Re: memory leak? rtl problem?

Search this archive.

From: Sergio Masci (sergio@xcprod.com)
Date: Sun 01 Apr 2001 - 01:56:55 IST


> Hey all. I'm working with a set of C++ libraries I've created for use in
an
> embedded system with a touch panel, color LCD, and a GUI. The libraries
> handle all the GUI elements such as buttons, images, text boxes, labels,
> sliders, pulldown menus, and whatever else. The setup is multilayered
> graphically and event-wise, where an object "above" another object will
take
> precedent if the user touches it.

[snip]

> After a while of this running, the system will hang. It isn't a segfault,
> but a total hang. We have had problems with older versions of SVGALib
> wanting to call CLI and STI which will cause real time linux to crash, but
I
> didn't find any evidence of those calls in version 1.4.2.
>
> Is there any reason my object wouldn't delete properly or the bitmap
buffer
> delete properly? Or is there some reason that calling gl_getbox and
> gl_copyfromcontext 25 times a second would cause any problems? The
processes
> are working very fast, and there is plenty of time left in the system. On
> the screen I'm testing this on, there is a touch keyboard and all the
> buttons react just as fast as can be assuming you don't try and press one
> under the rectangle as it flies by.
>
> Thanks for any suggestions anyone might have.
>
> Steve

I don't use the gl library with svgalib and I haven't used rtLinux either,
so the help I am able to offer is very limited I'm afraid, but here are a
few suggestions.

If possible can you run you app under GDB (using a remote terminal). When it
locks up you might to able to interrupt it via GDB (have a look at the
archives for this mailing list for details regarding debugging svgalib
programs with gdb, in particular have a look at some of the posts by Russell
Marks and the thread "Re: debugging svgalib programs" - these should help)

Althernatively if you are able to log onto the machine running your svgalib
problem code, try sending the locked process an ABORT signal (kill -6), and
if you've enabled core dumps for it you should be able to do a postmortum on
it and maybe see where it was stuck.

Another approach would be to contiunually send debug info to a standalone
tty connected via a seiral link. Use a binary chop method to home in on the
problem area in your code.

Hope this helps

Regards
Sergio Masci


------------------------------------------------------------------
Unsubscribe:  To:   listbot@svgalib.org
              Body: unsubscribe linux-svgalib


This archive was generated by hypermail 2.1.4 : Wed 21 Jan 2004 - 22:10:23 IST