Problème fonction externe DLL lors du lancement d'un executable

Bonjour à tous,
J'ai créé un installeur qui génére mon application sous forme d'éxécutable. L'installeur et l'éxécutable fonctionne parfaitement sur certains PC. Par contre sur d'autres PC lors du lancement de l'application j'ai le message d'erreur suivant qui apparaît :
À noter que c'est le même installeur et le même éxécutable qui sont utilisés. La DLL est bien présente. Je n'ai pas accès aux fonctions de la DLL donc je ne sais pas comment elles sont rédigés.
Quelqu'un a-t-il déjà rencontré ce problème? Il faut que je puisse faire fonctionner cette application sur tout nos PC.

Bonjour,
Il semblerait que ton application ne trouve pas la DLL. Pourrais tu donner quelques détails supplémentaires qui pourraient avoir leurs importance en comparant les cas qui fonctionnent et ceux qui ne fonctionne pas. Donc si tu peux les configs qui marchent avec au moins les points suivants et les configs qui ne fonctionnent pas.
- Système d'exploitation : Windows 7, Windows 8 ...?
- Version 32 ou 64 bits de Windows ?
- Origine de la DLL ? Installé avec ton exe ? driver a installer sur le PC ?...
- Emplacement de la DLL. A côté de ton EXE ? ailleurs
- Emplacement de ton exe : dossier spécifique, programs files ?
- Les droits d'accès du compte utilisé sur le PC .
Je demande ces différents points car sur ta capture, tu sembles utiliser Windows 8. Avec les Dll, les chemins et les droits d'accès ont leurs importance et suivant les versions de Windows, ca change pas mal.
Dans tous les cas, tiens bon et ne te recogne pas la tête contre ton écran, on va trouver une solution
.mesLeft{float:left} .mesInfo{border-left:solid 1px #989898;font-size:x-small;color:#989898} .mesLogo{float:right;opacity:0.18} .mesLogo:hover{opacity:0.9}
Maxime R.
  CLD - Certified LabVIEW Developer / Développeur LabVIEW Certifié
  CLAD - Certified LabVIEW Associate Developer

Similar Messages

Fichier INI introuvable lors du lancement du .exe

Bonjour,
J'ai développer une application labview et mis en place un fichier ini pour le choix d'opérateur. Cette application et l'ouverture de la fenêtre du choix opérateur s'effectue normalement avec la lecture des noms dans le fichier .INI mais lorsque je passe à la création d'un exécutable, le fichier INI ne se lit pas, ou l'executable ne le trouve pas...
J'ai d'abord vérifié ma programmation et ai appris qu'il fallait décomposer deux fois le chemin du VI actuel lorsqu'on se trouve en exécutable. Après cette légère modification, le nom du chemin que je vais lire est le bon. Le fichier ini porte bien le même nom et se trouve à l'emplacement prévu. Mais lors du lancement de l'executable, aucun nom n'apparait dans la liste déroulante.
voici une capture d'écran pour illustrer mes propos :
merci d'avance pour votre aide !
ps : je suis sur Labview 8.6

Salut ! et merci de ta réponse rapide !
J'ai réaliser la programmation que tu as suggéré, mais celle-ci ne règle toujours pas le souci de la lecture du fichier INI lors du lancement de l'exécutable. J'ai mis un indicateur de chemin sur ma face avant. et le chemin lus grace à l'indicateur correspond bien à l'emplacement du fichier INI mais toujours pas de texte dans ma liste déroulante.
Pièces jointes :
try ini.vi ‏18 KB
operateur.ini ‏1 KB

How to load external DLLs with C++ interface in TestStand?

Hi,
Can you please let me know how would I load external DLLs with C++ interface in TestStand?
Regards.

TestStand 3.x can only call static class C++ methods. TestStand cannot call methods on a C++ object because TestStand does not know how to enstantiate the C++ object. In TestStand 3.x, there is a online help topic called "Exporting Class Methods and Functions in Visual Studio .NET".
Scott Richardson
National Instruments

How to use external DLLs in InDesign server plugin

Hi,
I am working on a project, which is having dependency on libxml2 library. I compiled the code on 64 bit Windows platform and using InDesign server 64 bit version. I put the required DLLs in Adobe InDesign CS6 Server x64 folder(with other DLLs). But now my plugin is not loading in server and also not throwing any error message on command prompt.
If I remove the libxml2's method call, then plugin is loading successfully.
Is there any other way to use external DLL or I am missing something?
Thanks & Regards,
Harsh

Hi Sidharth,
If you are using web dynpro DC perspective then you need to follow the following points to use the external jar files in it.
1. Create a external library project.
2. copy the external jars in the library folder os the projects.
3.) Select all the jars from the u201CLibrariesu201D folder, Right click and then select Development Component and click on Add to Public Part
4.Select the first Radio Button (Provides an API)and give some nameto it.
5. Repeat the step no 3 but now select the second radio button other than as selected in step no 4.
6. Now build your lirary DC.
7. Now create a j2ee DC project.
8. ) Expand the node DC Definition and Right Click on Used DC. Select Add Used DC.
9. Select the External Library DC with build time dependency.
10.Right click on the J2EE DC and then select Development Component followed by Build
11. Right click on the J2EE DC and then select Development Component followed by Deploy
now you can use both the libary DC and the j2ee DC in your web dynpro DC as used DC.
But if you have created a web dynpro project only(but not DC) than you can directly add the external jars in java build path
hope this will help
regards
Narendra
Edited by: Narendra Singh on Oct 27, 2009 11:22 AM

