Hi Roland.
You might want to try the option "debugmem" although it is a bit like
killing a fly with a double barrel gun.
Also, you can try --enable-trace when doing ./configure, this will
print, after program exit, a stackdump of the "create" of the remaining
allocations.
For synchronising; I have normally success by using the "same" way as
DirectFB debug messages, namely fprintf(stderr,"message\n");
For DFB_DEAD, this should come if thiz->priv is set to 0. However, we do
a free(thiz) so it is possible that the location is already taken by
something else later. If you have enough memory you can consider to
remove the bottom D_FREE in DIRECT_DEALLOCATE_INTERFACE in
lib/direct/interface.h.
Greets
Niels
Roland Schaefer wrote:
Hi. I am trying to track down three (out of quite a huge number of)
surfaces which seem not to get freed correctly by my application. I have
re-compiled DFB with debugging on and still can't find the rogue
surfaces. One problem is that my own debug output is not in sync with
the DFB debug output, which makes finding the place where my code is
missing a Release call sort of hard to find. So, is there anything like
XSynchronize? Or can I check the reference counter explicitly? And btw,
I never get DFB_DEAD after freeing my surfaces, even though I am in
debug mode. Is that normal?
Cheers
Roland
_______________________________________________
directfb-users mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
--
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-users mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
