Changing numeric control representation causes fatal internal error.

Has anyone seen this problem. In the attached program the control at the top of the front panel named "Part Number" is a U64 which was part of an earlier program. I wanted to change the representation of the control since I don't need a U64 so I tried to change it to a U8 or any other unsign number and get an fatal internal error which closes the program. The error screen is also attached. Is this a know issue? Is there a work around the problem? Just not sure why changing this control's representation would cause such a error? Please let know if this has been seen before.
Regards
Gary
Attachments:
Sockeye1P1.zip ‏210 KB
LV2010_ErrorScreen.JPG ‏96 KB

Hey Gary,
Sorry to hear that you're experiencing this error. This could be related to a known LabVIEW 2010 issue with case structure selectors having their representation changed. A Corrective Action Request for that particular issue has been filed for this so that it can be looked at for future versions. The workaround is to delete and re-add the case structure (just the one where the Part Number is the case selector, located in your "WaitStart" state). Basically, the case structure gets corrupted causing the crash.
I wasn't able to reproduce this on my machine, however I had to cull a lot of your code to run it here due to missing subVIs, etc. Let me know if deleting and re-adding the case structure fixes your issue and hopefully we can get to the bottom of this.
Courtney L.
Applications Engineer
National Instruments

Similar Messages

Use mouse scroll wheel to change numeric control

Does anyone know if and how I can use the mouse scroll wheel to change numeric control values?

Another option would be to change the timeout. This would avoid the timeout event every ms when the mouse has not "entered" the contol.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Attachments:
Mouse Scroll.vi ‏14 KB

Fatal Internal Error MemoryManager.cpp

I've created a sequence file in teststand that uses the sub vi's for
reading out config files. If I run this on my development machine
there is no problem.
I tried to deloy everything onto a new target machine. I start to run
the sequence and i'm able to execute the 'Open Config Data.vi'. The
next step is to read out some data with the vi 'Read Key(String).vi'
but this creates the error. I get a Fatal Internal Error :
"MemoryManager.cpp" , line 406 LabVIEW 8.5.
What could cause this problem?

I have been struggling with this error today. It appears that under some circumstances LabView does not automatically recompile all VIs requiring referencing a typedef when the typedef is changed. In my case, the problematic routine was one in which the typedef did not appear as a control, indicator or diagram constant. An array of the typedef was an output from one SubVI that was an input to another. The first routine had a case structure around it with some cases where the output took a default value. I assume the default typedef output is the core of the problem in my case. Manually recompiling the routine (or making any code changes to it) solved the problem.
One could probably do a mass recompile of the whole VI hierarchy to solve this problem, but that's undesirable in a large program that is being developed by a team. It is at least something to try if you are running into this error.
Unfortunately I have not been able to make a simple program that reproduces this problem. I have attached some code but it does not make LabView crash. However, bad pointer dereferences are tricky things to debug because the severity depends on where you end up when you dereference. (In my production code, LabView was trying to read location 0xFFFFFFFF; Windows killed it). So this example could be causing silent corruption. Or my suspicions could be ungrounded and the bug may lie elsewhere.
I do notice that when I change the typedef and quit labview, labview offers to save the TLVI and the two subVIs that contain the typedef control, but not the routine I suspect is causing the problem. ("Routine that doesn't recompile.vi" in my example.)
This message is related to support issue "Reference#7184406".
-Rob Calhoun
Attachments:
MemoryManagerCrash.zip ‏36 KB

Fatal Internal Error: "image.cpp", line 13192 when trying to insert a cursor to graph

NOTE: This IS a duplicate post from the Breakpoint. Text slightly changed. The post in Breakpoint can be deleted. All comments should be placed in this thread.
I resolved the "Fatal Internal Error: "image.cpp", line 13192 when trying to insert a cursor to graph", but would like to share to find out if others have seen this and to determine whether this is a bug, or if it's time to redo my PC, or buy a new one..
I have an existing graphs (qt 6) which originally had 2 cursors. This occurred while trying to add the third cursor.
Up until attempting to add the last cursor, the program worked great, and I had been running tests for a while. However, I do recall seeing this problem when creating the original cursors, but not to this extent. Plus I don't remember the original error message from that time.
I needed to add one more cursor to the existing graphs. As soon as I add a new cursor and set it's properties, I get a nasty error message and without warning LV8.2 simply closes itself (well, the only warning was the error message. Tried it 3 times, same result.
Here are the steps:
Shut down the PC, went for a coffee, rebooted the PC. Opened the LV project, opened the VI. Immediately went to the graph properties to add the new cursor by doing the following steps:
Right click graph indicator icon on block diagram.
Select Properties.
Click on cursor tab.
Click on Add
Select Cursor 2 (3rd one, newly created)
Change color
Select cursor as a line
Remove checkmark for "show cursor"
Click OK
I need to do this to 3 other graphs, same steps. And as soon as I get to the step before clicking OK, I get the error message.
I managed to get an additional one done, by immediately saving after each step (yep going in & out of the properties). But I've had this problem before when creating the first two cursors.
Is it a bug? Anyone else seen this? Using LV8.2. And the message is right about LOOSING ALL unsaved work!!!!
Here are more observations:
Tried creating a new one on the second graph. As soon as I clicked on the color, it crashed!
See the error explanation below. It is really clear, now anyone can solve it    LOL!!... According to the error log, there's a bad image out there
.\manager\image.cpp(13192) : DAbort: bad image in ValidateImage
$Id: //labview/branches/Europa/dev/source/manager/image.cpp#47 $
0x007A81E8 - LabVIEW <unknown> + 0
0x007A7BDB - LabVIEW <unknown> + 0
0x00829D74 - LabVIEW <unknown> + 0
0x008546CD - LabVIEW <unknown> + 0
0x00C054E6 - LabVIEW <unknown> + 0
0x0081B9C8 - LabVIEW <unknown> + 0
0x0081EB9A - LabVIEW <unknown> + 0
0x0084D9D4 - LabVIEW <unknown> + 0
0x00854663 - LabVIEW <unknown> + 0
0x00C054E6 - LabVIEW <unknown> + 0
0x0085F7A1 - LabVIEW <unknown> + 0
0x00BBACDD - LabVIEW <unknown> + 0
0x00C06A2F - LabVIEW <unknown> + 0
0x0085AA46 - LabVIEW <unknown> + 0
0x00C06A2F - LabVIEW <unknown> + 0
I observed the title bar after making changes to the properties. I noticed that 3 out of 4 times, while changing the properties of the graphs to include the cursor, and saving after each & every step, that there were no stars appearing on the title bar to indicate "unsaved changes". Saving was also much slower than usual. I suspect, the program never got to placing the star before saving occurred. However, I am noting everything.
After creating the cursors, saving was and is normal, and the program runs well..   I have run tests without problems.
Does anyone have a clue at what causes this? Has anyone seen this before?
Thanks,
RayR

Hi Donovan,
I can't remember seeing this elsewhere. When I get a chance, I'll create a new (blank) vi with new graphs and will repeat the steps.
I will let you know if I see this in the new vi.
Thanks!
RayR

Solaris Studio 12.3 demangle fatal internal error: information lost in character quoting

Hello,
I have run into a problem with the Solaris Studio 12.3 compiler when building one source file that makes use of the open source Eigen library. The compilation fails with the error:
demangle fatal internal error: information lost in character quoting
CC: fbe failed for CSeasonalComponent.cc
The full command that fails is:
CC -c -o .objs/CSeasonalComponent.o -m64 -g3 -fsimple=1 -O4 -xbuiltin=%all -xlibmil -xlibmopt -xarch=sse3 -xchip=nehalem -nofstore -xalias_level=compatible -features=extensions -errtags +w -erroff=anonnotype,anonstruct,badargtype2w,hidef,notemsource,wbadasg -library=Crun -library=no%Cstd -KPIC -mt -I/usr/local/stdcxx/include -I/usr/include -I/usr/local/include -DSOLARIS -D_POSIX_PTHREAD_SEMANTICS -D_RWSTD_NO_STRING_MUTEX -D_RWSTD_MINIMUM_STRING_CAPACITY=22 -D_RWSTD_NO_LIST_NODE_BUFFER -DBOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS -DEIGEN_MPL2_ONLY -DEIGEN_DONT_USE_RESTRICT_KEYWORD -DNDEBUG -I/export/home/dave/source/local/include -I/usr/local/include/boost-1_54 CSeasonalComponent.cc
The problem goes away if the -g3 flag is removed. Replacing -g3 with -g0 does not help - the same fatal error occurs. (Removing the -g0/-g3 options has the effect of not passing a -dbgfile option to the fbe program, and this appears to be what avoids the problem.)
The information in this question is from a Solaris x86 machine, although the same "demangle fatal internal error: information lost in character quoting" also occurs on SPARC with the same source file and similar (although obviously not identical) compiler options.
The result of running the CC command that fails with the -dryrun option added is this:
### CC: Note: NLSPATH = /opt/solarisstudio12.3/prod/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/opt/solarisstudio12.3/prod/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
###     command line files and options (expanded):
### -dryrun -c -o.objs/CSeasonalComponent.o -m64 -g3 -fsimple=1 -O4 -xbuiltin=%all -xlibmil -xlibmopt -xarch=sse3 -xchip=nehalem -nofstore -xalias_level=compatible -features=extensions -errtags=yes +w -erroff=anonnotype,anonstruct,badargtype2w,hidef,notemsource,wbadasg -library=Crun -xcode=pic32 -mt=yes -I/usr/local/stdcxx/include -I/usr/include -I/usr/local/include -DSOLARIS -D_POSIX_PTHREAD_SEMANTICS -D_RWSTD_NO_STRING_MUTEX -D_RWSTD_MINIMUM_STRING_CAPACITY=22 -D_RWSTD_NO_LIST_NODE_BUFFER -DBOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS -DEIGEN_MPL2_ONLY -DEIGEN_DONT_USE_RESTRICT_KEYWORD -DNDEBUG -I/export/home/dave/source/local/include -I/usr/local/include/boost-1_54 CSeasonalComponent.cc
/opt/solarisstudio12.3/prod/bin/ccfe -xarch=amd64 -D__SunOS_5_10 -D__SUNPRO_CC=0x5120 -D__unix -D__SVR4 -D__sun -D__SunOS -D__x86_64 -D__x86_64__ -D__amd64 -D__amd64__ -D_LP64 -D__LP64__ -D__BUILTIN_VA_STRUCT -Dunix -Dsun -D_REENTRANT -D__SUN_PREFETCH -D__SUNPRO_CC_COMPAT=5 -I/usr/local/stdcxx/include -I/usr/include -I/usr/local/include -I/export/home/dave/source/local/include -I/usr/local/include/boost-1_54 -I-xbuiltin -I/opt/solarisstudio12.3/prod/include/CC -I/opt/solarisstudio12.3/prod/include/cc -DSOLARIS -D_POSIX_PTHREAD_SEMANTICS -D_RWSTD_NO_STRING_MUTEX -D_RWSTD_MINIMUM_STRING_CAPACITY=22 -D_RWSTD_NO_LIST_NODE_BUFFER -DBOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS -DEIGEN_MPL2_ONLY -DEIGEN_DONT_USE_RESTRICT_KEYWORD -DNDEBUG -ptf /tmp/ccfe.04.%1.%2 -features=extensions -ptx /opt/solarisstudio12.3/prod/bin/CC -ptk "-dryrun -c -m64 -g3 -fsimple=1 -O4 -xbuiltin=%all -xlibmil -xlibmopt -xarch=sse3 -xchip=nehalem -nofstore -xalias_level=compatible -features=extensions -errtags=yes +w -erroff=anonnotype,anonstruct,badargtype2w,hidef,notemsource,wbadasg -library=Crun -library=no%Cstd -xcode=pic32 -mt=yes -I/usr/local/stdcxx/include -I/usr/include -I/usr/local/include -DSOLARIS -D_POSIX_PTHREAD_SEMANTICS -D_RWSTD_NO_STRING_MUTEX -D_RWSTD_MINIMUM_STRING_CAPACITY='22' -D_RWSTD_NO_LIST_NODE_BUFFER -DBOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS -DEIGEN_MPL2_ONLY -DEIGEN_DONT_USE_RESTRICT_KEYWORD -DNDEBUG -I/export/home/dave/source/local/include -I/usr/local/include/boost-1_54 " -compat=5 -g -xdebuginfo=macro -xdbggen=no%stabs+dwarf2+usedonly -xF=%none -xbuiltin=%all -pic -xldscope=global -xivdep=loop -xalias_level=layout -xdepend -O4 -errtags -erroff=anonnotype,anonstruct,badargtype2w,hidef,notemsource,wbadasg +w CSeasonalComponent.cc -ptb .objs/CSeasonalComponent.o -o /tmp/ccfe.01.ir -s /tmp/ccfe.02.sd 2> /tmp/ccfe.03.err
/opt/solarisstudio12.3/prod/bin/iropt -Qy -O4 -xarch=sse3 -m64 -xchip=nehalem -xcache=generic -fsimple=1 -g -depend -mt -k -xalias_level=layout -xbuiltin=%all -xlibmopt -xprefetch=auto,explicit -xprefetch_level=1 -xprefetch_auto_type=no%indirect_array_access -xvector=no%lib,simd -F -o /tmp/iropt.05.ir -is /tmp/ccfe.02.sd /tmp/ccfe.01.ir 2> /tmp/iropt.06.err
rm /tmp/ccfe.01.ir
/opt/solarisstudio12.3/prod/bin/c++filt -filt=no%stdlib < /tmp/iropt.06.err >> /tmp/ccfe.03.err
rm /tmp/iropt.06.err
/opt/solarisstudio12.3/prod/bin/stdlibfilt -stderr < /tmp/ccfe.03.err
rm /tmp/ccfe.03.err
/opt/solarisstudio12.3/prod/bin/ir2hf -Qy -g -O4 -xbuiltin=%all -m64 /tmp/iropt.05.ir /tmp/ccfe.02.sd /tmp/ir2hf.07.hf
rm /tmp/ccfe.02.sd
rm /tmp/iropt.05.ir
/opt/solarisstudio12.3/prod/bin/ube -Qy -verbose -iropt -O4 -comdat -m64 -xarch=sse3 -xchip=nehalem -xcache=generic -xannotate=yes -il /opt/solarisstudio12.3/prod/lib/amd64/libm.il -fsimple=1 -ZW -g -xalias_level=layout -PIC -xbuiltin=%all -N -xprefetch=auto,explicit -xprefetch_level=1 -xthreadvar=dynamic -mt -fbe /opt/solarisstudio12.3/prod/bin/fbe -ipo .objs/CSeasonalComponent.o -dbgfile /tmp/ube.09.dbg -S /tmp/ube.08.s /tmp/ir2hf.07.hf
rm /tmp/ir2hf.07.hf
/opt/solarisstudio12.3/prod/bin/fbe -Qy -xarch=amd64 -xchip=nehalem -warn=%none -o .objs/CSeasonalComponent.o /tmp/ube.08.s -dbgfile /tmp/ube.09.dbg
rm /tmp/ube.08.s
rm /tmp/ube.09.dbg
Running the CC command with the -keeptmp option added leaves these files in /tmp:
-rw-rw-r--   1 dave     dev            0 Dec 11 16:20 /tmp/ccfe.1386778859.8273.03.err
-rw-rw-r--   1 dave     dev      45679331 Dec 11 16:21 /tmp/ccfe.1386778859.8273.01.ir
-rw-rw-r--   1 dave     dev            0 Dec 11 16:21 /tmp/iropt.1386778859.8273.06.err
-rw-rw-r--   1 dave     dev       393220 Dec 11 16:21 /tmp/ccfe.1386778859.8273.02.sd
-rw-rw-r--   1 dave     dev      47820727 Dec 11 16:21 /tmp/iropt.1386778859.8273.05.ir
-rw-rw-r--   1 dave     dev      60490992 Dec 11 16:21 /tmp/ir2hf.1386778859.8273.07.hf
-rw-rw-r--   1 dave     dev      22377791 Dec 11 16:21 /tmp/ube.1386778859.8273.09.dbg
-rw-rw-r--   1 dave     dev      8915850 Dec 11 16:21 /tmp/ube.1386778859.8273.08.s
Finally, creating an fbe command similar to the one from the dry run output using the last two files in /tmp with the -V option added as follows:
/opt/solarisstudio12.3/prod/bin/fbe -V -Qy -xarch=amd64 -xchip=nehalem -warn=%none -o .objs/CSeasonalComponent.o /tmp/ube.1386778859.8273.08.s -dbgfile /tmp/ube.1386778859.8273.09.dbg
results in this:
as: Sun Compiler Common 12.3 SunOS_i386 2011/11/16
demangle fatal internal error: information lost in character quoting
I would be happy to provide the /tmp/ube.1386778859.8273.08.s and /tmp/ube.1386778859.8273.09.dbg files to assist with reproduction of this problem if anyone is interested.

The problem with creating a simple test case that doesn't rely on Boost or Eigen is that the error message is so vague that there's no hint about where to start. The pre-processed source of the file that causes the problem is 4.7MB so trying to chop that down without any clue as to what's relevant is going to be very hard.
You could do everyone a favour if future internal error messages contained at least some information about what caused the problem. I know they're not supposed to happen at all, but clearly they occasionally do. For example, instead of:
demangle fatal internal error: information lost in character quoting
something like:
demangle fatal internal error: information lost in character quoting: corrupt symbol is __1cFEigenPPlainObjectBase4n0AGMatrix4CdIBiBiAIBiB___KresizeLike4n0AOGeneralProduct4n0AFBlock4Ckn0AGMatrix4CdIBIB_"""_oops
Then that would give somebody trying to report the problem or change their code to avoid it a starting point for where to look.
Anyway, I've worked around the problem by changing -g3 in the CXXFLAGS in the Makefile to `test $< = CSeasonalComponent.cc || echo -g3` which avoids the error. And hopefully like you say it's a known problem that's already fixed in the next version of Solaris Studio.

I have encountered the new error "Fatal internal error fpinit.cpp line 7398

I get the error message "Fatal internal error fpinit.cpp line 7398".
I use:
TestStand 2.0
LabView 7.1
Vision 7.1
uEye USb Camera
I've included into my TestStand programm some new steps that control the uEye USB Camera.
I use following steps (all steps written in LabView):
- Initialze Camera
- Wait
- Close Camera
- Wait
I have the settings "Load dynamically" in TestStand"
If I use also the setting "Unload after sequence executes" and start the sequence I get somtimes a LabView error after running the Step for the Camera initialization. LabView is sometimes immediatlly closed. This happen at leased after 10 turns/starts of the programm. If I use the loop functions "Loop on selected steps" it happen only sometimes at the first loop. The initialize Camera Step is every time pass, if TestStand try to run the next step I get a error.( Sometimes I get also the message ActiveX Server got lost)
I detected also that sometimes in this case a constant in a other vi is emty.
Normally I use the setting "Unload when sequence file is closed" then I have the problem only sometimes at the first turn.
If the initialize Camera step is succesfull I have no problem with further camera steps.
Regards
Alexander
Attachments:
lvlog02-18-10-09-34-10.txt ‏1 KB
Copy of Error.jpg ‏76 KB
Copy of Error2.jpg ‏42 KB

Hi Alex,
I'd suggest to replace all ctl. with new ones.
Perhaps one of them is corrupt.
You will find a documentation about preferred execution system
in the LabVIEW help. I also attached this files.
Regards
DianaS
Attachments:
help1.gif ‏37 KB
help2.gif ‏11 KB

Fatal internal error: I/EX

I am developing an application, it will read out data in an olite db(5.0.2.7) using jdbc call, then it will write these data into an oracle 9i db using bc4j.
my system runs in win xp, I am using JDeveloper 9.0.3.1035.
when I run my class as a plain java application, everything is ok.
but when I call my class from a servlet as a web applicaiton, the web application terminate unexpected with an popup error message:
I/EX 311, and I can find this error in log:
Fatal internal error: I/EX
When I debug my program, I found that the error occured in rs.getString() statement :
ResultSet rs = ... ;
String s;
s = rs.getString("...");
Any one can help?
thanks.

Hello ! I am working with Oracle lite :
Connected to: Oracle9i Lite ORDBMS
Database Name: POLITE (Read Write)
Database Version: 4.0.2.0.0
Auto Commit: off
Driver Name: oracle.lite.poljdbc.POLJDBCDriver (OLite 4.0)
and Jdeveloper 9i
JDK 1.3 of the Jdeveloper and W2K Professional
I was searching for an answer cause I have the same problem but I realized that the problem is not directly related with BC4J or OC4J.
I suspect that is involve with the driver olite40.jar I hope you can validate this. I can reproduce the problem and it happen when you run a program in an application Server , I tried with OC4J and Tomcat the code like Weijun Tian explain I show two examples :
1st case : Supouse that I run a query to database like that : select name, price from tableTest ;
Statement stm = con.createStatement();
ResultSet rs = stm.executeQuery(�select name, price from tableTest�);
If the column �name� doesn�t exist or is incorrect writed I expect a SQLException well , that is right if I run a simple program with main method. But if I run the same query into a servlet , I have the problem of Fatal Internal Error I/EX without any explanation. This is running in OC4J now, if I run in Tomcat the same code I obtain :
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x6d442b44
Function name=JVM_DisableCompiler
Library=C:\jdk1.3.1_09\jre\bin\hotspot\jvm.dll
Current Java thread:
at oracle.lite.poljdbc.LiteEmbStatement.jniExecDirect(Native Method)
at oracle.lite.poljdbc.LiteEmbStatement.executeDirect(Unknown Source)
at oracle.lite.poljdbc.POLJDBCStatement.executeQuery(Unknown Source)
at com.next.jsptest.Product.getDetail(Producto.java:59)
at com.next.servlets.ControlServlet.doPost(ControlServlet.java:163)
�.
�.
In both of them (OC4J and Tomcat) the server is shut down after the problem.
2nd Case : Now, suppose another situation , imagine a field in the database that is null , well, after the rs.getString(�THE_FIELD�), I expected that the answer will be null ok, if I run this in a simple class with main method there is no problem but if I run the same in a servlet , well, the same problem! I/EX and server shutdown again with OC4J or Tomcat, the same problem.
I think that something like that happen with you Weijun Tian.
Well , what I think is that there is a problem with Oracle Lite to work with application servers, I don�t understand why works fine in simple programs with main method but when I run in a server the same query have these kind of errors , I really hope you can help me because I don�t want to tell that Oracle Lite doesn�t work with an application server or is not a good Database for web applications.
Thanks a lot!!!
PD . I also put here my posts to the metalink and forums.
21 / 10 / 2003
Hi there, I have the same problem but I found that there is not directed relation with the getString(),the problem is in general. Apparently the driver does not work with SQLException , for example I try to make update and I put a column that not exist I expected a SQLException but get the error Fatal internal error: I/EX and the server shut down (?).
I think that it dependes of the driver, I am using OLITE4.jar in windows 2000 and works fine but when I have a simple error (talking about JDBC) get the error I/EX and shut down the server. Could you help me with some advice around this??
21 / 10 / 2003
Also I found that when I use the driver in a simple program the SQLException is captured for the try-catch block but when the same query for example is running in the JDeveloper from a servlet using the server for test of JDeveloper the same exception produce the problem of Fatal internal error:I/EX , I tried the same code in a Tomcat server and this is what I get :
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x6d442b44
Function name=JVM_DisableCompiler
Library=C:\jdk1.3.1_09\jre\bin\hotspot\jvm.dll
Current Java thread:
at oracle.lite.poljdbc.LiteEmbStatement.jniExecDirect(Native Method)
at oracle.lite.poljdbc.LiteEmbStatement.executeDirect(Unknown Source)
at oracle.lite.poljdbc.POLJDBCStatement.executeQuery(Unknown Source)
at com.next.jsptest.Producto.getDetail(Producto.java:59)
at com.next.servlets.ControlServlet.doPost(ControlServlet.java:163)
at com.next.servlets.ControlServlet.doGet(ControlServlet.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at
and my server shut down as far as I know the driver olite40.jar is a JDBC-ODBC driver I think that this is the reason for the problem maybe if I use a driver type 4 I can work better but, is there other driver for Oracle Lite in windows 32??? type 4 could be a solution.

Fatal Internal Error

Fatal Internal Error in drawmgr2.cpp line 333 Labview version 7.1.1
This
is a repeatable crash when trying to open "Config Numeric
Comparison.vi" from the Mindstorm 1.1 "Blocks" directory. No option is
given to send a report.
-David

duplicate post: http://forums.ni.com/ni/board/message?board.id=beta18&thread.id=563&jump=true
LabVIEW Champion . Do more with less code and in less time .

Fatal internal error in JRockit

Hi,
I have been using & testing JRockit 7.0(1.4.0) and its been working fine so far.
I am running it on Win2K platform.
But rarely (say once in 20 times) when I run my application using JRockit jvm,
I get the error below.
===================================================================
Fatal internal error in JRockit. Thread 480 died abruptly
java.lang.NullPointerException
java.lang.NullPointerException:
-------end of stacktrace ===================================================================
Has anyone seen this before? Any idea why its happening?
Rgds
Thiru

Hi David,
Thanks for your response.
No, I am not using any native code in my application. But in my
application boot-up, I am spawning lot of threads (around 25).
I am not sure if using -Xthinthreads would help (I am not using
it)...but anyways I feel even if -Xnativethreads(default) is
used this error should not occur.
I guessed that this could be related to memory issue and then I tried to reproduce
this issue with a simple program where I was spawning 5 threads, and in a while
loop just sleeping.
The sample program is as below.
import java.io.*;
public class Memtest {
public static void main(String args[]) throws Exception{
int count = Integer.parseInt(args[0]);
for (int i=0; i<count; i++) {
InnerThread t = new InnerThread();
t.start();
static class InnerThread extends Thread {
public void run() {
System.out.println("Thread started....");
try {
while(true) {
Thread.currentThread().sleep(2000);
}catch(Exception e){
I kept on running this program with different min/max memory
values. I was running lot of other processes on my system and my
system was very low on memory(even virtual).
I saw the below error when I ran my sample program (after trying
it for nearly 2 hrs). Here if you notice, it was not able to
start even a single thread (As the thread started message din't
appear)
D:\Thiru\javatest\jrockit>C:\JRockit\7.0\1.4.0\bin\java -Xms205m -Xmx205m Memtest
5
===========================================================
[JRockit]Out-of-memory condition? : waiting for an available
stack
[JRockit]Out-of-memory condition? : waiting for an available
stack
[JRockit]Out-of-memory condition? : waiting for an available
stack
Fatal internal error in JRockit. Thread 380 died abruptly
java.lang.NullPointerException
java.lang.NullPointerException:
-------end of stacktrace
===================================================================
And then another time, I saw this other error (attached file jvm-
crash-04-dec) while running the same program, but this time my
system had enough free memory. So, I am not sure if this is
anything related to memory also but definitely feel is a bug in
JRockit.
Hope this information helps.
Rgds
Thiru
David Simms <[email protected]> wrote:
Hi Thiru,
I can't say as we have seen this one before. Perhaps if we had more
information we could work on finding the cause and produce a fix and/or
workaround for you.
Do you have any idea as to where in your code the problem is occuring
Does your application use native (JNI) code ?
If the problem seems completely random we could take a look at your
application.
Regards,
/David Simms
Thirumalesh C wrote:
Hi,
I have been using & testing JRockit 7.0(1.4.0) and its been workingfine so far.
I am running it on Win2K platform.
But rarely (say once in 20 times) when I run my application using JRockitjvm,
I get the error below.
===================================================================
Fatal internal error in JRockit. Thread 480 died abruptly
java.lang.NullPointerException
java.lang.NullPointerException:
-------end of stacktrace ===================================================================
Has anyone seen this before? Any idea why its happening?
Rgds
Thiru
[jvm-crash-04-dec.txt]

Fatal Internal Error : "ThEvent.cpp", line 209

Hi,
Any help with the following AddRef()/Release() issue would be most appreciated:
I'm a software developer working on a COM (ActiveX) object for use by e.g. C# (test ok) and LabVIEW clients. The object supports events; however, when events are accessed with the "Register Event Callback" block, LabVIEW does not free the object when the VI is finished, and upon subsequently closing LabVIEW, I receive the following dialog:
Fatal Internal Error : "ThEvent.cpp", line 209
LabVIEW version 8.6
You will lose any unsaved work. For assistance in resolving this problem, please relaunch LabVIEW, or contact National Instruments.
and log:
#Date: Fri, Nov 14, 2008 12:44:58 PM
#OSName: Windows NT
#OSVers: 5.1
#AppName: LabVIEW
#Version: 8.6
#AppKind: FDS
#AppModDate: 06/26/2008 05:25 GMT
source\mgcore\ThEvent.cpp(209) : DAbort:
$Id: //labview/branches/Saturn/dev/source/mgcore/ThEvent.cpp#6 $
0x00B129F6 - LabVIEW <unknown> + 0
0x0040F5C0 - LabVIEW <unknown> + 0
0x7719C351 - OLEAUT32 <unknown> + 0
0x7712DB25 - OLEAUT32 <unknown> + 0
0x77EF658C - RPCRT4 <unknown> + 0
0x77EF4BF3 - RPCRT4 <unknown> + 0
0x7717E724 - OLEAUT32 <unknown> + 0
0x77600C31 - ole32 <unknown> + 0
0x77600BDB - ole32 <unknown> + 0
0x7750F237 - ole32 <unknown> + 0
0x7750F15C - ole32 <unknown> + 0
0x7750FC79 - ole32 <unknown> + 0
0x77600E3B - ole32 <unknown> + 0
0x776009BC - ole32 <unknown> + 0
0x77600DF2 - ole32 <unknown> + 0
0x7750FCB3 - ole32 <unknown> + 0
0x7750FAE9 - ole32 <unknown> + 0
0x7E418734 - USER32 <unknown> + 0
0x7E418816 - USER32 <unknown> + 0
0x7E4189CD - USER32 <unknown> + 0
0x7E4196C7 - USER32 <unknown> + 0
0x0041E852 - LabVIEW <unknown> + 0
0x0042AB32 - LabVIEW <unknown> + 0
0x00A27592 - LabVIEW <unknown> + 0
0x00A2DC60 - LabVIEW <unknown> + 0
0x00E3A5B9 - LabVIEW <unknown> + 0
0x008F0FF6 - LabVIEW <unknown> + 0
0x008F0CDA - LabVIEW <unknown> + 0
0x008F0EFB - LabVIEW <unknown> + 0
0x008F0F40 - LabVIEW <unknown> + 0
0x015AB20D - LabVIEW <unknown> + 0
0x7C816FD7 - kernel32 <unknown> + 0
0x00000000 - LabVIEW <unknown> + 0

I've attached a minimal COM server (that starts a thread when events are requested) that shows the issue. Steps to reproduce with LabVIEW 8.6 on Windows XP for x86 follow(stuff in parenthesis are comments):
(1) unzip HelloClass.zip to C:\ (4 files: hello.vi, callback.vi, HelloClass.dll, Hello.tlb)
(2) C:\>regsvr32 helloclass.dll (should get "DLLRegisterServer in helloclass.dll suceeded." dialog)
(3) C:\>hello.vi (start LabVIEW)
(4) Ctrl+R (run the VI. You should see "Command: test" in the String Indicator. At this point the last call into the server is AddRef() but should be Release())
(5) Alt+F4 (close the VI)
(6) Alt+F4 (close LabVIEW)
You may need to perform steps 3-6 up to ~10 times, because at this point one of 3 behaviors randomly occurs:
(A) Fatal Internal Error : "ThEvent.cpp", line 209
(B) Release() is finally called the same # of times as AddRef(), causing the destructor ~HelloClass to run (which kills the thread). This should instead happen after step 4 (which it does if you remove the "Reg Event Callback" block)
(C) Release() is called several times, but not enough to decrement the reference count to 0
Behavior A doesn't occur if the server doesn't start the thread. In source.zip, I've also attached the server's source code for your R&D team along with dbgMon, which is useful for looking at the _RPTF debug output. Thanks much for your patience and for looking at this.
Attachments:
HelloClass.zip ‏84 KB
source.zip ‏173 KB

Fatal Internal Error source/manager/thread.cpp line 3472 while starting LabVIEW

When I try to begin LabVIEW 7.1.1 on my mac OS X 10.4, I see the LV logo and then I get the pop-up window:
LabVIEW.app Alert
Fatal Internal Error: "source/manager/thread.cpp", line 3472
LabVIEW version 7.1.1
You will lose any unsaved work. For assistance in resolving this
problem, please relaunch LabVIEW, or contact National Instruments.
When I click on Continue, it kills LabVIEW. I also get 2 other
windows...one says Investigate Previous Internal Error...which does not
do anything, irrespective of what I click in that window.
The other window is called Controls.
The last message I see on the LabVIEW splash screen is Server: Exported VIs list ok.
The LV website says I need to make DLLs re-entrant, but I can't even begin LV to solve this problem.
Any suggestions?

Hi Enduro,
I would suggest creating a service request for this problem at ni.com/ask. The Applications Engineer will be interested in looking at the error log that is being created, so that we can determine if this problem has occurred before.
Amanda Howard
Americas Services and Support Recruiting Manager
National Instruments

Fatal Internal error: "oleautomgr.cpp", line 2832 when sending data by means of ActiveX methode

I have experienced error "Fatal Internal error: "oleautomgr.cpp", line 2832" during sending data to CAN card IXXAT iPCI-I XC16/PCI. LabVIEW communicates with that card by means of ActiveX methodes via "VCI Wrapper" which is COM object interface. Mass compiling of the project does not help. Card is initialized and configured propely. The driver card is working propely.
LabVIEW version is 8.5
The efect of that error is that labview completly shot down.
I appraciate any suggetions
thanks a lot

Hello,
Please try to reinstall the drivers for the CAN card, then make sure you close all references to the ActiveX control (at all levels) using the Automation Close primitive in LabVIEW.
Regards,
Emil

Receive "Fatal Internal Error: Linker.cpp, line 1926 when run executable.

Hi, I use invoke node to call multiple subvi.vit, it work fine under .vi but when run under an executable I receive this error:
Fatal Internal Error: 'linker.cpp", line 1926
LabVIEW Version 7.0 You will lose any unsaved work. For more assistance in resolving this problem, please relaunch LabVIEW, or contact National Instruments.
Any suggestion will be very appreciated

Hi David,
What you are seeing is a known issue when calling LabVIEW 7.0 VITs from
an executable or DLL if the VITs include any Express VIs. It can happen if you
try to load
multiple instances of that template VI using VI Server.
There are a couple of workarounds for this issue:
Take
all the express VIs that are inside the template VI and turn them into
static subVIs. You can do this by right-clicking on the express VI and
selecting "Open Front Panel"; then save the express VI as a normal
subVI.
Build the entire application into a single executable, which will force all of the express VIs to get compiled as static subVIs.
Don't use the runtime engine at all and always run your application in development mode.
Let me know if the workarounds fix your issue, thanks.
Good luck!
- Philip Courtois, Thinkbot Solutions

Fatal Internal Error : "OMUDClassMgr.cpp". Line 1128

I received the following message:
Fatal Internal Error : "OMUDClassMgr.cpp", 1128
LabVIEW version 8.2.1
I was trying to build an application using the application builder.
Has anyone else had this issue? What needs to be done to fix this.

Hello,
This was reported to R&D (#4ALB7O89) for further investigation. Are you able to reproduce this problem with the same VI? Are you able to build an application with a simple VI?
Regards,
Elizabeth S.
Applications Engineer
National Instruments

"Error 0001: Fatal Internal Error" in System Generator

Hi, I get the following error when I try to import data using the model explorer in Simulink. --------------------------------- Version Log ----------------------------------
Version                                 Path
System Generator 10.1.1134              C:/Xilinx/10.1/DSP_Tools/common/bin/../../sysgen
AccelDSP 10.1.1134                      C:/Xilinx/10.1/DSP_Tools/common/bin/../../AccelDSP
Matlab 7.5.0.342 (R2007b)               C:/Program Files/MATLAB/R2007b
ISE 10.1.i                              c:/Xilinx/10.1/ISE
Summary of Errors:
Error 0001: Fatal Internal Error
     Block: 'xlfsm_controller_simulation_test/Gateway In1'
--------------------------------------------------------------------------------Error 0001:Reported by:
'xlfsm_controller_simulation_test/Gateway In1'Details:
An internal error occurred in the Xilinx Blockset Library.Please report this error to Xilinx (http://support.xilinx.com),
in as much detail as possible. You may also find immediate help
in the Answers Database and other online resources at http://support.xilinx.com.Since it is possible that this internal error resulted from an
unhandled usage error in your design, we advise you to carefully
check the usage of the block reporting the internal error. If
errors persist, we recommend that you restart MATLAB.
-------------------------------------------------------------------------------- When I used the "From Workspace" block in Simulink to import data, the model executed without any errors. I don't know what am I doing wrong. I am new to System Generator. Could someone please give me some help??? Thanks in Advance

check this discussion
http://forums.xilinx.com/t5/DSP-Tools/System-Generator-Fatal-Internal-Error-Help-SOLVED/m-p/150010
http://forums.xilinx.com/t5/DSP-Tools/an-internal-error-occurred-in-the-xilinx-blockset-library/m-p/383207#M7366

Changing numeric control representa​tion causes fatal internal error.

Similar Messages

Maybe you are looking for

Changing numeric control representation causes fatal internal error.