On Wed, Apr 13, 2011 at 5:33 PM, Josh Blum <j...@joshknows.com> 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 > > jblum@blarg:~/work/grc$ ./top_block.py > Segmentation fault > jblum@blarg:~/work/grc$ ./top_block.py > jblum@blarg:~/work/grc$ ./top_block.py > Segmentation fault > jblum@blarg:~/work/grc$ ./top_block.py > jblum@blarg:~/work/grc$ ./top_block.py > Segmentation fault > jblum@blarg:~/work/grc$ ./top_block.py > Segmentation fault > jblum@blarg:~/work/grc$ ./top_block.py > Segmentation fault > jblum@blarg:~/work/grc$ ./top_block.py > jblum@blarg:~/work/grc$ ./top_block.py > jblum@blarg:~/work/grc$ ./top_block.py > jblum@blarg:~/work/grc$ ./top_block.py > jblum@blarg:~/work/grc$ ./top_block.py > jblum@blarg:~/work/grc$ ./top_block.py > jblum@blarg:~/work/grc$ ./top_block.py > jblum@blarg:~/work/grc$ ./top_block.py > jblum@blarg:~/work/grc$ ./top_block.py > Segmentation fault > jblum@blarg:~/work/grc$ ./top_block.py > Segmentation fault > jblum@blarg:~/work/grc$ ./top_block.py > jblum@blarg:~/work/grc$ ./top_block.py > jblum@blarg:~/work/grc$ ./top_block.py > jblum@blarg:~/work/grc$ ./top_block.py > Segmentation fault > jblum@blarg:~/work/grc$ ./top_block.py > jblum@blarg:~/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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
