Re: [Discuss-gnuradio] new tarballs: gnuradio-core-2.3 gr-audio-oss-0.3

[Eric Blossom]

On Mon, Nov 08, 2004 at 09:07:48PM +0100, Stephane Fillod wrote:
> On Thu, Nov 04, 2004 at 10:58:50PM -0800, Eric Blossom wrote:
> > gnuradio-core-2.3 fixes build problems that we have seen on a few
> > platforms.  The primary symptom was "make check" failing in test_all.
> > There is now code to detect and avoid buggy implementations of shm_open.
> 
> Something like this (from test_vmcircbuf)?
> 
> Testing gr_vmcircbuf_mmap_shm_open_factory...
> ....... gr_vmcircbuf_mmap_shm_open_factory: Failed
> gr_vmcircbuf_factory::test_factory (gr_vmcircbuf_mmap_shm_open_factory): 
> caught SIGBUS
> 

Yes.

> BTW, I have strange segfaults with "make check" in test_all:

Hmmm...

> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1210185472 (LWP 14243)]
> 0xb7e6618b in std::basic_string<char, std::char_traits<char>,
> std::allocator<char> >::basic_string ()
>    from /usr/lib/libstdc++.so.6
> (gdb) bt full
> #0  0xb7e6618b in std::basic_string<char, std::char_traits<char>,
> std::allocator<char> >::basic_string
>     () from /usr/lib/libstdc++.so.6
> No symbol table info available.
> #1  0xb7f46d13 in std::_Rb_tree<std::string, std::pair<std::string
> const, std::string>, std::_Select1st<std::pair<std::string const,
> std::string> >, std::less<std::string>,
> std::allocator<std::pair<std::string const, std::string> > >::_M_copy
> (this=0xbffff60c, __x=0x1, __p=0xbffff610) at stl_construct.h:81
> No locals.
> #2  0xb7fca5c9 in qa_runtime::suite () at stl_tree.h:464
> No locals.
> #3  0x080489af in main (argc=1, argv=0xbffff7e4) at
> ../../../gnuradio-core/src/tests/test_all.cc:38
>         runner = <incomplete type>
>         was_successful = 112
> 
> 
> My system is Debian with kernel 2.6.9-1-k7 and gcc-3.4 (GCC) 3.4.2
> (Debian 3.4.2-3), gnuradio-core configure'd with --disable-static.
> 
> > In addition we have determined that GNU Radio triggers bugs in g++
> > version 3.3 on the x86 platform.  If you're using g++ 3.3, please
> > either upgrade to 3.4 or downgrade to 3.2.  Both are known to work.
> 
> Could it be possible to add the test for the broken toolchain in
> configure.ac ? What the symptoms are like?

It would be possible to add the test if we really knew what was wrong
and what to check for.  We can definitely check for g++ 3.3 on x86.
FWIW, the Apple release of g++ 3.3 for PPC seems to work fine.

I've never seen the particular failure you show above.  Is it possible
that libstdc++ was compiled with g++ 3.3?

I'm not sure if the problems are related to buggy libs or good libs
compiled with buggy compilers, or both.

g++ 3.3 on x86 definitely has problems.  In fact, if you use g++ 3.3
the very straight forward signal handling used in this work around
doesn't work:

> Testing gr_vmcircbuf_mmap_shm_open_factory...
> ....... gr_vmcircbuf_mmap_shm_open_factory: Failed
> gr_vmcircbuf_factory::test_factory (gr_vmcircbuf_mmap_shm_open_factory): 
> caught SIGBUS

I suspect the g++ bug is related to failing to do something correctly
with constructors and destructors on stack allocated objects.  I did
notice in the GDB 6.2 manual a comment that indicates that the C++ ABI
changed (again!) in 3.3 and 3.4, and that at this moment GDB isn't
able to set breakpoints in constructors or destructors.

Eric