Re: [directfb-dev] Crash in GTK Directfb
Mike Emmel wrote:
Thanks I tried using mudflap which looked cool but does not work with
shared libraries.
valgrind is way to slow. This looks juuust right. I'm assumming
MALLOC_CHECK_ is basically the same as electric fence i.e it puts in
unmapped pages ?
if this can help, i would suggest you to boot the mini.iso image with
install DEBIAN_FRONTEND=newt
this way you boot the textual frontend, then you can switch to VT2 and do
export DEBIAN_FRONTEND=gtk
export MALLOC_CHCCK_=n
debian-installer
this way you should be able to easily see malloc output.
I remember memory corruption problems have been a really big issue
during the first months of developement of the GTK frontend.
If compiled and run under GTKX, the GTK frontend never crashed up but it
used to crash continuously if compiled and run under GTKDFB 2.0.9.
If you checkout the GTK frontend sourcecode gtk.c
svn co
svn://svn.d-i.alioth.debian.org/svn/d-i/trunk/packages/cdebconf/src/modules/frontend/gtk
gtk
you'll see an hacky initialization of gtk_init() parameters and a set of
NULL vriable assignements at lines 1338-1358.
the set of null assignements was once needed in order to prevent GTKDFB
from crashing when run from inside the miniiso; note that nowadays the
GTK frontend works well even if those lines are commented at compile
time but no one has ever understood clearly the reason why those lines
of code were once needed and now they aren't.
i hope this helps
ciao
attilio
Reply to: