[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 MALLOC_CHCCK_=n

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



Reply to: