GNOME Bugzilla – Bug 604632
gtk 2.19.1 + directfb 1.4.3 Null pointer dereference at initialization
Last modified: 2010-08-25 02:35:50 UTC
This also happens with gtk 2.19.0 and directfb 1.4.2 I was trying to run svn snapshot of Navit. Gdb stuff: Program received signal SIGSEGV, Segmentation fault. IA__gdk_drawable_get_colormap (drawable=0x0) at gdkdraw.c:276 276 gdkdraw.c: No such file or directory. in gdkdraw.c (gdb) bt
+ Trace 219615
Meanwhile I am trying to dig deeper into this problem...
The same happens with gtk 2.18.5
The patch in bug #600789 may fix this crash.
(In reply to comment #2) > The patch in bug #600789 may fix this crash. Sorry for late reply... Sadly this patch doesn't fix this particular problem. private->parent is NULL in gdk_window_real_set_colormap() when it calls gdk_drawable_get_colormap(). And nothing sets it in _gdk_windowing_window_init(). I tried used following patch to overcome this issue, but then another crash happens... --- gtk+-2.18.5/gdk/gdkwindow.c.orig 2009-12-08 17:13:05.000000000 +0200 +++ gtk+-2.18.5/gdk/gdkwindow.c 2009-12-16 13:46:05.208592895 +0200 @@ -4779,7 +4779,7 @@ gdk_window_real_set_colormap (GdkDrawabl private = (GdkWindowObject *)drawable; /* different colormap than parent, requires native window */ - if (!private->input_only && + if (!private->input_only && private->parent && cmap != gdk_drawable_get_colormap ((GdkDrawable *)(private->parent))) gdk_window_ensure_native ((GdkWindow *)drawable);
Forgot to mention that I was testing your patch with gtk 2.18.5
Did some more testing. With my patch and without yours I get the same bug you pointed me to. Your patch really fixes it. It is very strange that Yan Weichuan did not experience my crash before the one in bug 600789. After applying both patches I hit assert in cairo_directfb_surface_create() In the following backtrace you can see that dfbsurface=0x0 is passed and so assert in cairo happens...
+ Trace 219866
Created attachment 153137 [details] [review] fix cairo usage the attached patch fixes cairo usage and cures the segfault
(In reply to comment #6) > Created an attachment (id=153137) [details] [review] the removal of the cairo version check in the above patch should not be a problem, since gtk requires cairo >= 1.6 anyway
Comment on attachment 153137 [details] [review] fix cairo usage the patch is incorrect, will have a better version soon :-)
Any update on cairo-related patch? I'm hitting this bug too...
I have the same problem; gdk_window_real_set_colormap() passes a NULL pointer to gdk_drawable_get_colormap(), which duly crashes the process. I'm using gtk+-2.19.7 and DirectFB-1.4.2 running on an HP iPAQ hx4700 (armv5tel).
Comments on the gtk-devel-list and gtk-list suggest that the DirectFB backend is "in a badly maintained state", is "heavily broken", that "the DirectFB route is a dead-end", and that "it seems no one works on fixing it". I have not followed development of the DirectFB backend so I am not able to comment. However, if these comments do accurately describe the current state of the DirectFB backend then shouldn't the maintainers be making a decision about its future? Namely that the DirectFB backend will be fixed or will be dropped.
apt-get install fbset fbset -i gedit /boot/grub/grub.cfg find quiet splash to quiet splash vga=789 gedit /etc/initramfs-tools/modules add fbcon vesafb gedit /etc/modprobe.d/blacklist-framebuffer.conf blacklist vesafb to #blacklist vesafb cd /dev ln -s fb0 fb update-initramfs -u gedit /usr/x11dfb/etc/directfbrc system=FBDev fbdev=/dev/fb0 wm=default mode=800x600 depth=32 pixelformat=ARGB https://wiki.ubuntu.com/FrameBuffer Open 2 vmwares one use Gdbserver and another GDB in eclipse, easier to debug gtk in directfb mode http://www.wretch.cc/blog/fatalfeel
(In reply to comment #11) > Comments on the gtk-devel-list and gtk-list suggest that the DirectFB backend > is "in a badly maintained state", is "heavily broken", that "the DirectFB route > is a dead-end", and that "it seems no one works on fixing it". I have not > followed development of the DirectFB backend so I am not able to comment. > > However, if these comments do accurately describe the current state of the > DirectFB backend then shouldn't the maintainers be making a decision about its > future? Namely that the DirectFB backend will be fixed or will be dropped. Your probably referring to my comments. The problem is no community has really formed around it thus its support is probably best described as adhoc vs unmaintained. I don't think its bad enough to be removed just a bit sad really. And to be honest I think the real problem is that the primary users of the port are companies and so far at least no company has stepped up to provide long term support despite the fact a fair number have benefited. This is a big problem with embedded opensource in general not just gtk/directfb. If this means the port is maintained via random patches form time to time then thats the way it works. As I said a bit sad but its just the way things have worked out. I don't think it should result in pulling the port. What needs to happen somehow is companies involved in embedded opensource software need to wakeup and realize they need to fund the fundamental support and help develop a vibrant opensource community. And we need world peace :) One of those two events might happen. If you pull the port then you can be pretty certain the embedded community will never become a good opensource citizen. Hopefully this sets the record strait.
(In reply to comment #11) > Comments on the gtk-devel-list and gtk-list suggest that the DirectFB backend > is "in a badly maintained state", is "heavily broken", that "the DirectFB route > is a dead-end", and that "it seems no one works on fixing it". I have not > followed development of the DirectFB backend so I am not able to comment. > However, if these comments do accurately describe the current state of the > DirectFB backend then shouldn't the maintainers be making a decision about its > future? Namely that the DirectFB backend will be fixed or will be dropped. Here is a good debug way use IDE for directfb http://www.wretch.cc/blog/fatalfeel
(In reply to comment #5) > Did some more testing. > With my patch and without yours I get the same bug you pointed me to. Your > patch really fixes it. It is very strange that Yan Weichuan did not experience > my crash before the one in bug 600789. > After applying both patches I hit assert in cairo_directfb_surface_create() > In the following backtrace you can see that dfbsurface=0x0 is passed and so > assert in cairo happens... If anyone fixed directfb bug in GTK 2.20.X or above please let me know
(In reply to comment #15) > (In reply to comment #5) > > Did some more testing. > > With my patch and without yours I get the same bug you pointed me to. Your > > patch really fixes it. It is very strange that Yan Weichuan did not experience > > my crash before the one in bug 600789. > > After applying both patches I hit assert in cairo_directfb_surface_create() > > In the following backtrace you can see that dfbsurface=0x0 is passed and so > > assert in cairo happens... > If anyone fixed directfb bug in GTK 2.20.X or above please let me know email:fatalfeel@hotmail.com
The directfb backend has been removed form GTK 3