Thread: RE: [Quickfix-developers] crash when upgrade to 1.9.4
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers
|
From: Sean K. <Sea...@Pi...> - 2005-06-20 21:53:02
|
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
|
|
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... |
|
From: Caleb E. <cal...@gm...> - 2005-06-21 19:59:49
|
On 6/21/05, Sean Kirkpatrick <Sea...@pi...> wrote: > Additional Info: >=20 > 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 som= e > googling, but that didn't seem to make a difference... This is starting to look like an issue for your platform vendor to have to answer. Also, which version of gcc are you using? I'm praying its not 2.95.x... If it is, thats probably a big source of your troubles. You should switch to gcc 3.3.x or 3.4.x and drop STLport. --=20 Caleb Epstein caleb dot epstein at gmail dot com |
|
From: Sean K. <Sea...@Pi...> - 2005-06-21 17:05:20
|
> -----Original Message----- > From: Caleb Epstein [mailto:cal...@gm...] > Sent: Tuesday, June 21, 2005 11:30 AM > To: Sean Kirkpatrick > Cc: qui...@li... > Subject: Re: [Quickfix-developers] crash when upgrade to 1.9.4 >=20 >=20 > On 6/20/05, Sean Kirkpatrick=20 > <Sea...@pi...> wrote: > =20 > > Ok, so I am really banging my head on my desk at this point. > >=20 > > Thank you for the suggestions, Caleb. I was able to run a simple > > exception throwing program successfully. The build server=20 > is running: > >=20 > > Linux 2.4.9-e.3smp #1 SMP Fri May 3 16:48:54 EDT 2002 i686 > >=20 > > The server having the issues is running: > >=20 > > Linux 2.4.9-e.3 #1 Fri May 3 17:02:43 EDT 2002 i686 > >=20 > > I have verified and re-verified that the binaries between these two > > machines are identical. It seems that the problem has=20 > something to do with > > the new function declarations as "FieldNotFound" rather than > > "FieldNotFound&". I'm basing this on the call_unexpected=20 > that is being > > triggered in the trace: > >=20 > > #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 (*)())=20 > (handler=3D0x40804f34 > > <abort>) at eh_terminate.cc:47 > > #4 0x40741100 in __cxa_call_unexpected (exc_obj_in=3D0x4) at=20 > eh_personality.cc:406 > > #5 0x407d1fdc in _Unwind_RaiseException_Phase2=20 > (exc=3D0x84ab0f0, context=3D0x4150d0dc) > > at ../../gcc/unwind-dw2.c:1045 > > #6 0x407d2116 in _Unwind_RaiseException (exc=3D0x84ab0f0) at > > ../../gcc/unwind-dw2.c:1045 > > #7 0x407413f9 in __cxa_throw (obj=3D0x84ab0f0,=20 > tinfo=3D0x8254048, dest=3D0x8254048) > > at eh_throw.cc:72 > > #8 0x08113fb5 in FIX::FieldMap::getField(FIX::FieldBase&)=20 > const (this=3D0x4150e7cc, > > field=3D@0x4150d5dc) at=20 > /usr/local/include/quickfix/FieldMap.h:101 > > #9 0x080c63d4 in ClientCode::FIXToNewOrder(Session*, > > FIX::Message const&, Order&) (this=3D0x81a30b0,=20 > pSession=3D0x8213a10, > > msg=3D@0x4150e7cc, order=3D@0x4150d90c) at qfmsg.cpp:1649 >=20 > Are you catching FIX::FieldNotFound (by value or reference) in your > code here (qfmsg.cpp:1649)? >=20 > --=20 > Caleb Epstein > caleb dot epstein at gmail dot com >=20 I actually originally had it caught by ref, then tried by val, and have since changed it back to by ref. |
|
From: Sean K. <Sea...@Pi...> - 2005-06-21 20:02:57
|
We're using GCC 3.2.3 to build the binaries. Thanks for you time/input. > -----Original Message----- > From: Caleb Epstein [mailto:cal...@gm...] > Sent: Tuesday, June 21, 2005 4:00 PM > To: Sean Kirkpatrick > Cc: qui...@li... > Subject: Re: [Quickfix-developers] crash when upgrade to 1.9.4 >=20 >=20 > On 6/21/05, Sean Kirkpatrick=20 > <Sea...@pi...> wrote: >=20 > > Additional Info: > >=20 > > 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=20 > --enable-shared, after some > > googling, but that didn't seem to make a difference... >=20 >=20 > This is starting to look like an issue for your platform vendor to > have to answer. Also, which version of gcc are you using? I'm > praying its not 2.95.x... If it is, thats probably a big source of > your troubles. You should switch to gcc 3.3.x or 3.4.x and drop > STLport. >=20 > --=20 > Caleb Epstein > caleb dot epstein at gmail dot com >=20 |
|
From: Sean K. <Sea...@Pi...> - 2005-06-21 21:36:12
|
I apologize for being so annoying about this, but I just now seem to have resolved this issue. I wiped everything out for quickfix and=20 untarred the source again (same source used originally). I then ran ./configure --with-stlport=3D/usr/local --disable-callstack. I am using GCC 3.2.3 here. I then went directly to src/C++ and ran make and=20 make install from there to build the libraries and install the header files. I ran ldconfig -v and rebuilt my app. Now the exceptions are being thrown and caught as expected. One thing I did notice is that the library binaries are different sizes. Is there any reason why building from src/C++ would yield different results? Thanks, Sean > -----Original Message----- > From: qui...@li... > [mailto:qui...@li...]On Behalf Of > Sean Kirkpatrick > Sent: Tuesday, June 21, 2005 4:03 PM > To: Caleb Epstein > Cc: qui...@li... > Subject: RE: [Quickfix-developers] crash when upgrade to 1.9.4 >=20 >=20 > QuickFIX Documentation:=20 > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX FAQ:=20 > http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ > QuickFIX Support: http://www.quickfixengine.org/services.html >=20 > We're using GCC 3.2.3 to build the binaries. Thanks for you=20 > time/input. >=20 > > -----Original Message----- > > From: Caleb Epstein [mailto:cal...@gm...] > > Sent: Tuesday, June 21, 2005 4:00 PM > > To: Sean Kirkpatrick > > Cc: qui...@li... > > Subject: Re: [Quickfix-developers] crash when upgrade to 1.9.4 > >=20 > >=20 > > On 6/21/05, Sean Kirkpatrick=20 > > <Sea...@pi...> wrote: > >=20 > > > Additional Info: > > >=20 > > > 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=20 > > --enable-shared, after some > > > googling, but that didn't seem to make a difference... > >=20 > >=20 > > This is starting to look like an issue for your platform vendor to > > have to answer. Also, which version of gcc are you using? I'm > > praying its not 2.95.x... If it is, thats probably a big source of > > your troubles. You should switch to gcc 3.3.x or 3.4.x and drop > > STLport. > >=20 > > --=20 > > Caleb Epstein > > caleb dot epstein at gmail dot com > >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers >=20 |
|
From: Caleb E. <cal...@gm...> - 2005-06-21 22:12:50
|
On 6/21/05, Sean Kirkpatrick <Sea...@pi...> wrote: > I apologize for being so annoying about this, but I just now seem to > have resolved this issue. I wiped everything out for quickfix and > untarred the source again (same source used originally). I then > ran ./configure --with-stlport=3D/usr/local --disable-callstack. I am > using GCC 3.2.3 here. I then went directly to src/C++ and ran make and > make install from there to build the libraries and install the header > files. I ran ldconfig -v and rebuilt my app. Now the exceptions are > being thrown and caught as expected. One thing I did notice is that > the library binaries are different sizes. Is there any reason why > building from src/C++ would yield different results? Probably because you had old object files sitting around that were built with a different compiler, or with other differences in the compiler settings. --=20 Caleb Epstein caleb dot epstein at gmail dot com |
|
From: Caleb E. <cal...@gm...> - 2005-06-21 17:50:42
|
On 6/20/05, Sean Kirkpatrick <Sea...@pi...> wrote: =20 > Ok, so I am really banging my head on my desk at this point. >=20 > Thank you for the suggestions, Caleb. I was able to run a simple > exception throwing program successfully. The build server is running: >=20 > Linux 2.4.9-e.3smp #1 SMP Fri May 3 16:48:54 EDT 2002 i686 >=20 > The server having the issues is running: >=20 > Linux 2.4.9-e.3 #1 Fri May 3 17:02:43 EDT 2002 i686 >=20 > I have verified and re-verified that the binaries between these two > machines are identical. It seems that the problem has something to do wi= th > the new function declarations as "FieldNotFound" rather than > "FieldNotFound&". I'm basing this on the call_unexpected that is being > triggered in the trace: >=20 > #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=3D0x40804f= 34 > <abort>) at eh_terminate.cc:47 > #4 0x40741100 in __cxa_call_unexpected (exc_obj_in=3D0x4) at eh_personal= ity.cc:406 > #5 0x407d1fdc in _Unwind_RaiseException_Phase2 (exc=3D0x84ab0f0, context= =3D0x4150d0dc) > at ../../gcc/unwind-dw2.c:1045 > #6 0x407d2116 in _Unwind_RaiseException (exc=3D0x84ab0f0) at > ../../gcc/unwind-dw2.c:1045 > #7 0x407413f9 in __cxa_throw (obj=3D0x84ab0f0, tinfo=3D0x8254048, dest= =3D0x8254048) > at eh_throw.cc:72 > #8 0x08113fb5 in FIX::FieldMap::getField(FIX::FieldBase&) const (this=3D= 0x4150e7cc, > field=3D@0x4150d5dc) at /usr/local/include/quickfix/FieldMap.h:10= 1 > #9 0x080c63d4 in ClientCode::FIXToNewOrder(Session*, > FIX::Message const&, Order&) (this=3D0x81a30b0, pSession=3D0x8213= a10, > msg=3D@0x4150e7cc, order=3D@0x4150d90c) at qfmsg.cpp:1649 Are you catching FIX::FieldNotFound (by value or reference) in your code here (qfmsg.cpp:1649)? --=20 Caleb Epstein caleb dot epstein at gmail dot com |
