RE: [Quickfix-developers] crash when upgrade to 1.9.4
Brought to you by:
orenmnero
|
From: Sean K. <Sea...@Pi...> - 2005-06-21 18:10:29
|
QuickFIX Documentation: = http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX FAQ: = http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ QuickFIX Support: http://www.quickfixengine.org/services.html See below. > -----Original Message----- > From: Caleb Epstein [mailto:cal...@gm...] > Sent: Thursday, June 16, 2005 6:02 PM > To: Sean Kirkpatrick > Cc: qui...@li... > Subject: Re: [Quickfix-developers] crash when upgrade to 1.9.4 >=20 >=20 > On 6/16/05, Sean Kirkpatrick <Sea...@pi...> = wrote: > > We are currently in the process of QAing a release in which we will = be > > upgrading our production version of quickfix from 1.7.0 to 1.9.4. = When run on:=20 > >=20 > > Linux 2.4.9-e.3 #1 Fri May 3 17:02:43 EDT 2002 i686=20 > >=20 > > our fix engine crashes whenever a FieldNotFound exception is thrown. = The > > strange thing is that when the same binaries are used on my=20 > >=20 > > Linux 2.4.21-27.0.1.ELsmp #1 SMP Mon Dec 20 18:47:45 EST = 2004 i686 > > i686 i386 GNU/Linux=20 > >=20 > > server, the exception is caught as expected. Has anyone seen = similar > > behavior? It definitely seems to indicate that there is some = incompatibility, but I'm not > > sure where...=20 >=20 > I've seen similar behavior when using incompatible versions of the GCC > runtime library libgcc_s.so.1 (e.g. different GCC versions on the > machine you compiled on and the libraries installed on the one you're > running on) >=20 > I'm not sure entirely what is in that library, but the exception > handling code seems to be part of it. You ought to be able to verify > this with a simple test program that you compile on the newer machine > and run on the older one. Something like: >=20 > simplethrow.cpp: > #include <stdexcept> > int main () { > try { throw std::runtime_error ("Boom!") } > catch (std::runtime_error) { return 0; } > return 1; > } >=20 > % g++ -g -o simplethrow simplethrow.cpp >=20 > The program should exit cleanly with status 0: >=20 > % ( ./simplethrow && echo w00t ) || echo uh-oh > w00t >=20 > You can likely work around the problem by putting a copy of the newer > libgcc_s.so.1 (run ldd on your executable on the NEWER machine to find > where it lives - probably /lib) into the directory where your QuickFIX > .so lives, and ensuring this directory appears in your LD_LIBRARY_PATH > before the directory where the system version lives. >=20 > --=20 > Caleb Epstein > caleb dot epstein at gmail dot com >=20 Ok, so I am really banging my head on my desk at this point. Thank you for the suggestions, Caleb. I was able to run a simple exception throwing program successfully. The build server is running: Linux 2.4.9-e.3smp #1 SMP Fri May 3 16:48:54 EDT 2002 i686 The server having the issues is running: Linux 2.4.9-e.3 #1 Fri May 3 17:02:43 EDT 2002 i686 I have verified and re-verified that the binaries between these two machines are identical. It seems that the problem has something to do = with the new function declarations as "FieldNotFound" rather than=20 "FieldNotFound&". I'm basing this on the call_unexpected that is being triggered in the trace: #0 0x40803b11 in __kill () from /lib/i686/libc.so.6 #1 0x406e079b in raise (sig=3D6) at signals.c:65 #2 0x40805092 in abort () at ../sysdeps/generic/abort.c:88 #3 0x40741247 in __cxxabiv1::__terminate(void (*)()) = (handler=3D0x40804f34 <abort>) at eh_terminate.cc:47 #4 0x40741100 in __cxa_call_unexpected (exc_obj_in=3D0x4) at = eh_personality.cc:406 #5 0x407d1fdc in _Unwind_RaiseException_Phase2 (exc=3D0x84ab0f0, = context=3D0x4150d0dc)=20 at ../../gcc/unwind-dw2.c:1045 #6 0x407d2116 in _Unwind_RaiseException (exc=3D0x84ab0f0) at=20 ../../gcc/unwind-dw2.c:1045 #7 0x407413f9 in __cxa_throw (obj=3D0x84ab0f0, tinfo=3D0x8254048, = dest=3D0x8254048)=20 at eh_throw.cc:72 #8 0x08113fb5 in FIX::FieldMap::getField(FIX::FieldBase&) const = (this=3D0x4150e7cc, field=3D@0x4150d5dc) at /usr/local/include/quickfix/FieldMap.h:101 #9 0x080c63d4 in ClientCode::FIXToNewOrder(Session*, FIX::Message const&, Order&) (this=3D0x81a30b0, pSession=3D0x8213a10, msg=3D@0x4150e7cc, order=3D@0x4150d90c) at qfmsg.cpp:1649 #10 0x080ce118 in ClientCode::FIXToNewOrder(Session*, FIX::Message = const&, Order&) (this=3D0x81a30b0, pSession=3D0x8213a10, msg=3D@0x4150e7cc, = order=3D@0x4150d90c) at qfmsg.cpp:2738 #11 0x080b3fed in ClientCode::OnNewOrderSingle(Session*, FIX::Message = const&, FIX::BeginString const&) (this=3D0x81a30b0, pSession=3D0x8213a10, = msg=3D@0x4150e7cc, beginString=3D@0x4150df2c) at qfmsg.cpp:573 #12 0x080ae1ef in ClientCode::OnFIXAppMessageIn(Session*, FIX::Message = const&) (this=3D0x81a30b0,pSession=3D0x8213a10, msg=3D@0x4150e7cc) at = qfmsg.cpp:231 #13 0x08096724 in ClientCode::fromApp(FIX::Message const&, = FIX::SessionID const&) (this=3D0x81ba5b8,msg=3D@0x4150e7cc, sessionid=3D@0x84482dc) at = qfeng.cpp:1291 #14 0x4039ae3b in FIX::Session::fromCallback(FIX::MsgType const&, FIX::Message const&, FIX::SessionID const&) (this=3D0x84482d8, msgType=3D@0x4150e22c, msg=3D@0x4150e7cc, sessionID=3D@0x84482dc) at Session.cpp:932 #15 0x4039a26f in FIX::Session::verify(FIX::Message const&, bool, bool) (this=3D0x84482d8, msg=3D@0x4150e7cc, checkTooHigh=3Dtrue, = checkTooLow=3Dtrue) at Session.cpp:899 #16 0x4039e3f6 in FIX::Session::next(FIX::Message const&) = (this=3D0x84482d8, message=3D@0x4150e7cc) at Session.cpp:1137 #17 0x4039d3cd in FIX::Session::next(_STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char> > const&) = (this=3D0x84482d8, msg=3D@0x4150e89c) at Session.cpp:1071 #18 0x403bd59c in FIX::SocketConnection::read(FIX::SocketAcceptor&, FIX::SocketServer&) (this=3D0x8455e78, a=3D@0x8254048, s=3D@0x844eff0) = at SocketConnection.cpp:112 #19 0x403b7a83 in FIX::SocketAcceptor::onData(FIX::SocketServer&, int) (this=3D0x8205db8, server=3D@0x844eff0, s=3D123) at = SocketAcceptor.cpp:157 #20 0x4040b869 in FIX::ServerWrapper::onEvent(FIX::SocketMonitor&, int) (this=3D0x4150ea7c, socket=3D123) at SocketServer.cpp:60 #21 0x403bc9f8 in = FIX::SocketMonitor::block(FIX::SocketMonitor::Strategy&, bool) (this=3D0x844f00c, strategy=3D@0x4150ea7c, poll=3Dfalse) at SocketMonitor.cpp:182 #22 0x403ae620 in FIX::SocketServer::block(FIX::SocketServer::Strategy&, = bool) (this=3D0x844eff0, strategy=3D@0x8254048, poll=3Dfalse) at = SocketServer.cpp:124 #23 0x403b771b in FIX::SocketAcceptor::onStart() (this=3D0x844eff0) at SocketAcceptor.cpp:84 #24 0x403b17f1 in FIX::Acceptor::startThread(void*) (p=3D0x8254048) at Acceptor.cpp:208 #25 0x406ddc6f in pthread_start_thread (arg=3D0x4150ebe0) at = manager.c:284 It's lines 4-7 that seem suspicious to me, but I haven't been able to = get around this crash. Any help would be greatly appreciated. Thanks, Sean Additional Info: We are using STLport 4.6.2 and I ran: ./configure --with-stlport=3D/usr/local --disable-callstack before building quickfix. I also tried adding --enable-shared, after = some googling, but that didn't seem to make a difference... |