Hi list,
I wanted to update everyone that I will be updating gr-qtgui in the
master
branch tomorrow. I wanted to warn everyone that this WILL change the
API.
These changes in the code are mostly related to the stability of the
qtgui
interface and prevents the segmentation fault that we were seeing
before. It
does not address some of the performance issues we have discussed; those
are
still to come.
I ended up cleaning up some of the cruft in the code, and I removed any
trace of the former 3D waterfall. I also got rid of most of calls to
OpenGL-based stuff. I couldn’t completely get rid of this, because some
of
the calls to QWT don’t work without linking against libQtOpenGL.
The main changes in the API are that I took out the args in the
constructors
to turn on/off the 3D waterfall and the OpenGL flag. If you have been
doing
anything with the QtGui sinks, watch out for this change, as it will
affect
how your display works. If you have been using the QtGui interface in
GRC,
you should be fine, as the GRC files have all been updated to work with
the
new interface.
Another change is that I have exposed the redraw update time through
Python.
This means that you can use the “set_update_time(double)” method on a
QtGui
sink in Python to set the refresh rate of the plots. This won’t reduce
the
overhead too much right now, since many of the math is computed
regardless
of the update time. This is on my list of improvements in the next
round.
If you are up for helping me vet this, you can find it as the “qtgui”
branch
on my github account:
git://github.com/trondeau/gnuradio.git
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.
Thanks,
Tom
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
On Wed, Apr 13, 2011 at 5:33 PM, Josh B. [email protected] wrote:
So I put together a simple flow graph in grc, noise → throttle → qt
jblum@blarg:~/work/grc$ ./top_block.py
jblum@blarg:~/work/grc$ ./top_block.py
Segmentation fault
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
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.
its never easy is it…
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.
I removed the “self.” and still seeing the same results.
But, you gave me an idea that there might be this unhappy deconstructor
race condition. So, I tried deleting the qapp after exec() and that made
it better. Also and rather, stopping the top block make it better; so
maybe it was getting data to draw and somebody already destroyed the qt
graphics stuff.
So, the reason I didnt stop the top block:
http://gnuradio.squarespace.com/examples
I will give this a more conclusive test tomorrow, but the fix seems
worth while anyhow.
http://gnuradio.org/cgit/gnuradio.git/commit/?id=e762abc703e3224b54466685bf51b3fa90ee8edc
-Josh
On Thu, Apr 14, 2011 at 1:21 AM, Josh B. [email protected] wrote:
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.
its never easy is it…
worth while anyhow.
http://gnuradio.org/cgit/gnuradio.git/commit/?id=e762abc703e3224b54466685bf51b3fa90ee8edc
-Josh
Hmm… that’s very disappointing. I was unable to reproduce this on
three of
my machines (Core2Quad, i7, and i7 (sandybridge)) and a couple of VMs.
But I
did see a segfault about once in twenty on my Core2Duo. So that that for
what you will.
I tried your fix and also applied the fix to pyqt_example_f.py and ran
both
about 50 times in a row without seeing the seg fault, so that seems to
fix
it. Either that, or it just reduces the probability of it occurring even
more… But I think we go with it until someone reports another
problem.
Good catch, thanks!
Tom
On 04/14/2011 09:40 PM, Tom R. wrote:
reports another problem.
Good catch, thanks!
Tom
I think this speaks to the monumental complexity of modern software.
The surprising thing is not how well it generally works, but that
it works at all.
I think that people who aren’t software developers (heck, technology
developers in general) have no grasp of the horrendous complexity we
juggle in our heads every day, and generally “just make it work”.
On Thu, Apr 14, 2011 at 9:48 PM, Marcus D. Leech [email protected]
wrote:
fix it. Either that, or it just reduces the probability of it occurring even
I think that people who aren’t software developers (heck, technology
developers in general) have no grasp of the horrendous complexity we
juggle in our heads every day, and generally “just make it work”.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
That’s a good point, Marcus. It also brings me back to why we have so
many
dependencies in the project, which I’ve often heard people complain
about.
But the thousands of lines of code that those dependencies have means
that
we don’t have to re-write them and can then build more complex systems
because of it. The whole “standing on the shoulders of giants” concept.
But
it definitely adds to the complexity and the potential problems with
stability and compatibility that we need to work on. Though the effort
of
dealing with the latter problems no where near outweighs the former
benefits.
Then again, since we’re talking about the fact that these things work at
all, even though I understand the physics and have flown in them before,
I’m
still not convinced that a 747 can fly*.
Tom
*Note: This remark was not intended to be a factual statement.
On 18/04/2011 11:16 AM, Philip B. wrote:
Philip
We somewhat already have that, at least at the hardware source/sink
level.
Adding further formalized interfaces for things like GUI components
would be a good thing™.
I worry that adding further levels of abstraction/compartmentalization
would negatively impact performance, and performance is
a crucial attribute of any DSP system.
On 04/18/2011 10:20 AM, Tom R. wrote:
–
it definitely adds to the complexity and the potential problems with
stability and compatibility that we need to work on. Though the effort of
dealing with the latter problems no where near outweighs the former
benefits.
I’d like to see GNU Radio divided into logical pieces that are seperate
from each other. I believe this would help with the dependency that
exists today.
The core of GNU Radio is the code that defines how blocks are built,
connected, and executed. From there you would add signal processing
blocks, gui blocks, hardware interface blocks, etc as needed for the
specific application/environment.
Philip
On Mon, Apr 18, 2011 at 11:28 AM, Marcus D. Leech [email protected]
wrote:
application/environment.
would negatively impact performance, and performance is
a crucial attribute of any DSP system.
Philip and I have talked about this before. What he really means is
splitting out gnuradio-core into more top-level blocks. Eventually, we
probably want a gnuradio-runtime that only contains the basic block
parent
classes and and the scheduler. This way, for getting the runtime engine
going, you need a minimum of dependencies. We would then have other top
level blocks containing the other blocks that are currently in
gnuradio-core. I’ve already started splitting off a gr-digital block in
one
of my branches to this effect.
Tom