Re: [directfb-dev] Crash in GTK Directfb
Thanks....
I think I'm on to the root cause of a lot of problems.
Here is another patch I will check in its harmless but continue to read
Index: gdkwindow-directfb.c
===================================================================
RCS file: /cvs/directfb/gdk-directfb/gdkwindow-directfb.c,v
retrieving revision 1.110
diff -u -r1.110 gdkwindow-directfb.c
--- gdkwindow-directfb.c 13 Oct 2005 03:09:39 -0000 1.110
+++ gdkwindow-directfb.c 16 Nov 2005 13:48:22 -0000
@@ -405,7 +405,8 @@
_gdk_window_destroy (window, FALSE);
return NULL;
}
- impl->window->SetOpacity(impl->window, 0xFF );
+ if( desc.caps != DWCAPS_INPUTONLY )
+ impl->window->SetOpacity(impl->window, 0xFF );
break;
case GDK_WINDOW_CHILD:
The root proble is input only windows don't get a surface even nor do
they get a default event handler attached leading to a number if
issues later on I'm now crashing in
#1 0x0064c3d5 in fusion_reactor_dispatch (reactor=0x8c27250,
msg_data=0xbfdeaf04, self=true, globals=0x2232fc) at reactor.c:949
#2 0x0021b837 in dfb_window_dispatch (object=0x8c27148, message=0xbfdeaf04,
globals=0x2232fc) at ../../src/core/windows.h:101
#3 0x0021b808 in dfb_window_post_event (window=0x8c27148, event=0xbfdeaf04)
at windows.c:1111
#4 0x0021ac53 in dfb_window_destroy (window=0x8c27148) at windows.c:534
#5 0x001e332f in IDirectFBWindow_Destroy (thiz=0x8c272f8)
at idirectfbwindow.c:777
#6 0x00f3674c in _gdk_windowing_window_destroy (window=0x8c26f40,
recursing=0, foreign_destroy=0) at gdkwindow-directfb.c:526
#7 0x00f295b1 in _gdk_window_destroy_hierarchy (window=0x8c26f40,
For a input only window because no one is listening for it to close.
Now I can fix this by checking for reactors equal to null but should
input only windows
actually get a default no op surfaces so you don't have to guard for
them all over the place ?
Mike
On 11/16/05, Attilio Fiandrotti <fiandro@tiscalinet.it> wrote:
> 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: