Stack overflow when calling a DLL

I have developped a DLL in Ada.
I tried to call a function of this DLL from a C++ executable.
My program crashed because of a stack overflow.
Then, I increased the stack size of my program (linker option), and now it
works.
Calling this DLL through the call library function from a 6.0 Labview
program causes the same stack overflow.
How could I increase the stack size of my Labview program ?
Thanks.

Hi,
I have never come across this issue but here are a few things you can try:
1) Change the Calling Convention between C and StdCall(WINAPI). The main difference between the two calling conventions has to do with when the stack is cleaned up. In one method, the stack is cleaned earlier than in the other method.
2) Call your dll with LabVIEW 7.0. You can find the evaluation version of the latest version at http://www.ni.com/labview
Good luck
Feroz

Similar Messages

Array limitation when calling VB Dll?

Today I encountered a problem when calling a Visual Basic DLL in Labview 8.2.1
I had to pass a 3D Array, with one dimension exceeding 30 000. around that array size I ended up with error -2146828282 when calling the Dll.
The dll was working fine for weeks. So, is there any limition to the array size, which could cause the error?

Hi sthu,
Having 30,000 elements in one dimension of an array should not cause any problems by itself. The maximum number of elements per dimension in an array is (2^31) – 1 as described in the LabVIEW Help for Grouping Data with Arrays and Clusters. However, this is also dependent upon the memory available in your computer. If there is not enough memory available in RAM, you might receive an error when passing the array to the DLL.
I have included a couple links to pages that discuss LabVIEW memory usage and managing large data sets in LabVIEW. These might help get your application up and running with the larger array sizes.
VI Memory Usage
Managing Large Data Sets in LabVIEW
Donovan

LabVIEW crashes when calling a dll

I am trying to call a dll through my LabVIEW program. The dll implements a routine to access an ftp server. When the server is found, everything works as expected. However, if there is a delay in finding the server, LabVIEW throws an error � �An exception occured within the external code called by the Call Library Node�. The detailed error message is attached here.
The dll function times out after 25 seconds if the server is not found (it returns a signed integer). This error message pops up after roughly 20 seconds.
The dll was created in VC++ 6.0. It uses standard MFC calls.
Any information about why this could be happening will be appreciated.
Thanks.
Attachments:
LabVIEW_error.jpg ‏14 KB

Hi,
If you call a dll, everything should be just right, or it will crash (if you
use LV7, you're lucky, most of the times LV stays alive, and only gives a
message).
The first thing that should be checked is the calling convention. This
should probably be "stdcall (API)". This changes the way the parameters and
return address are pushed to the stack.
The second point are the parameters. Pointers should be set to pointers,
LONG to i32 etc. The return parameter can always be set to i32, or to
nothing.
My best guess is (since the dll crashes after a while), there should be a
pointer to a buffer (most likely a cluster, but could be a reference). The
connection succeeds, and the dll copies the information to the pointer. If
the pointer is not valid (the memory does
not belong to LabVIEW), an
exception is raised.
Perhaps you can give a function prototype? The prototype is the way to
start.
Regards,
Wiebe.
"gopinath" wrote in message
news:[email protected]..
I am trying to call a dll through my LabVIEW program. The dll
implements a routine to access an ftp server. When the server is
found, everything works as expected. However, if there is a delay in
finding the server, LabVIEW throws an error - "An exception occured
within the external code called by the Call Library Node". The
detailed error message is attached here.
The dll function times out after 25 seconds if the server is not found
(it returns a signed integer). This error message pops up after
roughly 20 seconds.
The dll was created in VC++ 6.0. It uses standard MFC calls.
Any information about why this could be happening will be appreciated.
Thanks.

Error when calling external DLL function.

When calling a function in Oracle, the error happens
ORA-28575: '... error RPC connection to external procedures'
code:
create or replace library LibFunctions as 'c:\MyDLL.dll';
grant all PRIVILEGES on LibFunctions to public;
create or replace
FUNCTION Max(num1 in number, num2 in number) RETURN number IS
EXTERNAL LIBRARY LibFunctions
NAME "Max"
LANGUAGE C;
grant all PRIVILEGES on Max to public;
obs. Dll was created in Pascal.
What can this error?
tks,
Mauricio
Edited by: user13794390 on 19/01/2011 06:29

It's been a while since I used extproc. Anyway, it listener.ora make sure extproc is added. I'll assume you are on Unix:
(SID_DESC =
(SID_NAME = PLSExtProc)
(ENVS = "EXTPROC_DLLS=ANY,LD_LIBRARY_PATH=proper-directory-list")
(ORACLE_HOME = path-to-oracle-home)
(PROGRAM = extproc)
) SY.

"stack overflow" when trying to connect with Oracle ODBC

Hi,
I'm trying to connect to Oracle DB (8.1.7.3.0) from WinNT 4.0 SP6 with Oracle ODBC driver 8.0.6.6.0. I've been trying to connect with "Oracle ODBC Test" and with "MS Query". In either way I end up with Dr. Watson reporting about "stack overflow". Before starting to upgrade ODBC driver I wanted to ask - should these versions of driver and DB work together at all (even unofficially)? Or may I be missing some other thing? Any hints, ideas are welcome.
Regards,
Madis Priilinn

Thank You for replying, Justin!
Yes, I can connect successfully to the database through other tools - at the moment I tried SQL*Plus, Net8 Easy Config and Schema Manager.
The Oracle client in the NT machine is 8.0.5.0.0. And unfortunately I do not know anything about the Oracle installation on this machine and at the moment I don't have that person near me too whom to ask also. But I think the installation was ok, because the connection through ODBC was working before the DB upgrade as far as I understood (sorry, again at the moment I don't know what was the previous version of DB. I will ask that information as soon as possible).
The main problem that bothers me at the moment is that I can't install 8.1.* series OraODBC driver with 8.0.5.0.0 Oracle Installer. I managed to install 8.0.6.6.0 version of the driver, but not the newer ones. As far as I've understood I have to upgrade the whole Oracle in the NT machine to upgrade that installer. Am I correct?
Regards,
Madis Priilinn

Error when calling a DLL function

Hi,
I am using external C++ code with labView. One of the DLL functions I use serves to call files. The directory and the name of the file is is passed as a parameter for this function. When the VI is running and arrives at this function (I use the Calling Library Function Node tool), the following message is displayed:
ERREUR de type class boost::filesystem::filesystem_error.
boost::filesystem:ath: invalid name "D:\Documents Johan\Johan\Stitching\Fichiers de mesure\front parfait\13z2" in path: "D:\Documents Johan\Johan\Stitching\Fichiers de mesure\front parfait\13z2"
I do not know why this message is sent to me.
Thanks for your answer
JF

Hello,
How are you passing the file path to the DLL -- are you passing it as a
string? If you are passing at as a string, I would do some basic
console output to make sure that your DLL is receiving the file path
corectly as a string and perform your appropriate C++ function in your
DLL. If the error is occuring with passing the file path you
might want to check out the links below for a little more information
on this.
http://zone.ni.com/devzone/conceptd.nsf/webmain/7d6a20fe02edbf318625690700704cf3#4
http://digital.ni.com/public.nsf/websearch/4E9234BA4C7C4ABE86256E3C0074760F?OpenDocument
http://digital.ni.com/public.nsf/websearch/3B994675B17C654A86256FDD00754DD2?OpenDocument
Hope this helps,
Travis M
NI
Travis M
LabVIEW R&D
National Instruments

Labview gpib timeout when calling cvi dll

Equipment used :
VXI Rack with Slot 0 controller
Labview V5.0.1
Lab Windows V5.0.1
GPIB controlled Power10 I63 PSU
We run an intermediate Labview driver which communicates with a low level CVI driver (dll) to control a PSU. We recently tried to run the Labview driver on a Slot 0 controller and we get timeout errors when waiting for a response after commanding the PSU to switch off ( "CST OFF" is sent , and the driver waits on "ST OFF" being returned - it never does and times out). Ni Spy is on when it fails. In the same driver, a call to return the Instrument ID is carried out happily, with the ID being returned with no errors.
I can run the low level CVI driver with an interactive script and it works fine with no errors.
I can run the Labview driver with NI Spy switched off and it works ok too, Our customer cannot get it to work even with Ni Spy switched off. They have the same setup as us.
Any ideas?

The solution I had previously documented only partly worked. It cleared the timeout error, but I am still experiencing various errors in testing the PSU with Labview (still no problems with running the functions with Labwindows directly). Also, if NISpy is running I see no errors, which still leads me to believe its a timing problem. I saw another thread on here from someone with similar problems and I tried all the recomendations in that, but it still did not fix it. The last recomendation was to re-write the GPIB driver to slow down the message transfer to the instrument!
A link to the thread with similar problems to mine.....
http://forums.ni.com/ni/board/message?board.id=140&message.id=20031
Message Edited by edinsofty1 on 09-09-2008 07:21 AM
Message Edited by edinsofty1 on 09-09-2008 07:21 AM

