Compiler error on 64bit system: conflicting return type specified for 'uint32_t' ... overriding "size_t"

Bug #484465 reported by Jan
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
openWNS Library
Fix Committed
Medium
Maciej Muehleisen

Bug Description

In the various *Link* header files in library/src/ldk as well as in the corresponding tests, uint32_t is used instead of size_t in some occasions yielding compiler errors on 64bit systems:

In file included from include/WNS/ldk/multiplexer/Dispatcher.hpp:41,
                 from framework/library/src/ldk/multiplexer/Dispatcher.cpp:28:
include/WNS/ldk/RandomAccessLink.hpp: In instantiation of 'wns::ldk::RandomAccessLink<wns::ldk::IDelivererReceptacle>':
include/WNS/ldk/multiplexer/OpcodeDeliverer.hpp:56: instantiated from here
include/WNS/ldk/RandomAccessLink.hpp:64: error: conflicting return type specified for 'uint32_t wns::ldk::RandomAccessLink<RECEPTACLETYPE>::size() const [with RECEPTACLETYPE = wns::ldk::IDelivererReceptacle]'
include/WNS/ldk/Link.hpp:68: error: overriding 'size_t wns::ldk::Link<RECEPTACLETYPE>::size() const [with RECEPTACLETYPE = wns::ldk::IDelivererReceptacle]'

A fix is straightforward: uint32_t should be replaced by size_t in the header files, as well as in the tests and also in the CompoundSwitch*.?pp files in framework/dllbase/src/compoundSwitch

Revision history for this message
Maciej Muehleisen (mue-comnets) wrote :

Thank you for the patches. They have been applied to openwns-dllbase and openwns-library. I do not know if other projects need changes since we do not have a 64bit OS here. Compiling 32bit on Ubuntu 9.10 should work with the current version.

Changed in openwns-library:
status: New → Fix Committed
importance: Undecided → Medium
assignee: nobody → Maciej Muehleisen (mue-comnets)
Revision history for this message
Jan (jan-ellenbeck) wrote :
Download full text (3.8 KiB)

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::CommandP...

Read more...

Revision history for this message
Maciej Muehleisen (mue-comnets) wrote : Re: [Bug 484465] Re: Compiler error on 64bit system: conflicting return type specified for 'uint32_t' ... overriding "size_t"

Thank you for the detailed bug report. The code causing the SegFault is
currently still under development and further testing. We will see if
the problem will still be there after we upload the final version.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.