Comment 2 for bug 484465

Revision history for this message
Jan (jan-ellenbeck) wrote :

As already mentioned in my mail, on our 64bit systems (x86-64 opensuse) it compiles with the patches, but most of the times (not always though) I get a segfault in one of the unittests. I have the impression it is a more general thing and the code causing it seems to be new, so here it is:

[TST] N3wns9scheduler5queue5tests19SegmentingQueueTestE::testSegmentConcatenate
openWNS: caught signal 11
openWNS: caught signal 'SIGSEGV' (segmentation violation)
Backtrace (most recent call last, stack size: 41):
[...]
 17) wns::ldk::CommandReaderInterface::activateCommand(wns::ldk::CommandPool*)
 16) wns::ldk::CommandProxy::activateCommand(wns::ldk::CommandPool*, unsigned int const&)
 15) unknown

gdb's backtrace shows it happens at line 269 of ramework/library/src/ldk/CommandProxy.cpp:269
[TST] N3wns9scheduler5queue5tests19SegmentingQueueTestE::testSegmentConcatenate
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fda231cc700 (LWP 25253)]
0x00007fda21b6366d in wns::ldk::CommandProxy::activateCommand (this=0x16a1730, commandPool=0x166d970, id=@0x7fff2b1f916c) at framework/library/src/ldk/CommandProxy.cpp:269
269 activateCommand(commandPool, commandTypeSpecifiers.at(id));
(gdb) bt
#0 0x00007fda21b6366d in wns::ldk::CommandProxy::activateCommand (this=0x16a1730, commandPool=0x166d970, id=@0x7fff2b1f916c) at framework/library/src/ldk/CommandProxy.cpp:269
#1 0x00007fda21a3331d in wns::ldk::CommandReaderInterface::activateCommand (this=0x19d51b0, commandPool=0x166d970) at include/WNS/ldk/CommandReaderInterface.hpp:60
#2 0x00007fda21a2d05b in wns::scheduler::queue::SegmentingQueue::getHeadOfLinePDUSegment (this=0x178bf30, cid=4, requestedBits=48) at framework/library/src/scheduler/queue/SegmentingQueue.cpp:267
#3 0x00007fda21aa1373 in wns::scheduler::queue::tests::SegmentingQueueTest::testSegmentConcatenate (this=0x899660) at framework/library/src/scheduler/queue/tests/SegmentingQueueTest.cpp:379

and running valgrind shows it is caused by a lot of "Invalid read of size 8" errors which lead to the final segfault:

==26793== Invalid read of size 8
==26793== at 0x676149D: std::vector<wns::ldk::CommandTypeSpecifierInterface*, std::allocator<wns::ldk::CommandTypeSpecifierInterface*> >::size() const (stl_vector.h:485)
==26793== by 0x675C582: wns::ldk::CommandProxy::activateCommand(wns::ldk::CommandPool*, unsigned long const&) (CommandProxy.cpp:267)
[...]
==26793== Address 0x8f00940 is 8 bytes before a block of size 16 alloc'd

...

==26793== Invalid read of size 8
==26793== at 0x676149D: std::vector<wns::ldk::CommandTypeSpecifierInterface*, std::allocator<wns::ldk::CommandTypeSpecifierInterface*> >::size() const (stl_vector.h:485)
==26793== by 0x6769ECC: std::vector<wns::ldk::CommandTypeSpecifierInterface*, std::allocator<wns::ldk::CommandTypeSpecifierInterface*> >::_M_range_check(unsigned long) const (stl_vector.h:585)
==26793== by 0x6769F2E: std::vector<wns::ldk::CommandTypeSpecifierInterface*, std::allocator<wns::ldk::CommandTypeSpecifierInterface*> >::at(unsigned long) (stl_vector.h:604)
==26793== by 0x675C8B6: wns::ldk::CommandProxy::activateCommand(wns::ldk::CommandPool*, unsigned long const&) (CommandProxy.cpp:269)
==26793==
...
==26793== Invalid read of size 8
==26793== at 0x675C8B7: wns::ldk::CommandProxy::activateCommand(wns::ldk::CommandPool*, unsigned long const&) (CommandProxy.cpp:269)
...
==26793== Invalid read of size 8
==26793== at 0x667C8F2: wns::ldk::CommandTypeSpecifierInterface::getPCIID() const (CommandTypeSpecifierInterface.hpp:128)
==26793== by 0x675BA8B: wns::ldk::CommandProxy::activateCommand(wns::ldk::CommandPool*, wns::ldk::CommandTypeSpecifierInterface const*) (CommandProxy.cpp:243)
==26793== by 0x675C8C5: wns::ldk::CommandProxy::activateCommand(wns::ldk::CommandPool*, unsigned long const&) (CommandProxy.cpp:269)