On Sun, Sep 24, 2006, Attilio Fiandrotti wrote: > Meanwhile, if you want to see if you can reproduce the "BOOM" bug in GTK > from CVS, you can proceed as follows (you'll need a ssh terminal). > -Run gtk-demo and open the hypertext app > -Attach gdb to the process and set a breakpoint at > gtk_target_table_free() and continue running > -close the hypertext window with meta-c, you'll enter the > gtk_target_table_free() > -At some point you should get a crash in the for() loop, can you > reproduce this?
Ok, I suppose I could reach the crash and setup an initial environment for testing, but that's not good enough for debugging for now. Here's what I did: - boot with a vesa framebuffer on the kernel command line - build gtk-demo against directfb from the gtk source: * fakeroot debian/rules debian/stampdir/configure-stamp-directfb * cd debian/tmp/build/directfb/demos/gtk-demo * make (should fail at the final link) * gcc $(pkg-config --cflags --libs gtk+-directfb-2.0) -o gtk-demo *.o * launch ./gtk-demo as root - I also had to setup mode= in /root/.directfbrc and capslock-meta So, I could launch the hypertext app, and close it with CapsLock+c. I still had the mouse afterwards, but I did *not* have the etch-a-sketch bug. Instead, nothing else was happening, I couldn't do anything with the interface anymore. I couldn't switch VT anymore. Since I have a single console, it's not easy to debug the graphical problem; perhaps there's a virtual output for DirectFB (like Xvfb)? I think I will setup a qemu or vmware to debug this. Thanks for the hints! Bye, -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
