Compiler Crashes!!

Hi,
I'm using J2sdk1.4.1 on Windows XP pro. When I compile my code, the compiler crashes! It seems to work sometimes, and not others, and I think it tends to crash when I'm importing and using items from javax.swing.*
Here's what comes up when I try to compile:
C:\Documents and Settings\Claire\Desktop\Claire\school\Birmingham\Team Java>javac UserInterface.java
Unexpected Signal : EXCEPTION_FLT_STACK_CHECK occurred at PC=0xBBD0D2
Function=[Unknown.]
Library=(N/A)
NOTE: We are unable to locate the function name symbol for the error
just occurred. Please refer to release documentation for possible
reason and solutions.
Current Java thread:
Dynamic libraries:
0x00400000 - 0x00408000 c:\j2sdk1.4.1\bin\javac.exe
0x77F50000 - 0x77FF7000 C:\WINDOWS\System32\ntdll.dll
0x77E60000 - 0x77F46000 C:\WINDOWS\system32\kernel32.dll
0x77DD0000 - 0x77E5D000 C:\WINDOWS\system32\ADVAPI32.dll
0x78000000 - 0x78086000 C:\WINDOWS\system32\RPCRT4.dll
0x77C10000 - 0x77C63000 C:\WINDOWS\system32\MSVCRT.dll
0x00280000 - 0x002F4000 C:\DOCUME~1\Claire\LOCALS~1\Temp\ata6.tmp
0x77340000 - 0x773CB000 C:\WINDOWS\system32\COMCTL32.DLL
0x77C70000 - 0x77CB0000 C:\WINDOWS\system32\GDI32.dll
0x77D40000 - 0x77DCC000 C:\WINDOWS\system32\USER32.dll
0x71B20000 - 0x71B31000 C:\WINDOWS\system32\MPR.DLL
0x771B0000 - 0x772D1000 C:\WINDOWS\system32\OLE32.DLL
0x77120000 - 0x771AB000 C:\WINDOWS\system32\OLEAUT32.DLL
0x71AD0000 - 0x71AD8000 C:\WINDOWS\System32\WSOCK32.DLL
0x71AB0000 - 0x71AC5000 C:\WINDOWS\System32\WS2_32.dll
0x71AA0000 - 0x71AA8000 C:\WINDOWS\System32\WS2HELP.dll
0x6D330000 - 0x6D45C000 c:\j2sdk1.4.1\jre\bin\client\jvm.dll
0x76B40000 - 0x76B6C000 C:\WINDOWS\System32\WINMM.dll
0x6D1D0000 - 0x6D1D7000 c:\j2sdk1.4.1\jre\bin\hpi.dll
0x6D300000 - 0x6D30D000 c:\j2sdk1.4.1\jre\bin\verify.dll
0x6D210000 - 0x6D229000 c:\j2sdk1.4.1\jre\bin\java.dll
0x6D320000 - 0x6D32D000 c:\j2sdk1.4.1\jre\bin\zip.dll
0x76C90000 - 0x76CB2000 C:\WINDOWS\system32\imagehlp.dll
0x6D510000 - 0x6D58D000 C:\WINDOWS\system32\DBGHELP.dll
0x77C00000 - 0x77C07000 C:\WINDOWS\system32\VERSION.dll
0x76BF0000 - 0x76BFB000 C:\WINDOWS\System32\PSAPI.DLL
Local Time = Wed Mar 19 16:26:13 2003
Another exception has been detected while we were handling last error.
Dumping information about last error:
ERROR REPORT FILE = (N/A)
PC = 0x00BBD0D2
SIGNAL = -1073741678
FUNCTION NAME = (N/A)
OFFSET = 0xFFFFFFFF
LIBRARY NAME = (N/A)
Please check ERROR REPORT FILE for further information, if there is any.
Good bye.
C:\Documents and Settings\Claire\Desktop\Claire\school\Birmingham\Team Java>
Anyone got any ideas?
Claire

Hello,
We have similar java crash on HP-UX 11.11 (with all latest OS and java patches). The funny thing is that we able to run java as "root", but we won't able to run java as local users. We checked possible environment issue, but did not find anything what could be a problem. We also reinstalled java 1.4 on that machine - it did not fix the problem. Also we tried this: we installed Java 1.3 - works with all users, Java 1.2 - works with all users. With Java 1.4 , we are getting this:
$ java -version
Another exception has been detected while we were handling last error.
Dumping information about last error:
ERROR REPORT FILE = (N/A)
PC = c52227cb
SIGNAL = 11
FUNCTION NAME = (N/A)
OFFSET = 0xFFFFFFFF
LIBRARY NAME = (N/A)
Please check ERROR REPORT FILE for further information, if there is any.
Good bye.
Abort
$ which java
/usr/lnms/bin/java
$ id
uid=104(onmsorcl) gid=104(oinstall)
$
$ exit
root@titania > java -version
java version "1.4.2.00"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2.00-031015-15:06)
Java HotSpot(TM) Server VM (build 1.4.2 1.4.2.00-031015-16:52-PA_RISC2.0 PA2.0,
mixed mode)
Any ideas?
Yulia

Similar Messages

Annotation-caused compiler crash

