64-bit problems

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=) 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=) at /usr/include/boost/checked_delete.hpp:34
#7 0x00007f4fd9112a5a in _wrap_delete_gr_top_block_sptr (args=) 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 }

On Tue, May 13, 2008 at 11:46:00AM +0300, Juha V. wrote:

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.

We run GNU Radio on 64-bit machines all the time. No problem.

Are you getting any warnings from the compiler for your new block?
If so, make them go away.

Eric

Thanks. I fixed two very innocent looking warnings and now everything
works.

juha

On Wed, May 14, 2008 at 12:10:43PM +0300, Juha V. wrote:

Thanks. I fixed two very innocent looking warnings and now everything works.

Great! Glad to hear that fixed it.

Eric

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs