Re: [Discuss-gnuradio] out of memory, process killed

[Jim Lindstrom]

Eric,

I haven't been able to reproduce the problem yet, but I'll keep an eye out and let you know if I can.

When I ran into ther problem, my machine had been up for a few weeks
and I'd been doing some heavy development on it.  I was building a
program linked against libusrp (not surprisingly, my program crashed or
was CTRL-Ced frequently during development) and I'd also been
occasionally using the siggen python app to test out my hardware
setup.  At some point (presumably due to the combination or solo
contribution of either or both of those activities), I started getting
the behavior described in my first email (below).  Here's some
info on my setup:
$ python -V
Python 2.3.4

$ uname -a
Linux popov.aase.net 2.6.9-5.ELsmp #1 SMP Wed Jan 5 19:30:39 EST 2005 i686 i686 i386 GNU/Linux

My GNURadio and USRP packages appear to be whatever was current as of
March 30 2005: gnuradio-core-2.5, gnuradio-examples-0.4, gr-usrp-0.5,
gr-wxgui-0.3, usrp-0.8.  

jbl

On 3/17/06, Eric Blossom <address@hidden> wrote:

On Fri, Mar 17, 2006 at 06:33:39PM -0600, Jim Lindstrom wrote:
> I'm using the USRP board and libusrp for some prototyping right now.  I'm
> running into some strange behavior where after my machine has been up for a
> while and I've used libusrp a fair ammount (after maybe a day or two of
> use), I start to get the process being killed and /var/log/messages
> reporting that the process ran out of memory.  I obviously assumed that the
> problem was in my code, but interestingly, the usrp's siggen python script
> has the same behavior.  Are there any known memleaks in past versions?  I'm
> using the 2.6 kernel and the previous gnuradio codebase.
>
> Is it possible that my userspace app is causing this behavior somehow?  Any
> suggestions for debugging this problem?  I'd be happy to provide more
> details (logs of /var/log/messages, etc) when I get back to work on Monday,
> if that would be of use to anyone in helping me diagnose the problem.
>
> jbl

Jim, I do know for a fact that there's a leak in the wxPython code.
It's in the wx.BufferedDC primitive.  I haven't yet cooked up a small
test case to send to the maintainers, but I'm positive about the
location of that leak.  (This one show up if you leave
usrp_wfm_rcv_pll running for a while).  You can see it grow a few KB
every few seconds with ps.

Do you have an example script that demonstrates the problem?
Can you reproduce it with no wxPython code?

Does the version of usrp_siggen that's in CVS leak for you?
What OS / distribution / etc are you using?

Eric