Hi,
When attempting to build against a class that uses runtime annotations, javac is crashing with:
An exception has occurred in the compiler (1.6.0-rc). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you.
com.sun.tools.javac.code.Symbol$CompletionFailure: class file for test.annotation.TestAnnotation not found
The test case that generates this error can be found at:
http://www.cjtucker.com/annotation-bug.tgz
Synopsis:
Attempting to build against a class that contains a runtime annotation requires the definition of the annotation to be available to the compiler. If the definition is not available, the compiler crashes.
Test case:
The test case attempts to build three classes in three separate packages: a simple RUNTIME scoped annotation, a "core" class, and a "ui" class that builds against the core class. The "ui" class neither knows nor cares about the annotated properties of the "core" class. The annotation class is build in isolation; the core class is built only against the annotation class; the ui class is built only against the core class.
The test case tarball contains the necessary .java files and directory structure for compilation. The compilation commands are contained in compile.sh.
The crash can be avoided by including the annotation class in the classpath when building the ui component. The crash has been reproduced in 1.5.0_04, 1.5.0_05, and 1.6.0b61. Other JDKs have not been tested. The crash occurs with both RUNTIME and CLASS scoped annotations, though not with SOURCE scope (as expected: the compiler is correctly stripping annotations in that case). The crash does not occur if the annotation does not take parameters (i.e. is an empty "marker" annotation).
This raises some additional questions I'd be interested in hearing comment on. What is the expected behavior here? I would expect the annotation class should not be required as a dependency, in the same way I'm not expected to declare a dependency on every class used by a class I interact with. This behavior with annotations seems to breach encapsulation (for example, a client would have to know that my libraries happened to be using a Hibernate persistence layer whether or not this is of interest to them). Perhaps one of the Java gurus here could shed some further light on this?
Cheers,
Chris Tucker

Hi,
I know this is an old post but I am having the exact same problem with 1.6.0_11 and have not been able to find a solution.
Any assistance would be much appreciated.
Thanks.

IDL compiler crashes when......

Hi,
I've found that the IDL compiler crashes when trying to compile an idl that contains
a declaration similar to the following:
struct S {
union U switch(long) {
case 1:
long a;
case 2:
short b;
} y;
The crash occurs with both NT and Solaris 8 versions of Tuxedo 8.0's $TUXDIR/bin/idl
that I've tried.
Any ideas?
Thanks,
Dave.

Dave,
Looks strange... I suggest that you open a case with BEA support.
Regards,
Peter.
David Watson wrote:
Hi,
I've found that the IDL compiler crashes when trying to compile an idl that contains
a declaration similar to the following:
struct S {
union U switch(long) {
case 1:
long a;
case 2:
short b;
} y;
The crash occurs with both NT and Solaris 8 versions of Tuxedo 8.0's $TUXDIR/bin/idl
that I've tried.
Any ideas?
Thanks,
Dave.

Compiler Crash: Volatile Bit Fields (reading)

Can anyone verify that this crashes the Studio 12 C++ compiler?
typedef struct {
#if defined(CRASH)
    volatile int crash : 1;
#else
              int crash : 1;
#endif
} Flags_t;
int main()
    Flags_t Flags = {0};
    return Flags.crash; /* reading the volatile bit-field causes the compiler crash */
}With cc, it compiles fine, and it compiled fine up until some recent patch with CC. 124863-01 seems to work but 124863-03 results in a compiler SEGV.
Edited by: Mike_Morgan on Apr 17, 2008 2:44 PM
You'll need to use: -DCRASH to see the compiler SEGV.

Thanks for filing the bug report. It is CR 6690835, which should be visible at bugs.sun.com in a day or two.

CVI 2010 compiler crash

This short piece of code below causes compiler crash in CVI 2010 - in CVI9.0 it works fine.
Thanks for help.
jirjan
/* Compiler Crash example, CVI 2010 - v10.0.0 */
static void fctDummy1(void) {};
static void fctDummy2(void) {};
typedef struct tagMyStruct
void (*DummyFunction1) ( void );
void (*DummyFunction2) ( void );
} tMyStruct;
     tMyStruct MyFctStruct         = {fctDummy1, fctDummy2};
const tMyStruct MyConstFctStruct = {fctDummy1, fctDummy2};
void MyTest(void)
   MyFctStruct.DummyFunction1();
   MyFctStruct.DummyFunction2();
   /* this line doesn't cause the compiler crash...!!*/
   MyConstFctStruct.DummyFunction1();
   /* BUT next line caused the compiler crash...!!*/
   MyConstFctStruct.DummyFunction2();

It is a very simple project with one source file only - sending in attachment (adapt to your project path or create simple project with .c file)..As I wrote before - with CVI9.0 (and/or any C compiler) I can compile the source file, CVI 2010 crashes while compiling..
Thanks for your time
Jiri
Attachments:
CompilerTest.zip ‏3 KB

Problem with compilation crashing

Hi,
I'm having an issue with RH9 when I try to compile a CHM.
Fo a start, it's getting very agitated about the variable code for some reason, but just for the master topic:
Normal2.htt :
The HTML tag "?rh-variable_start name="title" format="default" v..." is not a valid HTML tag (it does not begin with an alphanumeric character).
But it also hates a lot of my images:
Button_Print_Preview.gif :
The HTML tag "ïMž\ã|ÅR£dPœ$s …U„ ]¸y\¸Ù³w®›,[‘”<‹ ÈÈ”CÆ ¢J„f‹œ Þ..." is not a valid HTML tag (it does not begin with an alphanumeric character).
I've checked the image, there is no HTML even close to it like the compiler is describing.
When it gets part way through the images it crashes.
The images were made with PSP 4 and 8 (I'm having trouble getting funding for newer versions) and have transparent sections.
If I rename and replace the image names that sometimes work in clearing the issue, and sometimes not. I've tried remaking them...no dice.
There is nothing in the HTML to suggest what could be tripping up the compiler, is this an IE9 issue?
To further complicate things, this is a file that was once RH9, then had to be downgraded to 8, then upgraded to 9.
It's also a template for WebHelp that I've stripped back down to complied help. I'm pretty sure that any of those things could have screwed it up, but I just can't see what has screwed up!
For example:
HHC3002: Warning:
Button_Print_Preview.gif :
The HTML tag "c" is missing a closing angle bracket.
The code is:
Tip: You can use <img src="../../Images/Button_Print_Preview.gif" alt="Button_Print_Preview.gif" style="border: none;" border="0" /> Print Preview to view the data you are about to print out.
I've 'deleted' the XPJ, no effect. Any ideas?
I'm on Windows 7, with IE9
Nicola

Hi William,
2. The HTML tag for the print image is just a lof of gibberish. Is that exactly what you're seeing?
I can't view the output because the compiler crashes before it can generate the CHM. I can generate WebHelp without these issues.
- Are your project AND your output directory both on your local drive?
Yes.
- Do you use long filenames/folder names? Long file paths may give trouble.
Typical path: "../../Images/Button_DocumentsStandard.gif"
I don't think that's excessive!
- You have deleted the XPJ. Have you also tried deleting the CPJ? Make a full backup, remove the CPJ and open the project again.
Can't find a CPJ, did you mean the CPD?? I've done that, no change.
- Can you run the W3C compliance tool to see what problems might be in your code? (File > W3C Compliance > Validate all)
I could, do you mean on the source or output? I don't have the output code (RH deletes it), and the source looks ok to me... nothing fancy.
- You say this is a 'file' that was RH9, went back to RH8 and is now back to RH9. Do you mean a single file or the entire project? What did you do to 'downgrade' the file/project?
Sorry, the project got downgraded. I can't remember what I did to downgrade it, this was a while ago.
If you get errors that certain tags are incomplete, there might be something wrong with the code in your topics.
I agree with this, but can't see anything wrong with the code.
Thanks,
Nicola

JVM Hotspot compiler crashed

Hello,
The JVM crashed in one of our Solaris production environments. The cause of the crash appears to be the HotSpot compiler. It seems that the JVM was trying to compile frequently used code and then it crashed. I have checked the forums and I found one other message with the same Internal Error ID. However, in that message, it is suggested that the JVM itself is running out of C malloc space (http://forum.java.sun.com/thread.jspa?forumID=37&threadID=5127551).
I have verified that the JVM was not running out of memory when it crashed. There was over 9 GB of swap and physical memory available to the JVM when the crash happened.
Below are the contents of the hs_err_pid file.
# An unexpected error has been detected by HotSpot Virtual Machine:
# Internal Error (434F44452255464645520E4350500060 01), pid=2355, tid=13
# Java VM: Java HotSpot(TM) Server VM (1.5.0_07-b03 mixed mode)
--------------- T H R E A D ---------------
Current thread (0x0017fcb8): JavaThread "CompilerThread0" daemon [_thread_in_native, id=13]
Stack: [0xa2300000,0xa2380000), sp=0xa237e370, free space=504k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x6f5644]
V [libjvm.so+0x4369b0]
V [libjvm.so+0x1b5140]
V [libjvm.so+0x21b8b0]
V [libjvm.so+0x227b70]
V [libjvm.so+0x224ce4]
V [libjvm.so+0x21ab78]
V [libjvm.so+0x282d78]
V [libjvm.so+0x278d04]
V [libjvm.so+0x2799c0]
V [libjvm.so+0x336548]
V [libjvm.so+0x2deae8]
V [libjvm.so+0x6691b0]
Current CompileTask:
opto:4113 gov.nist.javax.sip.stack.SIPDialog.setLastResponse(Lgov/nist/javax/sip/stack/SIPTransaction;Lgov/nist/javax/sip/message/SIPResponse;)V (954 bytes)
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x01a70548 JavaThread "RMI ConnectionExpiration-[90.0.64.65:49888]" daemon [_thread_blocked, id=121153]
0x01d8a5e0 JavaThread "RMI RenewClean-[90.0.64.65:49888]" daemon [_thread_blocked, id=5835]
0x005433e0 JavaThread "Thread-29" [_thread_in_native, id=1227]
0x0110a820 JavaThread "Thread-30" [_thread_blocked, id=1226]
0x016d2ae8 JavaThread "RMI RenewClean-[90.0.64.64:32827]" daemon [_thread_blocked, id=167]
0x00d31a28 JavaThread "UDPMessageChannelThread" daemon [_thread_blocked, id=120]
0x0151a1a8 JavaThread "UDPMessageProcessorThread" daemon [_thread_in_native, id=119]
0x01519f38 JavaThread "MitelTCPServer" [_thread_in_native, id=118]
0x00f1ced8 JavaThread "MitelTCPHandler" [_thread_in_native, id=117]
0x00f1d478 JavaThread "MinetEncryptedServer" [_thread_blocked, id=116]
0x00f1afb8 JavaThread "JainMgcpStackImpl" [_thread_in_native, id=115]
0x0079baf0 JavaThread "Thread-24" daemon [_thread_blocked, id=113]
0x00d22018 JavaThread "Thread-20" daemon [_thread_blocked, id=111]
0x00d21e50 JavaThread "Thread-18" daemon [_thread_blocked, id=110]
0x008e4090 JavaThread "Thread-15" [_thread_in_native, id=73]
0x01069af8 JavaThread "Thread-16" [_thread_blocked, id=72]
0x010e5720 JavaThread "Thread-14" [_thread_blocked, id=69]
0x000388d8 JavaThread "DestroyJavaVM" [_thread_blocked, id=1]
0x01e6b3b0 JavaThread "RTSEngine Watchdog" [_thread_blocked, id=68]
0x007826e0 JavaThread "RTSEngine" [_thread_in_Java, id=67]
0x00be1cd8 JavaThread "DBEngine Watchdog" [_thread_blocked, id=66]
0x00bdde38 JavaThread "DBEngine" [_thread_blocked, id=65]
0x00fc8a08 JavaThread "DefaultDomain:class=SnmpV3AdaptorServer,protocol=snmp,port=8163" [_thread_in_native, id=63]
0x00605e60 JavaThread "DefaultDomain:class=HtmlAdaptorServer,protocol=html,port=9001" [_thread_in_native, id=62]
0x001f98a0 JavaThread "CDR Processor" [_thread_blocked, id=61]
0x00fcb680 JavaThread "Python Server" [_thread_in_native, id=60]
0x00a15bc0 JavaThread "CDR File Manager" [_thread_blocked, id=59]
0x00542bb0 JavaThread "MemoryLogger" [_thread_blocked, id=58]
0x00541d20 JavaThread "Globals Executioner" [_thread_blocked, id=57]
0x00a16068 JavaThread "Remote Command Executioner" [_thread_blocked, id=56]
0x0157ab78 JavaThread "CallpAuditor" [_thread_blocked, id=55]
0x00664068 JavaThread "VACommClient" [_thread_blocked, id=54]
0x003f34e0 JavaThread "Thread-11" [_thread_blocked, id=50]
0x005844a8 JavaThread "Thread-10" daemon [_thread_blocked, id=34]
0x00f95e60 JavaThread "RMI LeaseChecker" daemon [_thread_blocked, id=32]
0x010821f0 JavaThread "GC Daemon" daemon [_thread_blocked, id=30]
0x00587928 JavaThread "RMI Reaper" [_thread_blocked, id=29]
0x015fd208 JavaThread "Timer-3" [_thread_blocked, id=28]
0x009b4200 JavaThread "EventScannerThread" [_thread_blocked, id=27]
0x006df418 JavaThread "Timer-2" [_thread_blocked, id=26]
0x0051d958 JavaThread "MemoryHandlerEx" [_thread_blocked, id=20]
0x0035cef8 JavaThread "RMI TCP Accept-4003" daemon [_thread_in_native, id=18]
0x00357d70 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=17]
0x003555c8 JavaThread "Timer-0" daemon [_thread_blocked, id=16]
0x00181d90 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=15]
0x00180c10 JavaThread "CompilerThread1" daemon [_thread_blocked, id=14]
=>0x0017fcb8 JavaThread "CompilerThread0" daemon [_thread_in_native, id=13]
0x0017e370 JavaThread "AdapterThread" daemon [_thread_blocked, id=12]
0x0017d1e8 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=11]
0x0017c118 JavaThread "JDWP Event Helper Thread" daemon [_thread_blocked, id=10]
0x00174030 JavaThread "JDWP Transport Listener: dt_socket" daemon [_thread_in_native, id=9]
0x00171420 JavaThread "Surrogate Locker Thread (CMS)" daemon [_thread_blocked, id=8]
0x00164aa8 JavaThread "Finalizer" daemon [_thread_blocked, id=7]
0x00164568 JavaThread "Reference Handler" daemon [_thread_blocked, id=6]
Other Threads:
0x00162488 VMThread [id=5]
0x003b28f0 WatcherThread [id=19]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap
par new generation total 7424K, used 3798K [0xa5800000, 0xa6000000, 0xa6000000)
eden space 6656K, 45% used [0xa5800000, 0xa5af5b48, 0xa5e80000)
from space 768K, 100% used [0xa5e80000, 0xa5f40000, 0xa5f40000)
to space 768K, 0% used [0xa5f40000, 0xa5f40000, 0xa6000000)
concurrent mark-sweep generation total 1220608K, used 354273K [0xa6000000, 0xf0800000, 0xf0800000)
concurrent-mark-sweep perm gen total 46400K, used 27804K [0xf0800000, 0xf3550000, 0xf8800000)
Dynamic libraries:
0x00010000      /usr/jdk1.5.0_07/bin/java
0xff370000      /usr/lib/libthread.so.1
0xff3fa000      /usr/lib/libdl.so.1
0xff280000      /usr/lib/libc.so.1
0xff3a0000      /usr/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1
0xfe800000      /usr/jdk1.5.0_07/jre/lib/sparc/server/libjvm.so
0xff240000      /usr/lib/libsocket.so.1
0xff220000      /usr/lib/libsched.so.1
0xff1f0000      /usr/lib/libCrun.so.1
0xff1a0000      /usr/lib/libm.so.1
0xff080000      /usr/lib/libnsl.so.1
0xff170000      /usr/lib/libmp.so.2
0xff050000      /usr/jdk1.5.0_07/jre/lib/sparc/native_threads/libhpi.so
0xfe7b0000      /usr/jdk1.5.0_07/jre/lib/sparc/libjdwp.so
0xfe770000      /usr/jdk1.5.0_07/jre/lib/sparc/libverify.so
0xfe720000      /usr/jdk1.5.0_07/jre/lib/sparc/libjava.so
0xfe700000      /usr/jdk1.5.0_07/jre/lib/sparc/libzip.so
0xfbfb0000      /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2
0xfbf90000      /usr/jdk1.5.0_07/jre/lib/sparc/libdt_socket.so
0xfbee0000      /usr/lib/nss_files.so.1
0xfbec0000      /usr/jdk1.5.0_07/jre/lib/sparc/libmanagement.so
0xfbdd0000      /usr/jdk1.5.0_07/jre/lib/sparc/libnet.so
0xf8ab0000      /usr/jdk1.5.0_07/jre/lib/sparc/libnio.so
0xf8a90000      /usr/lib/librt.so.1
0xf8860000      /usr/lib/libaio.so.1
0xf8840000      /usr/lib/libmd5.so.1
0xf8820000      /usr/lib/libsendfile.so.1
0xa57e0000      /usr/jdk1.5.0_07/jre/lib/sparc/librmi.so
0x9dc00000      /nci/vks.2.0.9.0.1/callp/libmgcpca.so.3.0.0.0.0
0xa5690000      /usr/local/lib/libstdc++.so.2.10.0
VM Arguments:
jvm_args: -XX:+UseISM -Xms1200m -Xmx1200m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -XX:+CMSParallelRemarkEnabled -XX:+DisableExplicitGC -XX:MaxPermSize=128m -XX:SurvivorRatio=8 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:-TraceClassUnloading -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=4001 -Dcom.sun.management.jmxremote.port=4003 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.password.file=/nci/vks/callp/jmxremote.password -Dnci.callp.state=2
java_command: com.nci.callp.MainApplication
Launcher Type: SUN_STANDARD
Environment Variables:
JAVA_HOME=/usr/java
CLASSPATH=:/usr/java/lib/tools.jar:/usr/java/jre/lib/rt.jar:.:/nci/vks/lib/bitlib.jar:/nci/vks/lib/nist.jar:/nci/vks/lib/antlrall.jar:/nci/vks/lib/common.jar:/nci/vks/lib/jconn2.jar:/nci/vks/callp/callp.jar:/nci/vks/callp/lib/3comlib.jar:/nci/vks/callp/lib/jcert.jar:/nci/vks/callp/lib/jnet.jar:/nci/vks/callp/lib/jsse.jar:/nci/vks/callp/lib/mitellib.jar:/nci/vks/mediaserver/mediaserver.jar:/nci/vks/snmp/snmp.jar:/nci/vks/snmp/lib/solaris/jdmkrt.jar:/nci/vks/snmp/lib/solaris/jdmktk.jar:/nci/vks/snmp/lib/solaris/jsnmpapi.jar:/nci/vks/auditor/auditor.jar:.:/nci/vks/lib/bitlib.jar:/nci/vks/lib/nist.jar:/nci/vks/lib/antlrall.jar:/nci/vks/lib/common.jar:/nci/vks/lib/jconn2.jar:/vks_shared/callp/resources:/nci/vks/callp/callp.jar:/nci/vks/callp/lib/3comlib.jar:/nci/vks/callp/lib/jcert.jar:/nci/vks/callp/lib/jnet.jar:/nci/vks/callp/lib/jsse.jar:/nci/vks/callp/lib/mitellib.jar:/nci/vks/callp/lib/cpl.jar:/nci/vks/callp/lib/asbsdk.jar:/nci/vks/mediaserver/mediaserver.jar:/nci/vks/snmp/snmp.jar:/nci/vks/snmp/lib/solaris/jdmkrt.jar:/nci/vks/snmp/lib/solaris/jdmktk.jar:/nci/vks/snmp/lib/solaris/jsnmpapi.jar:/nci/vks/lib/commons-collections-3.0.jar:/nci/vks/lib/commons-lang-2.0.jar:/nci/vks/lib/jython.jar:/nci/vks/lib/castor-0.9.7.jar:/usr/java/lib/tools.jar:/nci/vks/lib/commons-logging-1.0.3.jar://nci/vks/lib/common.nist.jar://nci/vks/lib/concurrent.jar://nci/vks/lib/log4j-1.2.8.jar
PATH=/nci/sybase/SYBSsa9/bin32:/nci/sybase/shared9/sybcentral43:/usr/sbin:/usr/bin:/nci/sybase/SYBSsa9/bin:/usr/sbin:/opt/SUNWcgha/sbin:/nci/vks/bin:/usr/local/bin:/usr/ccs/bin:/opt/SUNWcgha/sbin:/nci/mysql/bin
LD_LIBRARY_PATH=/usr/jdk1.5.0_07/jre/lib/sparc/server:/usr/jdk1.5.0_07/jre/lib/sparc:/usr/jdk1.5.0_07/jre/../lib/sparc:/nci/sybase/SYBSsa9/lib32:/nci/sybase/SYBSsa9/lib64:/nci/sybase/SYBSsa9/jre142/lib/sparc/client:/nci/sybase/SYBSsa9/jre142/lib/sparc:/nci/sybase/SYBSsa9/jre142/lib/sparc/native_threads:/nci/sybase/SYBSsa9/drivers/lib::/usr/lib:/nci/sybase/SYBSsa9/lib:/usr/local/lib
SHELL=/usr/bin/bash
HOSTTYPE=sparc
OSTYPE=solaris2.9
MACHTYPE=sparc-sun-solaris2.9
Signal Handlers:
SIGSEGV: [libjvm.so+0x6f60b8], sa_mask[0]=0x7fbffeff, sa_flags=0x00000004
SIGBUS: [libjvm.so+0x6f60b8], sa_mask[0]=0x7fbffeff, sa_flags=0x00000004
SIGFPE: [libjvm.so+0x276398], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c
SIGPIPE: [libjvm.so+0x276398], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c
SIGILL: [libjvm.so+0x276398], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c
SIGUSR1: [libjvm.so+0x66b714], sa_mask[0]=0x00000000, sa_flags=0x00000008
SIGUSR2: [libjvm.so+0x276398], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c
SIGHUP: [libjvm.so+0x66a38c], sa_mask[0]=0x7fbffeff, sa_flags=0x00000004
SIGINT: SIG_IGN, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGQUIT: [libjvm.so+0x66a38c], sa_mask[0]=0x7fbffeff, sa_flags=0x00000004
SIGTERM: [libjvm.so+0x66a38c], sa_mask[0]=0x7fbffeff, sa_flags=0x00000004
--------------- S Y S T E M ---------------
OS: Solaris 9 9/04 s9s_u7wos_09 SPARC
Copyright 2004 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 29 June 2004
uname:SunOS 5.9 Generic_118558-28 sun4u (T2 libthread)
rlimit: STACK 8192k, CORE infinity, NOFILE 65536, AS infinity
load average:0.49 0.59 0.61
CPU:total 2 has_v8, has_v9, has_vis1, has_vis2, is_ultra3
Memory: 8k page, physical 4194304k(839536k free)
vm_info: Java HotSpot(TM) Server VM (1.5.0_07-b03) for solaris-sparc, built on May 3 2006 01:22:35 by unknown with unknown Workshop:0x550

0x00181d90 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=15]
0x00180c10 JavaThread "CompilerThread1" daemon [_thread_blocked, id=14]
=>0x0017fcb8 JavaThread "CompilerThread0" daemon [_thread_in_native, id=13]
0x0017e370 JavaThread "AdapterThread" daemon [_thread_blocked, id=12]
0x0017d1e8 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=11]upgrade ur java to 1.5u11, this may solve the problem
the application is crashing in compiler thread.
the easiest workaround is to use -server or -client (vice versa) and check with which option your application doesn't crash.

WebHelp compile crashes in RH8 and RH6

I am currently evaluating Version 8 of Robohelp and would like to get all my projects on the same version of Robohelp. Most of my projects are at Version 6. I have another project that is currently at Version x.41 that I would like to upgrade and was testing it to see how it runs with Version 8. The X4.1 project converted to Version 8 without a hitch but when I compiled the WebHelp , it crashed and I received the following error: “Adobe Robohelp 8 has encountered a problem and needs to close. “ Here are the details:
AppName: robohtml.exe
AppVer: 8.0.0.203
ModName: msvcr80.dll
ModVer: 8.0.50727.3053
Offset: 0008aa0
After researching the error on line, I found that it was the conditional build statement that was causing the crash. When I compiled the WebHelp without the conditional build statement, it compiled just fine. I could not find any help on line for dealing with this error for Version 8 so I made a new copy of the project and converted it to Version 6, which apparently had a patch I can download. I applied the patch that was in Peter Grainge’s site to my copy of Robohelp 6. The X4.1 project opened without a hitch in Version 6. But when I compiled the WebHelp, it crashed again with the same error – even with the patch installed. Here are the error details:
AppName: robohtml.exe
AppVer: 6.0.99.0
ModName: msvcr80.dll
ModVer: 8.0.50727.3053
Offset: 0008aa0
Can someone please shed some light into this? I really would like to have all my RH projects at the same version.
Thanks!