CVI crashes when calling function from external DLL

I'm calling a CVI library from Test Stand 4.1. In that CVI library I load an external DLL (using LoadLibrary) and create a few function pointers (using GetProcAddress). The DLL loads successfully, and I get addresses for all of the imported functions.
However, when I one of the functions is called CVI crashes (Test Stand says it lost the ActiveX connection to CVI) when executing in an external CVI instance. If executed in the Test Stand process I get a system level exception.
If I step through the code in CVI, it hangs after trying to step into or over the call to the function pointer from the external DLL.
I am able to call the functions in a small test project I created in CVI, however when integrating it into an existing test library and calling it through Test Stand it fails.
Any ideas on how to go about debugging this issue?

Have you tried calling into the dll that CVI calls directly from TestStand? I am curious to know if this also crashes.
I am also curious to know if there are any path references in the dll that is called by the CVI program. If so are they relative, or absolute paths?
I ask because one of the possibilities is that relative paths are being used to specify a path from the location of the code that is called, and they are not working because the current working directory is being specified by TestStand, and the paths are not relative to the working directory given by TestStand.
Jensen
National Instruments
Applications Engineer

Vi reference = function pointer for external DLL?

So I'm porting this simple program from C to LabVIEW. All it does is getting some signals from an haptics hardware (Sensable Phantom Omni). It should be simple, but it has shown several complications. (been stuck for 2 weeks )
I successfully imported the hardware's DLL with all of its functions (using LV 8.2, because 8.5 and 8.6 's wizard sucks).
But there is a function whose argument is a function pointer:
hUpdateHandle = hdScheduleAsynchronous(updateDeviceCallback, 0, HD_MAX_SCHEDULER_PRIORITY);
I already have the corresponding VI for updateDeviceCallback (which gets a (void *) that does not really use, and returns an int).
hdScheduleAsynchronous is part of the hardware's API (I can't mess with it, nor I know what's inside), and as first argument expects a function pointer.
Can I use the Open VI reference node to get the 'pointer' for my VI and then feed it as an argument for the external DLL? How do I properly cast the VI ref datatype into a function pointer?
Solved!
Go to Solution.
Attachments:
QueryDevice.c ‏9 KB
updateDeviceCallback.vi ‏14 KB

JavierRuiz wrote:
So I'm porting this simple program from C to LabVIEW. All it does is getting some signals from an haptics hardware (Sensable Phantom Omni). It should be simple, but it has shown several complications. (been stuck for 2 weeks )
I successfully imported the hardware's DLL with all of its functions (using LV 8.2, because 8.5 and 8.6 's wizard sucks).
But there is a function whose argument is a function pointer:
hUpdateHandle = hdScheduleAsynchronous(updateDeviceCallback, 0, HD_MAX_SCHEDULER_PRIORITY);
I already have the corresponding VI for updateDeviceCallback (which gets a (void *) that does not really use, and returns an int).
hdScheduleAsynchronous is part of the hardware's API (I can't mess with it, nor I know what's inside), and as first argument expects a function pointer.
Can I use the Open VI reference node to get the 'pointer' for my VI and then feed it as an argument for the external DLL? How do I properly cast the VI ref datatype into a function pointer?
LabVIEW has no concept that can translate seemlessly to function pointers and there is certainly no sensible way to make the Call Library Node support something like this.
There are possibilities to create a DLL from your callback VI and import the function using Windows API calls to pass it as a function pointer to your other function. But this is involved and quite dirty and most importantenly a total nightmare to maintain, since things go completely awry if your DLL is created in a different LabVIEW version than the LabVIEW version you call it with. This may seem like a piece of cake now but whoever will have to upgrade your software to a new LabVIEW version later will love you to the point that they will feel like sending you as the original programmer a nice little present that blows in your face when opened
The only feasable way is to write a wrapper DLL in C that translates between something more LabVIEW friendly like a user event and the actual callback function mechanisme.
Rolf Kalbermatter
Message Edited by rolfk on 06-09-2009 10:24 AM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

FRM-40734 when calling external DLL Function from Forms 6

Even though some answers were given to my previous help request ("Again: Forms 6 and user-defined data types") I wasn't able to solve the problem of passing a parameter of an user-defined type to an external DLL function residing in the SECURSIGN.DLL library (the closest solution was to declare that "composite" parameter using the ROWTYPE clause referencing a custom-made table created just for the sake of defining that perticular datatype).
So I concentrated on SECURSIGN.DLL functions using more trivial data types, like a function requiring just four character strings as parameters.
I generated the necessary PL/SQL support using the FFI.
I discovered that also the simplest calls to external functions fail at runtime with the generic error FRM-40734.
I located the error: it happens just at the moment of calling the function from within the FFI-generated package body. Before that, the DLL is loaded with no problem, the function is correctly registered, and a function handle is regularly returned.
As long as I can regularly issue the very same call with the very same parameters from Visual Basic, I can't understand what's going wrong (ALL the needed DLL are in the same directory as the FMB/FMX forms).
I will greatly appreciate any help that You may be able to provide.

I have noticed just now that a dump file having a name like ifrun60_dump_299, is generated by FORMS every time I issue the aborted call to the foreign function.
Inside the form dump file, apart from useless info like Registers and so on, the message:
"Could not find Module32First"
By a FILE/FIND/CONTAINING TEXT I searched all the DLLs, and I noticed that Module32First is a routine that can be found within each of the following DLLs:
Cl32
d2kwut32
d2kwut60
I tried to load those DLLs along with SECURSIGN.DLL by modifying the PROCEDURE LoadLibrary into the FFI-generated PLL code, and I have apparently no problem in loading all the DLLs that I wish, but the error persists, and that dump file is constantly generated, always looking for the "Module32First" routine.
How can I avoid all that mess and the FRM-40734 error??

Controling a user interface with extern DLL

Hi,
I am currently developing an application that is based on a graphical interface. I divide my code into multiple DLLs. By going this route, I met several problems. I want to know some facts:
1 - from the DLL can I assign values to textbox, read listbox of the GUI:GetCtrlVal (panelHandle, PANEL_TEXTBOX, val); (the GUI is integrating in the project who call the DLL)
2 - I use global variables "extern int" in my files. h and my functions. How do I change this variable declaration when I migrate to the DLL.
If you have any exemple describing how can i control a GUI with extern DLL.
Thanks

Hey Fishingman,
It looks like this post is very similar to your other post on Application Architecture. If this is the case, let's continue this discussion on this thread so that it is easier to follow for anyone else who may be keeping up with this.
To expand on my original response a little though - if you are just looking to be able to modify the user interface in a dll then take a look at this link. It explains how to set up dll function calls to modify a user interface. Again, I wouldn't suggest building your entire GUI through different dlls but it is definitely possible to modify it within a dll.
Regards,
Trey C.

Using an external DLL with "Call Library Function"

