On Wed, Apr 13, 2011 at 5:33 PM, Josh Blum
<address@hidden> wrote:
> If you find that it's not working for you or still producing segmentation
> faults on close, please let me know (and let me know your OS, CPU, and any
> other relevant features you can think of). I have run it on a few machines
> and various VMs, but it's a limited set. You can try the
> gr-qtgui/apps/pyqt_example_c.py as a test.
>
So I put together a simple flow graph in grc, noise -> throttle -> qt
sink. I ran it repeatedly and alt + f4'd. Here are the results. Python
app attached. Ubuntu 10.10 x64 latest gnuradio master
e8ff9ef4bb77517428e1208ff4b3551a38107bbd
address@hidden:~/work/grc$ ./top_block.py
Segmentation fault
address@hidden:~/work/grc$ ./top_block.py
address@hidden:~/work/grc$ ./top_block.py
Segmentation fault
address@hidden:~/work/grc$ ./top_block.py
address@hidden:~/work/grc$ ./top_block.py
Segmentation fault
address@hidden:~/work/grc$ ./top_block.py
Segmentation fault
address@hidden:~/work/grc$ ./top_block.py
Segmentation fault
address@hidden:~/work/grc$ ./top_block.py
address@hidden:~/work/grc$ ./top_block.py
address@hidden:~/work/grc$ ./top_block.py
address@hidden:~/work/grc$ ./top_block.py
address@hidden:~/work/grc$ ./top_block.py
address@hidden:~/work/grc$ ./top_block.py
address@hidden:~/work/grc$ ./top_block.py
address@hidden:~/work/grc$ ./top_block.py
address@hidden:~/work/grc$ ./top_block.py
Segmentation fault
address@hidden:~/work/grc$ ./top_block.py
Segmentation fault
address@hidden:~/work/grc$ ./top_block.py
address@hidden:~/work/grc$ ./top_block.py
address@hidden:~/work/grc$ ./top_block.py
address@hidden:~/work/grc$ ./top_block.py
Segmentation fault
address@hidden:~/work/grc$ ./top_block.py
address@hidden:~/work/grc$
So it prints segfault when I exit the app for many of those runs. I had
also tried this test with a UHD block where the destructors had a print
in it. What I observed was the the destructor w/ the print was not
called most of the time, even when it didnt print segfault. So my guess
is that many of those seemingly successful exit events are not good.
Can you run my app in succession 20 times and see if it says segfault?
Thanks,
-Josh
Well, yes, Josh, sure this one crashes. That's because you didn't subscribe to the new "Best QtGui Programming Practices" that I have not published, or, you know, even written.
Without getting to deep into this, the problem is in the shared responsibilities between the Python world and the C++ world. I don't completely understand the series of events, but the crux o the problem seems to be who gets to the destructors first.
In the case of your program, it's the self._qtgui_sink_x_0_win object that's the problem. If you don't make it a member of the class, that is, drop the "self." part, it _should_ work fine. My understanding, which could be wrong, is that as a local variable, it gets destroyed in the right order.
Multiple runs of pyqt_example_c.py with Valgrind showed no changes in lost memory, which tells me that the right destructors get called.
But seeing this, I don't think I made this change to GRC.
Tom