discuss-gnuradio
[Top][All Lists]
Advanced

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

[Discuss-gnuradio] 64-bit problems


From: Juha Vierinen
Subject: [Discuss-gnuradio] 64-bit problems
Date: Tue, 13 May 2008 11:46:00 +0300

Hi,

I have been compiling my own block on a 64-bit machine and I am
running into problems (segmentation fault). The code works fine on
32-bit architectures.

I haven't found anything yet, and the stack trace doesn't give any
clues either. valgrind also says nothing. It seems that the segfault
comes after my block has been destroyed. I am using two threads in a
block, but I make sure that the helper thread is killed before the
block is destructed. Is it "against the rules" to have two threads in
one block? The segfault is caused by some scary looking boost shared
pointer inline assembler. Here is some debug info.

Has anyone run into anything like this? Any clues on what might be going on?

Starting program: /usr/bin/python qa_filesinkseq.py
[Thread debugging using libthread_db enabled]
[New Thread 0x7f4fda1656e0 (LWP 12242)]
.Test 4
[New Thread 0x415c3950 (LWP 12252)]                   <-- new flowgraph
[New Thread 0x41e14950 (LWP 12253)]                   <-- helper thread
..........[Thread 0x41e14950 (LWP 12253) exited]      <-- helper thread ended
done
Write speed 35.96 MB/s
[Thread 0x415c3950 (LWP 12252) exited]                <-- flowgraph destroyed?
desctructor done

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f4fda1656e0 (LWP 12242)]
0x00007f4fd8e4e49b in ~gr_edge (this=0x13558d0) at
/usr/include/boost/detail/sp_counted_base_gcc_x86.hpp:50
50          );
Current language:  auto; currently c++
(gdb) bt
#0  0x00007f4fd8e4e49b in ~gr_edge (this=0x13558d0) at
/usr/include/boost/detail/sp_counted_base_gcc_x86.hpp:50
#1  0x00007f4fd8e4e7e8 in ~gr_flowgraph (this=0x11fae20) at
/usr/include/c++/4.2/bits/stl_construct.h:107
#2  0x00007f4fd8e56432 in
boost::detail::sp_counted_impl_p<gr_flowgraph>::dispose (this=<value
optimized out>) at /usr/include/boost/checked_delete.hpp:34
#3  0x00007f4fd8e6023a in ~gr_hier_block2_detail (this=0x12d5dd0) at
/usr/include/boost/detail/sp_counted_base_gcc_x86.hpp:145
#4  0x00007f4fd8e5d6f0 in ~gr_hier_block2 (this=0x134df60) at
gr_hier_block2.cc:51
#5  0x00007f4fd8e6e87d in ~gr_top_block (this=0x134df60) at gr_top_block.cc:54
#6  0x00007f4fd9128ef1 in
boost::detail::sp_counted_impl_p<gr_top_block>::dispose (this=<value
optimized out>) at /usr/include/boost/checked_delete.hpp:34
#7  0x00007f4fd9112a5a in _wrap_delete_gr_top_block_sptr (args=<value
optimized out>) at
/usr/include/boost/detail/sp_counted_base_gcc_x86.hpp:145
#8  0x000000000041ab7d in PyObject_CallFunctionObjArgs
(callable=0x7f4fd9ff06c8) at ../Objects/abstract.c:1861
#9  0x00007f4fd9100a48 in PySwigObject_dealloc (v=0x12f78a0) at
gnuradio_swig_py_runtime.cc:1451

(gdb) list -
        inline int atomic_exchange_and_add( int * pw, int dv )
36      {
37          // int r = *pw;
38          // *pw += dv;
39          // return r;
40      
41          int r;
42      
43          __asm__ __volatile__
44          (
(gdb) list
45              "lock\n\t"
46              "xadd %1, %0":
47              "=m"( *pw ), "=r"( r ): // outputs (%0, %1)
48              "m"( *pw ), "1"( dv ): // inputs (%2, %3 == %1)
49              "memory", "cc" // clobbers
50          );
51      
52          return r;
53      }




reply via email to

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