The TOC and Index might be easier than you think. In RH8 you can create a TOC and Index that is a copy of another one. This works well with TOCs and Indexes in the same project but usually a TOC or Index in another project will have different links to topics so they will be pretty useless. If you create exactly the same folders though, then you might be able to copy the old TOC and Index. Back up first though.
See www.grainge.org for RoboHelp and Authoring tips
@petergrainge

Mass compile crashes LabVIEW 2010

Before I go ahead and call the support line
Pentium 4
2.8GHZ
2GB RAM
XP 32 bit
Anyone have issues mass compiling an application code from 8.6.1 to 2010 SP1 whereby it would seem to work fine for quite awhile then crash?
I tries no cache on the VI and all other items are off.
It seems to happen even in subdirectories of the application.
I just installed 2010 SP1 and the device drivers and when I look at them in isolation they seem to be installed correctly.
I can also load the 8.6.1 application
Im just wondering if Mass Compile is running out of memory and is it known issue or am I discovering something.
I will attempt to log results on the next try.

Hey guys, this is Paul with Applications Engineering at NI.
I have reviewed your issues, asked around, and have a couple tips and questions.
First, if there is any chance you could post your project in a zipped format, then we could examine it on our end and see if we experience the same issue, which would make it easy to file a CAR on. If you are wary of posting your code publicly, you can PM me, and we can work out a way to upload it to our FTP server that only NI employees can access.
richjoh, in your posted Mass Compile screen, I see a VI being flagged as bad. When you open this VI on it's own do you experience this problem? Can you locate in that VI where it calls the NanoMsg.lvclass?
Second, to either of you, were the controls and lvclasses mentioned still referenced in your projects anywhere? Were they included in the dependencies? If not, once you restored these files into the project, find them in the
dependencies, right click them, choose "Find">"Callers". Where they still being called anywhere?
Alternative to your solutions, have you considered creating a new project and adding all of your VIs into the new project? I have seen this resolve upconverting issues in the past.
Paul Davidson
Sound and Vibration Software Staff Product Support Engineer
National Instruments

Compiler crash Forms 6i

Hi,
I have a problem with Forms developer 6i. I have a very big form 2.3 MB, and then I added some extra lines of code ( and there are no errors in them ), and when I try to recompile the fmb now it crashes the whole forms developer program !
I think I hit maximum compilesize for fmb's or something - but then again can that really be true ?
Have anyone experienced similar problems ? and does a solution exist.
PS - I tried to add the lines again from the functioning fmb and same thing happened again and again at roughly the same point - around 2.3 MB
Kind regards
Bo Normann

First of all, the last two posts are implying that the runform session is crashing. Please note that the original post is talking about the Forms Builder crashing.
I couldn't understand the logic behind 'Finding and Replacing' a semicolon with a semicolon through out the form.If you compile a form, you will notice in the Object Navigator, that each program unit has a '+' by them that you can click and see more options. If you open the source of the program unit, at the bottom of the editor window it says Not Modified . . . Sucessfully Compiled. If you save the form, close it, and re-open it, the program unit still has this compiled indicator.
If you change anything in the program editor, the compiled indicator disappears. If you save the form without compiling, and reopen it, it is still NOT compiled.
All you are doing by changing semicolon to semicolon is forcing every trigger and procedure to become uncompiled. And then if you save the form in this state and check the fmb size, you will notice a much smaller fmb size. You will notice when you open such a form in the Builder, the open is faster, and the first compile is slower (just like doing a shift-ctrl-K compile-all). On the other hand, a form saved with all compiled code opens slower, but first compile is fast. Apparently when Oracle opens a pre-compiled fmb, it tries to verify the compiled program units.
However, these compiled program units cause problems -- we have had problems using pre-compiled fmb's transported to different environments failing in stored-procedure calls and other places. Doing a compile-all (shift-ctrl-K) clears the problem.
The bottom line is this: Storing compiled code inside an fmb does no good. Oracle has been doing it from the beginning of client/server forms, along with storing a copy of the color palette, too. In BOTH situations, this has caused issues with forms, especially when moved from one environment to another. In my workplace, we make SURE we always store production forms WITHOUT the compiled code. They transport quicker due to smaller file size, and they compile cleaner in the users environments.

Tomcat/Java Compiler crash

The following issue is running on a HP/UX 11i V2 Itanium Superdome server.
We have a vendor application being deployed with Tomcat. The versions of Tomcat and java are:
Tomcat is 5.0.28 (required by vendor)
java is 1.4.2.10 (required by vendor)
Tomcat is randomly crashing with the following:
SIGSEGV 11* segmentation violation
si_signo [11]: SIGSEGV 11* segmentation violation
si_errno [0]: Error 0
si_code [2]: SEGV_ACCERR [addr: 0xc00]
Aborting...
Unexpected Signal : 11 occurred at PC=0xC56EF780
Function=_ZN7RegMask3ANDERKS_
Compiler thread crashed while compiling a method!
Compiled method class=ibi.broker.util.RCDES
Compiled method name=getStringFromHexString
Compiled method signature=(Ljava/lang/String;)Ljava/lang/String;
Library=/opt/java1.4/jre/lib/IA64N/server/libjvm.so
Current Java thread:
"CompilerThread0" daemon prio=7 tid=00064c50 nid=9 lwp_id=3017 runnable [0x00000
000..0x6a4001f8]
This is a problem with java compiling a method out of a class/jar file, correct? So, I added the following directive in the catalina.sh file for the JAVA_OPTS:
-XX:CompileCommand= exclude,ibi/broker/util/RCDES,getStringFromHexString
This should prevent the suspect method from getting compiled. And it does. The catalina.out file has
### Excluding compile: ibi.broker.util.RCDES::getStringFromHexString
which verifies this.
Well, then vendor thinks this is a problem with either Tomcat or Java.
So, does anyone think this is really a Tomcat or Java problem or a problem with the vendors method? I was able to find the jar file with the class file that contains this method. Since this is in a class file, is there a way to manually compile this method to see if I can reproduce the problem?

