Segmentation fault using qt gui sink

Sorry, now with example

Hi all,

if I use a qt-gui sink in a flowgraph I get a segmentation fault on the
tb.stop() call.
That is a problem as I use this together with a wavfile-sink.

Due to the segfault the wav file header is not written and I have to
use a hexeditor to correct the header data to be able to read the
samples in a wavfile source.

The segfault even happens if I remove the wavfile-sink.
A small example is attached.

I’m using gnuradio from git together with gentoo 64 bit linux.

Thanks in advance


On Mon, Mar 18, 2013 at 6:47 AM, Volker S. [email protected] wrote:

Sorry, now with example

I’ve run your example on the current master and not getting a segfault.

If there is a way you can get a gdb backtrace and the exact commit ID
I’d appreciate it.


Hi Jonathan,

I got no meaningful backtrace. That is all I got:

Program received signal SIGSEGV, Segmentation fault.
0x00000000000000c1 in ?? ()
(gdb) bt
#0 0x00000000000000c1 in ?? ()
#1 0x00007fc0ce119fcc in ?? ()
#2 0x0000000002849c10 in ?? ()
#3 0x000000000286b050 in ?? ()
#4 0x000000000286b068 in ?? ()
#5 0x00007fc0ce11a049 in ?? ()
#6 0x0000000002869240 in ?? ()
#7 0x00007fc0ce398630 in ?? ()
#8 0x00007fc0de618720 in ?? ()
#9 0x0000000000000000 in ?? ()

In my message log I see:[5074]: segfault at 81 ip 0000000000000081 sp
00007fffa0466758 error 14 in python2.7[400000+1000]

This happens behind
To verify this I introduced some print statements into the tb- block
source and put a line
raw_input('Press Enter to quit: ')
behind tb.stop()

Then I get:
+++gr_top_block stop
+++gr_top_block_impl stop
+++gr_sched_tpb stop
+++gr_sched_tpb stopped
+++gr_top_block_impl sched stopped
+++gr_top_block stopped
Press Enter to quit:

Perhaps this is a gentoo related problem and it may arise as I’m forced
to use boost 1.52. But I can’t downgrade boost as this would require a
downgrade of the glibc which is not supported on gentoo.

Commit id is

commit 7774331476979a530288eb8217d19f8f7af64ed1
Merge: 3421633 4a030cb
Author: Tom R. [email protected]
Date: Sat Mar 16 10:30:16 2013 -0400

Any ideas ?


Am 18.03.2013 18:31, schrieb Johnathan C.: