Re: [Quickfix-developers] core dump
Brought to you by:
orenmnero
From: <gar...@su...> - 2003-03-06 18:44:03
|
We actually did use gcc 2.95.2 with the stlport library because we knew that we would be using this on a multi-processor machine. Gary Mui Prescient Markets, Inc 914-989-3118 (W) 445 Hamilton Avenue 914-422-3693 (F) White Plains, NY 10601 Please visit us at http://www.cpmarket.com Oren Miller <ore...@ya...> Sent by: To: gar...@su..., om...@th... qui...@li...ur cc: qui...@li... ceforge.net Subject: Re: [Quickfix-developers] core dump 03/06/03 12:56 PM Please respond to omiller Another thing. Which compiler and STL implementation are you using? We know that there are bugs in the gcc STL implementation for gcc 2.95.x, when using strings on a multi-processor machine. This causes random bad behavior. For these cases we recommend using STLport. --- gar...@su... wrote: > > So far we've only seen this once, though we've only > been testing on the 250 > for a couple days. > > We will keep an eye on this but it does kinda make > me nervous.... > > Do you think that if we compiled on the platform we > run on, we would be any > safer? > > Thanks, > > Gary Mui > Prescient Markets, Inc 914-989-3118 (W) > 445 Hamilton Avenue 914-422-3693 (F) > White Plains, NY 10601 > > Please visit us at http://www.cpmarket.com > > > > > > Oren Miller > > > <orenmnero@yahoo To: > gar...@su..., > qui...@li... > .com> cc: > > > > Subject: Re: [Quickfix-developers] core dump > > 03/06/03 11:29 > > > AM > > > Please respond > > > to omiller > > > > > > > > > > > > Well, the only thing that is happening in the > destroy method (which is > called by the garbage collector through finalize), > is the underlying C++ > Message object is being deleted. This is the line: > > > delete getCPPMessage( obj ); > > > getCPPMessage( obj ), pulls out the value from the > cppPointer variable in > Message.java which is used to store the memory > address of the C++ object. > > > Obviously some pretty unsafe casting needs to be > done to accomplish this. > I don't know what the architectural differences are > between those two > systems, but OS isn't the only factor as such > pointer manipulation is more > affected by hardware than anything else. > > > Are you able to consistantly get this behavior in a > repeatable way, or does > it work sometimes and not others? Have you only > seen this behavior on the > e250? > > > gar...@su... wrote: > I got the following core dump and as I'm that > familiar with the C++ side > of > quickfix, was wondering if anyone has any > suggestions as to what may have > been the problem: > > Would it matter that the libraries were build on an > Ultra 5 but are being > used on an E250? The OS versions are the same. > > Thanks, > Gary > > > > <20030306-14:59:42, FIX.4.2:STNMMTST->FMRFITST, > incoming> > > > (8=FIX.4.2^A9=0066^A35=0^A34=280^A49=FMRFITST^A56=STNMMTST^A52=20030306-14:59:42^A112=TEST^A10=227^A) > > > An unexpected exception has been detected in native > code outside the VM. > Unexpected Signal : 11 occurred at PC=0xfe1c71f0 > Function name=assign__t18string_char_traits1ZcRcRCc > > Library=/export/home/prescient/QFE/qfe_03.04.03/lib/libstdc++.so.2.10.0 > > Current Java thread: > at org.quickfix.Message.destroy(Native Method) > at org.quickfix.Message.finalize(Message.java:89) > at > java.lang.ref.Finalizer.invokeFinalizeMethod(Native > Method) > at > java.lang.ref.Finalizer.runFinalizer(Finalizer.java:86) > at > java.lang.ref.Finalizer.access$100(Finalizer.java:17) > at > java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:163) > > Dynamic libraries: > 0x10000 /java/bin/../bin/sparc/native_threads/java > 0xff350000 /usr/lib/libthread.so.1 > 0xff390000 /usr/lib/libdl.so.1 > 0xff200000 /usr/lib/libc.so.1 > 0xff330000 > /usr/platform/SUNW,Ultra-60/lib/libc_psr.so.1 > 0xfe480000 > > /pfdcpmarket/apps/JDK/java131/jre/lib/sparc/client/libjvm.so > 0xff2e0000 /usr/lib/libCrun.so.1 > 0xff1e0000 /usr/lib/libsocket.so.1 > 0xff100000 /usr/lib/libnsl.so.1 > 0xff0d0000 /usr/lib/libm.so.1 > 0xff310000 /usr/lib/libw.so.1 > 0xff0b0000 /usr/lib/libmp.so.2 > 0xff080000 > > /pfdcpmarket/apps/JDK/java131/jre/lib/sparc/native_threads/libhpi.so > 0xff050000 > /pfdcpmarket/apps/JDK/java131/jre/lib/sparc/libverify.so > 0xfe440000 > /pfdcpmarket/apps/JDK/java131/jre/lib/sparc/libjava.so > 0xff020000 > /pfdcpmarket/apps/JDK/java131/jre/lib/sparc/libzip.so > 0xf4880000 > /pfdcpmarket/apps/QFE/qfe_03.04.03/lib/libquickfix_jni.so > 0xfe190000 > > /export/home/prescient/QFE/qfe_03.04.03/lib/libstdc++.so.2.10.0 > 0xf4700000 > /export/home/prescient/QFE/qfe_03.04.03/lib/libxml2.so.2 > 0xfe2c0000 /usr/lib/libz.so > 0xfe2a0000 /usr/lib/libpthread.so.1 > 0xfe170000 > /pfdcpmarket/apps/JDK/java131/jre/lib/sparc/libnet.so > 0xfd3e0000 /usr/lib/nss_files.so.1 > > Local Time = Thu Mar 6 09:59:47 2003 > Elapsed Time = 42711 > # > # The exception above was detected in native code > outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.3.1_02-b02 > mixed mode) > > > > Gary Mui > Prescient Markets, Inc 914-989-3118 (W) > 445 Hamilton Avenue 914-422-3693 (F) > White Plains, NY 10601 > > Please visit us at http://www.cpmarket.com > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of > TotalView, The > debugger > for complex code. Debugging C/C++ programs can > leave you feeling lost and > disoriented. TotalView can help you find your way. > Available === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |