It is definitely possible that the build could have caused some of the
issues. That's why I listed the compiler version.
valgrind = 3.3.
The OS and version is rare:
Linux version 2.6.24.7-9.smp.gcc3.4.x86_64
(rap-master.rpath....@rpath:linux-1-devel) (gcc version 3.4.4) #1 SMP
Tue Jul 15 12:23:51 EDT 2008
But I have been able to get M4 to build on it with minor finagling.
Also now it builds more easily just --enable-warnings=no.
Would it help to send a log of the compile? I can try and dig into
this more deeply if that would help. Unfortunately I am not able to
convince people to upgrade our version of g++ and I think this is the
most likely suspect (though I have no evidence of this).
The broker definitely does crash regularly.
The last point I log a message from my client, I had queried for a
queue and was about to declare, bind, send some messages, start a
subscriptionManager etc. I can try and pinpoint the client action
that causes the crash if needed.
Here is a stacktrace:
SEG FAULT:
(gdb) where
#0 0x00002ad3c74f6c88 in main_arena () from /lib64/tls/libc.so.6
#1 0x00002ad3c671a9ed in qpid::framing::AMQFrame::decode (
this=0x7fffe489dc90, buff...@0x7fffe489de10) at intrusive_ptr.hpp:125
#2 0x00002ad3c63f74dc in qpid::amqp_0_10::Connection::decode (this=0x538ec0,
buffer=0x7fffe489de10 "d", size=40) at memory:285
#3 0x00002ad3c6743cc9 in qpid::sys::AsynchIOHandler::readbuff (this=0x538dd0,
buff=0x530a00) at qpid/sys/AsynchIOHandler.cpp:103
#4 0x00002ad3c64efc61 in
boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool,
boost::_mfi::mf2<bool, qpid::sys::AsynchIOHandler,
qpid::sys::AsynchIO&, qpid::sys::AsynchIOBufferBase*>,
boost::_bi::list3<boost::_bi::value<qpid::sys::AsynchIOHandler*>,
boost::arg<1> (*)(), boost::arg<2> (*)()> >, bool,
qpid::sys::AsynchIO&, qpid::sys::AsynchIOBufferBase*>::invoke (
function_obj_p...@0x57e890, a...@0x7fffe489de10, a1=0x530a00)
at mem_fn_template.hpp:273
#5 0x00002ad3c66e2467 in boost::function2<bool, qpid::sys::AsynchIO&,
qpid::sys::AsynchIOBufferBase*, std::allocator<boost::function_base>
>::operator() (
this=0x57e890, a...@0x7fffe489de10, a1=0x28) at function_template.hpp:824
#6 0x00002ad3c66e1671 in qpid::sys::posix::AsynchIO::readable (this=0x5391f0,
h...@0x5391f8) at qpid/sys/posix/AsynchIO.cpp:446
#7 0x00002ad3c66e492d in
boost::detail::function::void_function_obj_invoker1<boost::_bi::bind_t<void,
boost::_mfi::mf1<void, qpid::sys::posix::AsynchIO,
qpid::sys::DispatchHandle&>,
boost::_bi::list2<boost::_bi::value<qpid::sys::posix::AsynchIO*>,
boost::arg<1> (*)()> >, void, qpid::sys::DispatchHandle&>::invoke (
---Type <return> to continue, or q <return> to quit---
function_obj_p...@0x57e890, a...@0x7fffe489de10) at mem_fn_template.hpp:162
#8 0x00002ad3c67485e7 in boost::function1<void,
qpid::sys::DispatchHandle&, std::allocator<boost::function_base>
>::operator() (this=0x57e890,
a...@0x7fffe489de10) at function_template.hpp:824
#9 0x00002ad3c67479f5 in qpid::sys::DispatchHandle::processEvent (
this=0x5391f8, type=qpid::sys::Poller::READABLE)
at qpid/sys/DispatchHandle.cpp:443
#10 0x00002ad3c66f3b7c in qpid::sys::Poller::run (this=0x52c670)
at Poller.h:122
#11 0x00002ad3c63ff1fe in qpid::broker::Broker::run (this=0xffffffff)
at qpid/broker/Broker.cpp:318
#12 0x000000000040bb5d in QpiddBroker::execute (this=0x57e890,
options=0x525fc0) at intrusive_ptr.hpp:125
#13 0x0000000000408ce1 in main (argc=1, argv=0x7fffe489ef58) at memory:301
Thanks,
Adam
On Wed, Mar 4, 2009 at 10:36 AM, Andrew Stitcher <[email protected]> wrote:
> On Tue, 2009-03-03 at 21:43 -0500, Adam Chase wrote:
>> Make check was flawless on 32 bit linux with g++ 4.3.2.
>>
>> Got errors on a 64 bit linux g++ 3.4.4.
>>
>> It crashes pretty regularly on this platform. Is this platform supported?
>
> You're going to have to be a little more specific than that!
>
> What are the platforms you are talking about?
> OS/Version
> valgrind version
>
> We test on 64 bit Linux (Red Hat 4/5, Fedora 9,10) all the time so these
> platforms should definitely work
>
> >From a cursory look at your output I'd say it is what we'd expect from a
> platform we'd not tested before - we commonly see different valgrind
> complaints (many valid some not) when we use a platform we've not tested
> on before.
>
> BTW the "it" that is crashing is the unit test not the broker or client
> themselves.
>
> A crash in the unit_test like that will cause a lot of leak records
> because the program will be interrupted before cleaning up normally, so
> take the leaks with a grain of salt.
>
> The fact that the rest of the test fails to run makes me suspicious
> something funny is going on though with the make could ti be because you
> are using NFS for your build directory?
>
> Hope that helps/sheds some light.
>
> Andrew
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:[email protected]
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
