[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] error

From: Martin Dvh
Subject: Re: [Discuss-gnuradio] error
Date: Tue, 11 Jan 2005 06:39:52 +0100
User-agent: Mozilla Thunderbird 0.9 (X11/20041124)

Ramakrishnan Muthukrishnan wrote:
On Mon, January 10, 2005 11:44 pm, Eric Blossom said:

On Mon, Jan 10, 2005 at 01:39:12PM +0100, Martin Dvh wrote:

I have a gnuradio cvs version from a while back which was compiled with
I have a recent cvs version compiled with gcc 3.4 which fails with a
segmentation fault.

gcc-3.4 --version

gcc-3.4 (GCC) 3.4.2 (Debian 3.4.2-2)

CC=gcc-3.4 CPP=cpp-3.4 CXX=g++-3.4 ./configure
make CC=gcc-3.4 CPP=cpp-3.4 CXX=g++-3.4
make CC=gcc-3.4 CPP=cpp-3.4 CXX=g++-3.4 install
cd src/tests

Segmentation fault

Still gnuradio seems to work sort-of. I do see some strange effects.

Did the test program catch the error and say it caught a SIGBUS?
I just got the output as shown above:
>>>Segmentation fault

Does it log on any other places apart from standard out?

To try to get it to work with gcc 3.3 I did a apt-get updat  && apt-get 
and also removed an old version of swig1.3.21 which I found on my system.
When I tried to ./bootstrap (using version 1.7 of the autotools) ./configure 
./make and ./make check
I got using gcc 3.3:
Making check in tests
make[2]: Entering directory 
make  check-TESTS
make[3]: Entering directory 
.Testing gr_vmcircbuf_sysv_shm_factory...
....... gr_vmcircbuf_sysv_shm_factory: OK
Testing gr_vmcircbuf_mmap_shm_open_factory...
FAIL: test_all
1 of 1 tests failed
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory 
make[2]: *** [check-am] Error 2
make[2]: Leaving directory 
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory 
make: *** [check-recursive] Error 1

Then I ran the test_all manually and got:
.Testing gr_vmcircbuf_sysv_shm_factory...
....... gr_vmcircbuf_sysv_shm_factory: OK
Testing gr_vmcircbuf_mmap_shm_open_factory...

So no Segfault with gcc 3.3. but still an error with not much clues what is 
going wrong, only Aborted.
I have not retried with gcc-3.4 yet. (A build takes quite a while on my machine)

Job de Haas succeeded with exactly the same versions installed. But I don't know of he completely removed gcc-3.4 and libstdc++6 or just used gcc-3.3 as I am doing.

Now I have the following versions installed.

libstdc++5              3.3.5-5    should be used by gcc-3.3
libstdc++6-dev          3.4.3-6    should only be used by gcc-3.4
libstdc++5-3.3-dev      3.3.5-5    should be used by gcc-3.3
libstdc++5-3.3-doc      1:3.3.5-5
libstdc++6              3.4.3-6    should only be used by gcc-3.4
gcc-3.3                 1:3.3.5-5
gcc-3.3-base            1:3.3.5-5
gcc-3.4-base            3.4.3-6
libgcc1                 3.4.3-6
gcc-3.4                 3.4.3-6
gcc                     3.3.5-1
g++                     3.3.5-1
g++-3.3                 3.3.5-5
g++-3.4                 3.4.3-6
automake1.7             1.7.9-6

further I now have the exact same versions as Job de Haas:
ii  autoconf       2.59a-2
ii  automake1.4    1.4-p6-8
ii  autotools-dev  20041130.2
ii  libtool        1.5.6-3
ii  swig           1.3.22-5
ii  libswig1.3.22  1.3.22-5
ii  pkg-config     0.15.0-4
ii  fftw3          3.0.1-11
ii  fftw3-dev      3.0.1-11
ii  python2.3      2.3.4-18
ii  python2.3-dev  2.3.4-18
ii  libboost-dev   1.31.0-9
ii  libboost-python-dev 1.31.0-9
ii  tetex-base     2.0.2c-3
ii  tetex-bin      2.0.2-25
ii  gcc            3.3.5-1
ii  gcc-3.3        3.3.5-5
ii  gcc-3.3-base   3.3.5-5
ii  libgcc1        3.4.3-6
ii  g++            3.3.5-1
ii  g++-3.3        3.3.5-5
ii  libstdc++5     3.3.5-5
ii  libstdc++5-3.3-dev 3.3.5-5

This is a problem somewhere in your Debian installation.
I'm not a Debian user, so I'm not inclined to track this down.
The problem could be that some library, e.g., libstdc++ is built with
the buggy compiler.  I've seen two possibly related problems.  These
problems do not show up on other GNU/Linux systems such as Mandrake or
FC 2 or 3.

(1) That shm_open was returning a non-zero value that was in fact not
(2) That constructor/destructors of stack allocated classes were not
   being properly handled.

I will try reproducing this problem tonight and debug it. I suspect that
some program in the chain has incompatible ABI. Debian has many versions
of c++ libraries (libstdc++{5,6}) and compilers in the archive, so one has
to be careful, to chose the right one.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]