VB6 applications crashes when calling C# dll's in production environment

Hi All,
I'm basically .NET developer, not much aware of VB language or VB visual Basic 6.0.
We are trying to work out with VB application running/ using C# dll's. The scenario is like VB exe applications using C# dll's and C# dll's are referenced to VB application using .tlb file.
In development environment(debug mode) the application looks fine and working as expected. But when the same code is put into production environment VB applications are crashing when pointing to C# method calls. We trying to know the reason but application
is getting killed. The issue seems to be sporadic and not able to catch in MsgView(debug tool).
In one more scenario, the VB application is loading C# form and getting data back to VB but when we repeat the same workflow again application is crashing either in 2nd attempt or 3rd attempt.
Has anybody seen such issue? Any input is welcomed.
Thanks,
Shesh

Hi Shesh.ugare
Welcome to MSDN.
I am afraid that these forums donot support VB6, you could refer to this thread:
Where to post your VB 6 questions
If this issue regarding VB6 then you could consider posting this issue in these forums below:
These forums do not support Visual Basic 6, however there are many third-party support sites that do. If you have a VB6-related question please visit these popular forums:
VB Forums
VB City
If not, then you could share more detailed code with us.
Thanks for your understanding.
Regards.
Youjun Tang
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click
HERE to participate the survey.

LabVIEW 2010 crash when calling user32.dll

Interesting LabVIEW 2010 "feature" I discovered this morning.
Attached are two identical VIs, one saved in 2010 and one saved in 2009. These VIs were specifically written to demonstrate the bug I stumbled upon this afternoon. Each VI when run should allow you to find a specific program (window) open in Microsoft Windows and bring it to the foreground. It relies on "user32.dll" to perform this operation. It also allows you to specify the calling convention for the function call.
In LV 2009, either calling convention works, without error. However, in LV 2010 the calling convention for the function must be "stdcall (WINAPI)" and not the default "C". If the calling convention is "C" then LabVIEW crashes and closes without warning.
If you happen to have both LV 2009 and LV 2010 on your computer, I would love to hear if this phenomenon is duplicated so that I can pinpoint whether the bug is LV 2010 related or is more specific to my personal setup.
Thanks,
~David
Solved!
Go to Solution.
Attachments:
LV2010 test.vi ‏13 KB
LV2009 test.vi ‏14 KB

221113
Return
CLFN with the wrong calling convention may siliently crash LabVIEW.
LabVIEW 8.5 through 2009 could adjust the calling convention at run time if the user selected the wrong option. In 2010 this no longer happens. More information is found in KnowledgeBase 59KB14WI
Workaround: Use the correct calling convention
Reported Version: 2010 32-bit
Resolved Version: N/A
Added: 07/23/2010
From 2010 release notes.
Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA

Fall into a trouble when calling a dll from java in linux

Hi, experts:
I encountered a big trouble when using JNI to call a C++-compiled DLL from java in Linux: The DLL function didn't execute immediately after the invocation, and was deferred till the end of the Java execution. But all worked well after migrating to windows. This problem made me nearly crazy. Can somebody help me? Thanks in advance.
Linux: fedora core 8, jdk1.6.0_10,
compile options: g++ -fPIC -Wall -c
g++ -shared

It looks like the OP compiled the C source file and linked it into a Windows .dll, which would explain why it worked flawlessly in Windows. (Though I must say the usage of GCC would make someone think it was compiled in Linux for Linux, GCC also exists for Windows, so I'm not sure it's a Windows .dll either...)
@OP: Hello and welcome to the Sun Java forums! This situation requires you to make both a .dll and a .so, for Windows and Linux. You can then refer to the correct library for the operating system using System.loadLibrary("myLibrary"); without any extension.
s
Edited by: Looce on Nov 21, 2008 11:33 AM

Anyone ever see this error when calling a dll? "Arbitrary.dll?"

Hey folks, I'm attaching a jpg of the error I get as soon as I try and load a vi whose subVIs call a "Call Library Function".
Double clicking on the call function I can verify that the 'Library name or path" is correct, and the Function name is what I want.
I do not understand why it is telling me I need "Arbitrary.dll" - the name of the lib is adwgc.dll as indicated in the path (that I verified).
Anyone deal with this error before? I'm pretty clueless at the moment, any help will be appreciatized and surely kudo'd!
thanks
-pat
edit- also, I'm using LV 2011
Solved!
Go to Solution.
Attachments:
error.jpg ‏18 KB

You get this error because adwgc.dll is internally loading Arbitrary.dll because whoever wrote adwgc.dll called some function in Arbitrary.dll. The only to fix this is to get Arbitrary.dll and put it in a folder that adwgc.dll can load it from. Putting it in the same folder as adwgc.dll should work.
Where did you get adwgc.dll from and are you sure they didn't supply Arbitrary.dll as well?

Input parameter setting when calling a DLL(Built from LabVIEW and a kind of VISA communication driver) in Teststand.

In labVIEW7.1 I wrote a COM port communications driver by using "VISA Write/Read". I put a string as the input of "VISA Write" and made it the input of the whole vi. Then I converted the vi into a DLL, which is called in Teststand3.1 by specifying DLL adapter. In "Edit C/C++ DLL Call" dialog, I pass a message of "60 6A 94 80 86 81" as the input parameter. My problem is I tried three kinds of methods to pass the message, see attached 1.jpg,2.jpg and 3.jpg. and found the first one sometimes doesn't work, the second work fine and the last doesn't work all time. I don't know why the first one and last one don't work well.
Thanks!
Jacky
Attachments:
31.jpg ‏38 KB
11.jpg ‏36 KB
21.jpg ‏49 KB

Hi Srinivas,
Just another note, I noticed that the Math Interface Toolkit version (MIT) 1.0 is not compatible with LabVIEW 7.1. You’ll need version 1.0.1. of the MIT toolkit in order for it to work with LabVIEW 7.1.
The LabVIEW 7.0 lvanlys.dll is also attached. I had to rename it with a .txt extension, so you’ll want to delete the extension.
Kileen
Attachments:
lvanlys.dll.txt ‏516 KB

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??

Stack overflow when writting custom tags

Hi all
I am writting complex custom tags and deploying them into JBoss. The tags are nested and they also use other classes like Vector or HashTable.
Deployed the war file into Jboss, when browsing some JSP pages I get the : java.lang.StackOverflowError!
for example:
HTML code .....
<CustomTag1>
<CustomTag2></CustomTag2>
<CustomTag3/>
</CustomTag2>
HTML code.....
CustomTag1 bufferes it's body and pirnts it out on doafterbody.
about 20 or so classes are working together to publish the output.
Any help!

Amazingly I don't have any stack trace of error, just plain :
[jbossweb] WARNING: Exception for /index2.jsp java.lang.StackOverflowError
this is really strange, i trace the code by writing messages to standard output console and program stops in different locations every now and then.
for example : I have a method to save current state of a tag and then a method to render the output of the tag. the sequence is like:
in customTag1 the one that all tags of nested inside it.
public int doAfterBody()
InitChildTags();
LoadChildTagsStates();
ProcessRequest();
CallLoadPage(); // an astract method used by descendants of CustomTag1
SaveChildTagsStates();
RenderChildTags();
The program sometimes stops at "SaveChildTagsStates(); " sometimes at "RenderChildTags();"!

LV 6.0.2: an App-built dll gives a runtime error when called by C

I want to use Labview 6.0.2 VIs as DLL's in a Borland C++ Project.
Starting with the simple I have made a VI that returns a constant int32 then built a dll with the Application Builder and put the dll and include file in a BC++ project directory. Compile and link seems to run well. But when excuting the call to the LV fuction gives Fatal Error: labview.lib was not called from a Labview process.
It seems this question was posted before, but answer didn't help me, Sorry.
7.1 -- 2013
CLA

Hi Gabriela -
This question is answered in the KB article entitled : "LabVIEW.LIB Error When Calling a DLL Built with LabVIEW"
The link for this document is -> http://ae.natinst.com/operations/ae/public.nsf/fca7838c4500dc10862567a100753500/a4c3aef93240280a86256931006fb66c?OpenDocument
Or you can go directly to www.ni.com/support and search for this document and others to help.
The reason for this is that the old labview.lib does not know how to correctly locate the LabVIEW Run-Time Engine when called.
From the document I posted ->
Your dll is most likely making a call If you want to call a Windows DLL or CIN built with a version of cintools before LabVIEW 6.0, you must relink the DLL with the labview.lib from 6.0. If you call an old DLL or CIN in your LabVIE
W DLL, you receive the aforementioned error and the application terminates, because the old labview.lib does not know how to correctly locate the LabVIEW Run-Time Engine when called in this situation.
Good luck-
ben schulte
national instruments

Stack overflow when calling a DLL

Similar Messages

Maybe you are looking for