Created attachment 3103[details]
workaround to prevent crash
openbox has segfaulted several times when running gtk3 programs, since updating gtk3 to version 3.4.
Unfortunately I haven't been able to reproduce the crash consistently, it seems related to pop-up dialogs / message boxes from gtk3 programs. I have captured a backtrace:
Thread 1 (Thread 0x7ff0fed10740 (LWP 14932)):
#0 0x000000000041e4e2 in client_configure (self=0x0, x=21, y=55, w=1202, h=
924, user=1, final=1, force_reply=0) at openbox/client.c:3057
#1 0x00000000004413c8 in moveresize_end (cancel=1) at openbox/moveresize.c:333
#2 0x000000000042be56 in event_handle_client (client=0x15994a0, e=
0x7fff8a1bdb60) at openbox/event.c:1491
#3 0x0000000000429b35 in event_process (ec=0x7fff8a1bdc80, data=0x0)
at openbox/event.c:625
#4 0x00007ff0fcd07186 in event_read (source=0x15abf50, callback=0, data=0x0)
at obt/xqueue.c:338
#5 0x00007ff0fe044d6a in g_main_context_dispatch ()
from /usr/lib64/libglib-2.0.so.0
#6 0x00007ff0fe045130 in ?? () from /usr/lib64/libglib-2.0.so.0
#7 0x00007ff0fe045535 in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0
#8 0x0000000000444015 in main (argc=1, argv=0x7fff8a1be028)
at openbox/openbox.c:378
It seems moveresize_end is being called but moveresize_client is a NULL pointer - I added a NULL pointer check to the start of moveresize_end to print a warning instead of crashing.
This is a huge PITA for me. Not really because I'm losing work, but because my window arrangement and such is lost.
Edward, does this change any functionality or is it just an error check?
It's just an error check.
I still haven't been able to find some exact steps that always reproduce the crash (or put a message into openbox debug output with the patch), but the window involved always seems to be nautilus.
I can freely reproduce this consistently and at will (with current openbox git as well as stable), using evince (and adwaita theme).
1. open evince (windowed), no need to have a document open,
2. drag a little by the top toolbar area (#1 in attached picture),
3. click on a toolbar separator (#2).
Hah. That's ridiculous. I'm certainly not doing that when I get a crash but I hope it helps come to an agreeable solution.
In any event, since I first posted here and applied Edward's patch, I haven't had a single crash on two different machines \times two different users.
Thank you Edward =)
Comment 6Pablo Olmos de Aguilera C.
2012-05-07 00:47:13 EDT
I found that the bug is always reproducible when you click inside or around the location bar in nautilus (if not once, try a couple of times). I've tried openbox from git and stable. I still haven't tried the workaround, but I will as soon as possible.
Just FYI, with the exact same steps nautilus crash in xmonad, with the only difference that it doesn't kill X, with gnome3 the bug doesn't happen. I believe it has to do with gtk 3.4 (latest update I believe).
If you point me how to help I'll gladly do it :)
Yes, this makes Openbox unusable for me on Fedora 17.
The problem is that Openbox expects the moveresize_client to be set,
i.e. a corresponding call to moveresize_start should have been made
first.
The GTK+ change was made in (reverting these also fixed the issue):
https://bugzilla.gnome.org/show_bug.cgi?id=669208http://git.gnome.org/browse/gtk+/commit/?id=db2eb85e4af9d8f191fe1ade53ec85a94b326c9f
and a followup fix:
https://bugzilla.gnome.org/show_bug.cgi?id=673328http://git.gnome.org/browse/gtk+/commit/?id=7b0fd635fa39a27693655171a4cdc0150ae476ed
"The special value _NET_WM_MOVERESIZE_CANCEL also allows clients to cancel the
operation by sending such message if they detect the release themselves
(clients should send it if they get the button release after sending the move
resize message, indicating that the WM did not get a grab in time to get the
release)."
This seems to indicate that in certain cases, the client will send the CANCEL message
without moveresize_client being set first. So Edward's patch to simply bail out
if moveresize_client == NULL is probably the correct behavior.
Thanks, I committed a fix that checks that moveresize_client is set at the point in event.c that calls moveresize_end, since that seems to be the pattern in the rest of the code there.
When you fix something in git, please add a link. I followed the instructions from http://openbox.org/wiki/Openbox:UsingGit and had problems finding the change as the wiki page seems outdated.
Created attachment 3103 [details] workaround to prevent crash openbox has segfaulted several times when running gtk3 programs, since updating gtk3 to version 3.4. Unfortunately I haven't been able to reproduce the crash consistently, it seems related to pop-up dialogs / message boxes from gtk3 programs. I have captured a backtrace: Thread 1 (Thread 0x7ff0fed10740 (LWP 14932)): #0 0x000000000041e4e2 in client_configure (self=0x0, x=21, y=55, w=1202, h= 924, user=1, final=1, force_reply=0) at openbox/client.c:3057 #1 0x00000000004413c8 in moveresize_end (cancel=1) at openbox/moveresize.c:333 #2 0x000000000042be56 in event_handle_client (client=0x15994a0, e= 0x7fff8a1bdb60) at openbox/event.c:1491 #3 0x0000000000429b35 in event_process (ec=0x7fff8a1bdc80, data=0x0) at openbox/event.c:625 #4 0x00007ff0fcd07186 in event_read (source=0x15abf50, callback=0, data=0x0) at obt/xqueue.c:338 #5 0x00007ff0fe044d6a in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #6 0x00007ff0fe045130 in ?? () from /usr/lib64/libglib-2.0.so.0 #7 0x00007ff0fe045535 in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0 #8 0x0000000000444015 in main (argc=1, argv=0x7fff8a1be028) at openbox/openbox.c:378 It seems moveresize_end is being called but moveresize_client is a NULL pointer - I added a NULL pointer check to the start of moveresize_end to print a warning instead of crashing.Created attachment 3140 [details] Clickable areas for evince to crash