|Subject:||RE: [Discuss-gnuradio] GL sinks freeze|
|Date:||Sun, 27 Dec 2009 00:07:03 +0000|
Looks like it's not letting go of a lock:|
-> def lock(self): self._lock.acquire()
------freezes here, never returns------
It's hard for me to really get a handle on it because from what I know the Python debugger pdb doesn't allow you to interrupt execution interactively while the program is running, so I have to manually step through until the program locks, and then look for what the last instructions were. Best I can tell, the draw_waterfall function gets called twice during init and that goes fine, and then the window gets drawn, and I break on _on_paint() repeatedly (some hundred times or so). Eventually both waterfall displays get drawn, and then the control panel, and right after the control panel gets drawn, the program calls lock(self) and then never returns from it.
Does that help any? Sounds like something's not letting go of that lock, since Python's threading system holds _lock.acquire() in block until the existing lock is released.
I'll keep looking to try to narrow it down some. Do you know how I can set up pdb to trigger a breakpoint if lock() blocks for more than a second or so? If I could just break somewhere inside that condition, I could get a stack trace and tell you exactly where it's failing for me.
> Date: Sat, 26 Dec 2009 17:04:36 -0500
> From: address@hidden
> To: address@hidden
> CC: address@hidden
> Subject: Re: [Discuss-gnuradio] GL sinks freeze
> Its probably something to do with texture handling, since thats the only
> thing that makes the waterfall distinct from the other plotters. If you
> care to mess with some python code, see the _draw_waterfall function in
> gr-wxgui/src/python/plotter/waterfall_plotter.py Thats likely to be the
> place where the trouble is. Perhaps something more portable could be
> implemented (if that is the problem).
> Nick Foster wrote:
> > Josh et al,
> > Thanks for the tip re: SVN vs Git. I thought the repositories were linked -- guess I didn't look closely enough.
> > After installing the latest version via Git, the FFT sink appears to work fine, as does everything else -- except the waterfall sink. The test case built into the __main__ method of waterfallsink_gl.py gives me the attached screenshot. CPU usage is 0%, and the GUI does not respond to input. The color key shows 0dB all the way up and down the range, and the main window of the waterfall display is black. The frequency axis is marked correctly.
> > Using GRC to put together a simple flowgraph with a waterfall sink produces the same result, when OpenGL is enabled (via .gnuradio/config.conf). Non-GL waterfall works fine.
> > I've tried reinstalling/updating OpenGL, the nvidia kernel module, python-opengl, numpy, and python-wxgtk (2.8). No change in behavior. I tried disabling Ubuntu visual effects, with no change in behavior. Other OpenGL applications and games work correctly on this machine (Thinkpad T61p, Nvidia Quadro FX 570 GPU).
> > I don't have any real experience debugging Python applications, or OpenGL apps, for that matter. Using pdb reveals that the application seems fine up until it calls app.MainLoop(), which I suppose is pretty obvious. Then it locks up. How can I get started in finding the cause of this behavior?
> > Thanks again,
> > Nick
> >> Date: Tue, 22 Dec 2009 17:38:59 -0800
> >> From: address@hidden
> >> To: address@hidden
> >> CC: address@hidden
> >> Subject: Re: [Discuss-gnuradio] GL sinks freeze
> >> Nick Foster wrote:
> >>> Hi all,
> >>> I'm having some trouble with the OpenGL versions of the wxgui waterfall and FFT sinks. I'm using r11659 (8/30/09). To test the sinks, I just created a simple flowgraph with a 32ksps random stream (throttled) feeding the sinks, similar to what the built-in test methods for the sinks use.
> >> All the newest stuff is on git: http://gnuradio.org/cgit
> >> For some reason we wont clear the svn stuff, probably to confuse people...
> >>> The FFT sink freezes up after displaying a single frame in GL mode, and never updates. It then locks up, using 100% CPU. The waterfall sink doesn't even load; it just loads an empty gray box and then freezes. However, it doesn't use any CPU time. Both sinks work fine in non-GL mode. Interestingly, the GL versions of the scope sink and histogram sink seem to work fine, so I don't believe it to be an issue with my graphics driver (nvidia kernel driver on Ubuntu Hardy).
> >> The waterfall sink is making heavy use of textures and I could imagine
> >> that having problems but... the scope and the fft are exercising the
> >> exact same gl plotter base class. So I cannot fathom why the fft freezes
> >> for you and the scope works.
> >> The only thing that comes to mind is the update rate on the fft is
> >> probably larger than the scopes. Not that the rate should be enough to
> >> kill your cpu, but if the gl configuration has issues, that could
> >> explain it.
> >> You may try turning your ubuntu visual effects to off. They have been
> >> known to mess up other applications that try to use gl.
> >>> Are there any known issues with the GL waterfall or FFT sinks? Has anyone else encountered this issue? I'd like to use the extra functionality the GL waterfall sink offers.
> >>> Thanks,
> >>> Nick
> >>> _________________________________________________________________
> >>> Hotmail: Powerful Free email with security by Microsoft.
> >>> http://clk.atdmt.com/GBL/go/171222986/direct/01/
> >>> ------------------------------------------------------------------------
> >>> _______________________________________________
> >>> Discuss-gnuradio mailing list
> >>> address@hidden
> >>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > _________________________________________________________________
> > Hotmail: Free, trusted and rich email service.
> > http://clk.atdmt.com/GBL/go/171222984/direct/01/
> > ------------------------------------------------------------------------
Hotmail: Trusted email with Microsoft’s powerful SPAM protection. Sign up now.
|[Prev in Thread]||Current Thread||[Next in Thread]|