The JVM should never segfault. Unless you are using JNI it shouldn't be possible to write code that causes this sort of behaviour.
So when you see a segfault it usually boils down to (in no particular order) one of:
1. Hardware problem
2. JNI (mis)use
3. JVM bug.
Check with the vendor to see if their app includes any JNI logic. If not, try it on known good hardware. If it still falls over, raise a bug with Sun.

FPGA LabVIEW 2011 Compilation Crash - I/O Node

When I try to compile this FPGA LabVIEW code then LabVIEW crash every during" Generating Intermediate Files"
It don't like these "FPGA I/O in" variables in FPGA I/O Node.
Constants "POT_net_1_x" are same standard DIOs.
Hardware: PXI-7841R
Solved!
Go to Solution.

Hi JCC,
Glad you got it to compile, it may have been that LabVIEW got a corrupted file somewhere in the project that was causing an issue and by rewriting the code you bypassed this problem.
If the further problems relate to a problem with FPGA compilation then you could post them here, otherwise it is probably best to create a new thread with a title that relates to that problem, that way other people will know what the thread is about and it they know the answers or have suggestions they will help.
Kind regards,
James W
Controls Systems Engineer
STFC

FPGA compile crashes frequently

Hello,
I have been working on an FPGA project. I am using LabView 8.5 with the FPGA module version 8.5. My target is a PCI-5640R. I am running Windows XP.
When I compile the FPGA, I frequently get errors. I originally was using arrays and clusters in the FPGA, but I got a tip that the compiler might not work well with those; so I migrated to memory blocks, but I am still getting errors.
I will attach a file with some old compile logs with errors that I got when I was using arrays and clusters. I will also attach my current project. The FPGA has a block which performs an FFT on incoming data. I am on my fourth compile attempt now. The first one failed due to circumstances outside of LabVEIWs control, but the other two logs are in the zip with the project.
I really need to get this working soon as I have a deadline approaching quickly.
Thanks
EDIT: I don't know if this helps, but twice in the past, when I started a compile, I just got a message box which said:
xflow.exe - Entry Point Not Found
The procedure entry point ?get_vendor@PM_PIC@@QBEQADXZ could not be located in the dynamic link library libPersonalityModule.dll.
However, this does not happen anymore.
Message Edited by pd2 on 07-15-2008 09:57 PM
Attachments:
project.zip ‏924 KB
some old compile failures.zip ‏229 KB

Hi
Your project LV FPGA VI compiled for me the first time.
I’ve attached the statistics for the build report.
As for why it may not be compiling all the time, or sort of randomly, I’m wondering if it may be the timing.
Base clock: ADC_0_Port_A_Clk
Requested Rate: 25.001250MHz
Theoretical Maximum: 25.661423MHz
The theoretical maximum is just a tad bit faster than the requested rate. I’m wondering if on the other compiles, that the compiler couldn’t come up with a logic layout that met the 25 MHz.
Is there any more pipelining you can do to your processing VI to get the margin up a lot higher. I saw in your processing case that there is a long chain of logic which may be pushing the theoretical time down to close to the requested time.
The other thing to try to verify this is to change the ADC clock Requested Rate down to 12.5 MHz, and see if it compiles easier.
It also might be a good idea to place your processing logic in another SCTL, passed through another FIFO. Run this off the RTSI Clock.
Jerry
Attachments:
Build.rpt.txt ‏1 KB

GJ Compiler crash

The following code causes the compiler to dump a stack trace (stack overflow) -- looks like some occurs check is missing in type-inference:
======================================
public class Test {
static
<T, A> T<A, A> genericNew() {
genericNew();
======================================
This is the simplest version of the code that produces the problem. Its the call that creates the problems.

recorded as bug 4784219.

Internet Toolkit for G5.0 crashes Labview 8.2 during Mass Compile

I have just received my Labview 8.2 update and installed it my system along with all my toolkits. When I tried to Mass Compile Labview 8.2 directory I found that it would crash labview consistantly as shown in the attached image.
I traced this to the vi's supplied with the Internet Toolkit for G5.0.
The workaround is ...
1. Re-installed the Internet Toolkit for G5.0 into Labview 8.2
2. Mass Compiled ...\project\_config\authcfg.llb using Labview 8.0
3. Mass Compiled ...\project\_config\authcfg.llb using Labview 8.2
and there wasn't any more Labview 8.2 crashes during mass compile. As Labview 8.0 was able to mass compile the internet toolkit vi's without crashing I am suspicious that Labview 8.2 might not be completely compatible with Labview 5.0.
I posted this just in case anyone else sees a similiar issue.
David
Attachments:
Labview 8.2 Mass Compile Crash with Internet Toolkit.png ‏34 KB

David,
I was able to reproduce the crash mass compiling authcfg.llb or just trying to open the VI named 'Directory Configuration'. That code is saved in LabVIEW 5.0.1 and must have something that LabVIEW 8.2 chokes on, I'll have to get someone to investigate it. Your workaround of saving that .llb or even that one VI in 8.0 first (or probably even 7.x) is the only way I see around it with 8.2.
I do want to mention that in Q1 2004 we released version 6.0 of the Internet Toolkit and it does not exhibit this behavior. So the official solution for this crash is to upgrade to the latest Internet Toolkit.
Kennon

Compiler Crashes!!

Similar Messages

Maybe you are looking for