Hi!
I am trying to use an external DLL which is used from Visualbasic & Delphi:
http://www.keb.de/common/tools/KEBCOMDriver.zip
the protKEB.dll accesses the serial port to control an KEB frequency
inverter.
Unfortunatly there is no prototype header file for the DLL (no help on that
from KEB).
I only have a VisualBasic example program which works with the DLL.
(Unfortunatly I am no Visual basic expert)
To initialize the com port I have to use the function: setprotproperties &
getprotproperties
they are declared as:
'Setting the protocol properties
'ctrl is a pointer to a data structure of type tProtProperty
Declare Sub setprotproperties Lib "protkeb.DLL" (ctrl As Any)
'Reading the protocol properties
'ctrl is a pointer to a data structure of type tProtProperty
'the desired protocol is entered in ctrl.prottype before calling
Declare Sub getprotproperties Lib "protkeb.DLL" (ctrl As Any)
and tProtProperty is:
Public Type tProtProperty
ProtType As Long 'Type of Protocol (tProt)
TimeOut As Long 'ALL protocols
Baudrate As Long 'ANSI, HSP5
Comport As Long 'ANSI, HSP5
Flag As Long 'ANSI, HSP5: 01 = Sendslow
/ IP: 01 = UDP
Port As Long 'IPort number
Txtlen As Byte 'IP : length of following
text or 0
txt As String * 100 'IP : IP-Address or name
(maximum length)
End Type
I already tried to use a cluster with tProtProperty entries as an Input for
the function
setprotproperty in a call library function with:
Parameter Type : Adapt to type
Data Format: Pointer to Handle
but I always get an "exception within external code....."
What am I doing wrong?
How does a cluster & a "call library function node" look like that works?
Any help is really appreciated!
thanks
tom
,-Thomas Kerberger Physikalisch-Technische Bundesanstalt-.
| Abbestr.2-12 D-10587 Berlin fon: +49-30-3481338 |
| mailto:[email protected] fax: +49-30-3481386 |
`--------Labor 7.33 Messung thermischer Energie---------'

Thomas,
LabVIEW cannot call a DLL that has structures directly, you will need to create either a wrapper DLL or CIN that will take in all of the data individually construct the structure, and send it to the DLL function.
For more information on what a cluster looks like in native code, I would suggest creating a simple cluster, creating a Call Library Function Node on the block diagram with a cluster input. Then right-click on the Call Library Function Node and choose "Create .c file". This will generate the data structure for the cluster and give you a better feel for it. I would then suggest going to the Using External Code in LabVIEW manual that can be found in the LabVIEW Bookshelf (Start»Programs»National Instruments»LabVIEW 6»LabVIEW Manuals or »LabV
IEW 6.1»Search the LaBVIEW Bookshelf).
There is also the following: Developer Zone: Passing a Variety of Data Types from DLL to LabVIEW.
Randy Hoskin
Applications Engineer
National Instruments
http://www.ni.com/ask

HELP! RETURN CLOB from External DLL

Hi
I am working on an External DLL using OCI. Basically, PL/SQL
calls an
External DLL to process the data and then returns LOB back to
the PL/SQL
procedure. Inside the DLL, I created a Temporary lob to process
the data.
The error is prompted from PL/SQL:
SQL> exec isdb.test_clob;
Before original length=10
ORA-24805: LOB type mismatch
ORA-06512: at "ISDBSVR.ISDB", line 24
ORA-06512: at "ISDBSVR.ISDB", line 29
ORA-06512: at line 1
So far I know that error is caused by the return from PLS_CLOB
is not clob.
"After_original := PLS_CLOB(before_original); {you will see more
code in the
below}" However inside the DLL, I have defined OCIClobLocator
and
OCI_TEMP_CLOB to carry the CLOB data.
I have found the following observations:
1. If I change everything to blob, it works fine. (such as
OCILobLocator,
OCI_TEMP_CLOB and all variables in PL/SQL)
2. If I run the same DLL and PL/SQL in 9i, it works fine (clob
too)
I guess it would be a bug for clob, please help to check thanks
-- CODE - PL/SQL
CREATE OR REPLACE PACKAGE BODY "ISDBSVR"."ISDB"
as
Function PLS_CLOB(var_clob in clob)
RETURN clob IS
EXTERNAL LIBRARY bb
WITH CONTEXT
NAME "Encrypt_Blob"
LANGUAGE C
PARAMETERS
CONTEXT,
var_clob,
var_clob INDICATOR SB4,
RETURN INDICATOR SB4
PROCEDURE TEST_CLOB IS
before_original cLOB;
After_original cLOB;
CHAR_TO_CLOB varchar(200);
bsize int;
BEGIN
CHAR_TO_CLOB := 'AAAAAAABBBBBBCCCCCCC';
dbms_lob.createtemporary( before_original, TRUE );
DBMS_LOB.write( before_original,10,1,CHAR_TO_CLOB);
bSize := DBMS_LOB.GetLength(before_original);
DBMS_OUTPUT.PUT_LINE('Before original length='||bSize);
After_original := PLS_CLOB(before_original);
bSize := DBMS_LOB.GetLength(After_original);
DBMS_OUTPUT.PUT_LINE('After original length='||bSize);
dbms_lob.freetemporary(before_original);
END;
END ISDB;
/* CODE - DLL */
EXPORT OCILobLocator * EncryptBlob(OCIExtProcContext
*with_context,
OCILobLocator *plaintext2,
sb4 pt_indicator2,
sb4 *ret_indicator
{ FILE *fp;
OCIClobLocator *cipherbb;
ub4 amount;
ocictx oci_ctx;
ocictx *oci_ctxp = &oci_ctx;
status = OCIExtProcGetEnv(with_context,
&oci_ctxp->envhp,
&oci_ctxp->svchp,
&oci_ctxp->errhp);
status = OCIDescriptorAlloc(oci_ctxp->envhp,
(dvoid **) &cipherbb,
(ub4) OCI_DTYPE_LOB,
(size_t) 0,
(dvoid **) 0);
status = (int) OCILobCreateTemporary(oci_ctxp->svchp,
oci_ctxp->errhp, cipherbb,
OCI_DEFAULT,
OCI_DEFAULT,
OCI_TEMP_CLOB, OCI_ATTR_NOCACHE,
OCI_DURATION_SESSION);
amount = 6;
status = OCILobCopy(oci_ctxp->svchp,
oci_ctxp->errhp,
cipherbb,
plaintext2,
amount,
(ub4) 1,
(ub4) 1);
*ret_indicator = OCI_IND_NOTNULL;
OCIDescriptorFree((dvoid *) cipherbb, (ub4) OCI_DTYPE_LOB);
return(cipherbb);

In what database version did you observe the problem?
Thomas

Problems using LIBRARY to access external DLL

Windows 2003, Oracle 10g and 11g.
We have an external dll that we can call using 'create library' and a wrapper function. The wrapper functios works well from SQL*Plus - our function is executed and the external dll does its work.
When we add the function to some Apex processing, the session hangs at the point at which the wrapper function is invoked and control never returns - we have to kill the database session.
Any ideas as to what might be happening? I thought that a permissions error would be returned immediately, I don't know what would just make the session hang.

Windows 2003, Oracle 10g and 11g.
We have an external dll that we can call using 'create library' and a wrapper function. The wrapper functios works well from SQL*Plus - our function is executed and the external dll does its work.
When we add the function to some Apex processing, the session hangs at the point at which the wrapper function is invoked and control never returns - we have to kill the database session.
Any ideas as to what might be happening? I thought that a permissions error would be returned immediately, I don't know what would just make the session hang.

Use an external DLL

Hello
I would like to use an external DLL (wrote in C language) in my J2EE application.
how to set the JDEV (10.1.3.2.0) ?
Tanks in advance.
Benoît

Benoit,
Google around for JNI (the "classic" and "somewhat difficult to implement" way of doing this), or JNA (the "newer," "easier in most cases," and "not-part-of-standard-java-so-you'll-have-to-download-something" way).
I myself have used JNA in JDeveloper - it's really quite straightforward.
Best,
John

LabView user-event from external dll source

Hi!
I'm dealing with the following issue:
I use a CAN sniffer device, wich sends data over USB to a PC. The main goal is to create a vi that can process the incoming data. I already have a vi wich works with polling mechanism. It calls external DLL functions with the "Call library function node". The main problem is the polling mechanism.
I would like to recreate this vi so that it would work event-driven. I have an other application, written in C++, that does the same thing, and it gets interrupts from a DLL, when a new data is available in the input buffer.
The callback mechanism is implemented in the DLL.
In LabView I would like to do tha same thing. There is the "event case structure", but there is no option for defining such user-events, that i would prefer.
I have found a similar topic, there the solution is "occurrences". The occurrence is called from a DLL, too. But this solution uses the "waiting for occurrence to set", that is an endless-loop-like thing.
The other thing I've found is the ActiveX and .NET events. I don't know, probably that is the solution.
Anyway: is there a possibility to create such events, that can be generated from a simple external DLL and can be handled by "event case structure"? How should I do this?
Or how NI does this? I mean that NIs DAQ cards must use some similar methods for data processing. Is there some tutorial or support about it?
Thank you for your answer!

2716jag wrote:
Hi Wiebe, From your answer i have a doubt that What it exactly means "If the dll is used from within LabVIEW". Also i want to know Is there any way to access the functuions defined in the .SYS file in Labview Environment. Regards,Jagan Can you be a litte more specific with your first sentence. I have no good idea what you mean. A .sys driver is usually a kernel device driver. This driver has to be started and run in the kernel subsystem which LabVIEW can not access directly. Such a driver is initialized using the CreateFile() Windows API. The returned handle is then used with other API functions such as ReadFile(), WriteWile(), DeviceIoControl(), and finally CloseHandle().Theoretically you could call all this APIs directly from within LabVIEW using the Call Library Node. In practice you do not want to do this even for fairly simple kernel drivers since the parameters for those APIs do get fairly complex in most cases, and you usually do also want to have some sort of asynchronous operation using events or such to make the driver access user friendly. All these things are most easily handled in a user space DLL written in C that exports a more LabVIEW friendly API that you can then import into LabVIEW using the Call Library Node. Usually most kernel device drivers do come with a accompagning user space DLL already, as this is the only sensible way of accessing such a driver. So you can usually look for the documentation of that user space DLL API and go from there trying to import that into LabVIEW using the Call Library Node. Even then it may not be easy at all if that API uses complicated function parameters and even completely impossible if it uses callbacks or such, requiring you to write a so called wrapper DLL that translates between the native API and a more LabVIEW friendly API. You don't have to believe me but I can guarantee you that if writing such a user space DLL or wrapper DLL is beyond your capabilities, trying to go directly about accessing the Windows APIs in LabVIEW to access a kernel device driver is going to make you squirm in real pain. And those knowing how to write such a DLL would never even consider spending the time to try to access a kernel device driver directly from LabVIEW. Rolf Kalbermatter

What causes memory use of my program increase? (Write to Spreadsheet? Running in LV environment? External dlls? Waveform graphs?)

Hi
I have attached a plot for the discussion here..
I am monitoring the memory usage by my VI thru calling a window's dll to keep checking that (Many thanks to Matt).
I saw raising slopes and flat (wow! First time I catch this, that's what I am expecting)
I am thinking where could there be a reason for memory growing up!
What I did:-
1. Mostly use queues (all limited # of elements) for parameters delivery between loops and between subVIs
2. I close Obtained queue ref. every time I finish with it (only leaving a few keeping alive so they won't be killed)
3. For all arrays I initialized with a fixed size array constant and do all jobs with Replace subset, Index Array and that In-place block.
Above are measures I intended to use to save memory.
However for a few points I think there might cause a memory grows, and I wish that someone can share with me your experience or give me an answer...
1. Write to spread file:-- I keep using this to log data, events into harddisk, in my use I always append new logs/data to the existing file, however I keep doing it all the time throughout the run-time.
2. Running my program in LV.exe -- I havn't compiled it yet. However when I was taking the plot's data, my PC is left with no one using it.
3. There is a couple of external dlls running -- however it sounds to me from other's view point, external dll's resource doesn't count into Labview.exe. Since I am monitoring Labview's memory use, that couldn't be a source of the raising I see from this plot, right?
4. Waveform graphs -- I am not sure whether this can be a problem. Everytime I feed data into a waveform control, I initialized a constant array and then replace elements into it, I don't think my data source is casuing any problem.
Can someone comment on my above descriptions of my program?
Raymond

vgbraymond wrote:
1. Write to spread file:-- I keep using this to log data, events into harddisk, in my use I always append new logs/data to the existing file, however I keep doing it all the time throughout the run-time.
Write to spreadsheet file is a high level VI that opens and closes the file with every call. I would recommend to open the file once at the start of the programs, then append using lowlevel functions. Close the file after the program is done.
Have you done any profiling to see which subVIs shows the bulk of the memory use?
You might also turn off debugging to see if it makes a difference. Don't open the front panel of subVIs (and avoid functions that force the front panel to be in memory) unless they need to show something important to the user.
It would really help if we could see some actual code. Can you strip it down to the essentials that still show the problem?
LabVIEW Champion . Do more with less code and in less time .

Compiling own app with -X02 makes external dll core dump.

Hello,
I have a C++ app that calls a function w/in an external shared library. The external dll does not have debug symbols and is probably optimized. When my app is compiled with -xO2 or higher, I get a core dump (no mapping at the fault address) deep within the external dll. When I am compiling my app with -xO1 or with debug info, I do not get the core dump within the external dll.
My questions are:
1. Does this mean that there is a bug w/in my code or within the external dll's code?
2. If not error in either, is there any way to overcome this core dump without lowering the level of optimization (and thus slowing down the app)
Here is a stack trace I got by attaching dbx to my app:
t@1 (l@1) signal SEGV (no mapping at the fault address) in num2qword at 0xfd320248
[1] num2qword(0x345cfd8, 0xffffff85, 0x63ad0, 0xfd323ba0, 0xa800, 0xa8d8), at 0xfd320248
[2] evalexpr(0xffbf7f58, 0x345cee8, 0x1, 0x0, 0xfd27e558, 0xfd3230d0), at 0xfd323ba0
[3] eval_expr_full(0x328e388, 0x345d04c, 0x345cfd8, 0xfd27e558, 0x1, 0x0), at 0xfd3249e8
[4] cm_eval_expr(0x328e388, 0x345d04c, 0x5800, 0x5944, 0xb400, 0xb400), at 0xfd1eea68
[5] cm_optredeem_can_redeem(0x328e388, 0x345d1e0, 0x16ddec, 0x5c00, 0x0, 0x345d1e4), at 0xfd21620c
[6] cm_optredeem_condition(0x328e388, 0x345d1e0, 0x0, 0x0, 0x0, 0x135eb29), at 0xfd2162d8
[7] cm_maybe_execute_optredeem(0x328e388, 0x345d1e0, 0x0, 0x0, 0x0, 0x1), at 0xfd216568
[8] cm_pay_1_period(0x328e388, 0xfd3ba364, 0x345d1e0, 0x345d52c, 0xfd383c98, 0x0), at 0xfd21ab5c
[9] cm_payloop(0x328e388, 0x1, 0x0, 0x324df00, 0x0, 0x3), at 0xfd21ae08
[10] icmo_cashflows(0x0, 0x0, 0x168, 0x328b7b0, 0x0, 0x328b7b0), at 0xfd2d1700
[11] CMOInstrument::getICMOCashFlow(0x1627b28, 0xfd48bdb8, 0x570, 0x2b1c, 0x2800, 0x400), at 0xfd442410
[12] NE_CMOAnalytics::value(0x39b71e0, 0x98, 0xfd48bdb8, 0xe, 0xffbfc268, 0x2e93b08), at 0xfd42d560
[13] NumericExpression::value(0x1643800, 0x1667b48, 0x1667b48, 0x2eabde0, 0x2eabde0, 0x0), at 0xc13410
[14] NE_CMOPriceTimesBalance::value(0x2b02078, 0x2ead230, 0x1667b48, 0x2eabea0, 0x2eac06c, 0xfd48ec8c), at 0xfd42da9c
[15] NumericExpression::value(0x1643800, 0x1667b48, 0x1667b48, 0x2eabea0, 0x2eabea0, 0x0), at 0xc13410
[16] ExchangeableModuleBase::evaluateExpression(0x31259c4, 0x15e4400, 0x0, 0x2eabea0, 0x1667b48, 0x2e93b08), at 0x746e54
[17] ExchangeableModuleBase::evaluateExpressions(0x31259c4, 0x2f3d7c8, 0x746ca0, 0x1, 0x164c800, 0x15c8414), at 0x746c68
[18] ExchangeableModuleBase::recalc(0x31259c4, 0x0, 0xffffffc8, 0x164c800, 0x0, 0x746c40), at 0x746c10
[19] ExchangeableModule::recalc(0x31258d4, 0x15e5730, 0x15c81ac, 0x164c800, 0x7fe8c0, 0x0), at 0x4a8ff4
[20] BatchInstrument::commandDispatch(0x15fd850, 0x1ac, 0x1, 0x619b2c, 0xc, 0x2ebbbc0), at 0x619ce0
[21] Callback(0x2eee48c, 0x3, 0x5, 0x1, 0xffbfccf0, 0xffbfcd6c), at 0xe652f0
[22] CallExtRtn(0xffbfe1d0, 0x2, 0x1, 0xffffdffe, 0x1, 0xfcd0fc86), at 0xe727d4
[23] PcodeExecute(0x2eee8ac, 0xef5c18, 0x1, 0x15b9750, 0xef5c18, 0x4), at 0xeab848
[24] ExpStartThread(0x2eee48c, 0x0, 0x0, 0x1, 0x1, 0x0), at 0xe6e1e0
[25] BasicScriptCodeObject::executeThread(0x2ebb070, 0x2eee48c, 0x0, 0x2ebb074, 0x2eeed68, 0x0), at 0xa0fcb0
[26] BasicScriptCodeObject::run(0x2ebb070, 0x0, 0x0, 0x0, 0x0, 0x2ebb070), at 0xa0fe24
[27] BasicScriptManager::loadAndExecInitScriptFile(0x2d7eb08, 0x1, 0xa, 0x0, 0x1, 0x2eef5f0), at 0x587f80
[28] main(0x32db9b8, 0xffff3400, 0x308b998, 0x0, 0x1c1fd20, 0x1c0db58), at 0x438c6c
[10] icmo_cashflows(...) is the call to the external dll. From 9 and up to 1 the source code is not visible to me..
OS/CC Versions:
CC: Sun C++ 5.5 Patch 113817-05 2004/01/13
SunOS: 5.9 Generic_117171-05 sun4u sparc SUNW,Sun-Fire-880
compilation options:
-dalign -xarch=v8plusa -xlibmopt -D__solaris_sparc__ -errtags=yes -errwarn=wnoretvalue,wnoelseretvalue +w2 -erroff=doubunder,reftotemp,notemsource,hidef,hidevf,wbadlinkage_w,noexthrow,noextry,notused -DLIC_MGR -DUSE_SMART_HEAP -DUSE_SH_ALLOC -template=wholeclass -instances=explicit -features=no%except -features=rtti -Drindex=rindex -Dindex=index -DADD_DYNAMIC_SYMBOLS -KPIC -DNDEBUG -mt -xO1 ( -xO2 .. -xO5 or -fast give above noted core dump)
Thanks in advanice,
Alex

From the symptoms you describe, it is possible that the shared library contains a bug, but it is more likely that the problem is in your code, passing bad data to the shared library.
The problem might be a compiler bug, but I think an error in your code is more likely.
For example, your code as written might have undefined behavior that works by accident when compiling without optimizing, but fails when the compiler improves the runtime code.
Some examples:
1. A classic MT programming error is failing to declare a variable volatile when it is shared by more than one thread. In each thread, the compiler assumes it can remember the value of the variable and not reload it between references.
2. "x = ++x + b;" Modifying a variable twice in an expression withtout sequence points has undefined behavior -- compiler optimization can affect the result.
3." foo(x, x+=3);" the order of evaluation of function arguments is unspecified, so the actual values passed to foo could depend on optimization.
With C++ 5.5, you get some warnings from system headers that you can't do anything about, which I suspect is why you have disabled some warnings. Unfortunately, you might be disabling warnings that you need to see. That is, some of the disabled warnings could point to invalid code that results in the program crash.
I suggest using w instead of w2 (to avoid uninteresting warnings), and fix your code to eliminate the warnings you get.
In the current compiler, C++ 5.7 in Sun Studio 10, we have made some adjustments to warnings to make w and w2 more useful. You should consider upgrading.You can get a 60-day free trial version here:
http://www.sun.com/software/products/studio/index.xml
Also get the current patches for it here:
http://developers.sun.com/prodtech/cc/downloads/patches/index.html

Problème fonction externe DLL lors du lancement d'un executable

Similar Messages

Maybe you are looking for