Bug 237842

Hangs X? Wow, not cool. Does g-p-m segfault?

g-p-m doesn't segfault (I already saw bug 203289 :)

How should I launch g-p-m to know whether it receives more than one keypress?

gnome-power-manager --verbose --no-daemon

[...]
[watch_device_condition_cb] gpm-hal.c:609 (22:58:40):    emitting
device-condition : /org/freedesktop/Hal/devices/computer_logicaldev_input_2,
ButtonPressed (power)
[hal_device_condition_cb] gpm-button.c:384 (22:58:40):  
udi=/org/freedesktop/Hal/devices/computer_logicaldev_input_2,
condition=ButtonPressed, details=power
[emit_button_pressed] gpm-button.c:326 (22:58:40):       emitting button-pressed
: power
[button_pressed_cb] gpm-manager.c:790 (22:58:40):        Button press event
type=power
[gpm_inhibit_is_valid] gpm-inhibit.c:374 (22:58:40):     Valid as no manual
inhibitors
[power_button_pressed] gpm-manager.c:701 (22:58:40):     power button pressed
[manager_policy_do] gpm-manager.c:350 (22:58:40):        policy:
/apps/gnome-power-manager/action_button_power
Saving to syslog: GNOME interactive logout because the power button has been
pressed[gpm_info_event_log] gpm-info.c:361 (22:58:40):      Adding 9 to the
event log
[button_pressed_cb] gpm-srv-screensaver.c:173 (22:58:40):        Button press
event type=power
[button_pressed_cb] gpm-srv-backlight.c:410 (22:58:40):  Button press event
type=power
[button_pressed_cb] gpm-info.c:459 (22:58:40):   Button press event type=power

That's all I get. The backtrace looks very suspicious though:
#0  0x0050c402 in __kernel_vsyscall ()
#1  0x008864fb in poll () from /lib/libc.so.6
#2  0x009a1a99 in ?? () from /usr/lib/libX11.so.6
#3  0x009a1e7f in _XRead () from /usr/lib/libX11.so.6
#4  0x009a2844 in _XReply () from /usr/lib/libX11.so.6
#5  0x00a8a8c3 in DPMSInfo () from /usr/lib/libXext.so.6
#6  0x08050b1d in ?? ()
#7  0x08051cc1 in ?? ()
#8  0x00b74bf6 in ?? () from /lib/libglib-2.0.so.0
#9  0x00b74622 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#10 0x00b775ff in ?? () from /lib/libglib-2.0.so.0
#11 0x00b779a9 in g_main_loop_run () from /lib/libglib-2.0.so.0
#12 0x0805fba6 in main ()

Better backtrace:
#0  0x0050c402 in __kernel_vsyscall ()
#1  0x008864fb in poll () from /lib/libc.so.6
#2  0x009a1a99 in _XWaitForReadable (dpy=0x82887d8) at XlibInt.c:498
#3  0x009a1e7f in _XRead (dpy=0x82887d8, data=0xbfb28ffc "s�K", size=32) at
XlibInt.c:1087
#4  0x009a2844 in _XReply (dpy=0x82887d8, rep=0xbfb28ffc, extra=0, discard=1) at
XlibInt.c:1714
#5  0x00a8a8c3 in DPMSInfo (dpy=0x82887d8, power_level=0xbfb29050,
state=0xbfb29053 "") at DPMS.c:280
#6  0x08050b1d in ?? ()
#7  0x08051cc1 in ?? ()
#8  0x00b74bf6 in ?? () from /lib/libglib-2.0.so.0
#9  0x00b74622 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#10 0x00b775ff in ?? () from /lib/libglib-2.0.so.0
#11 0x00b779a9 in g_main_loop_run () from /lib/libglib-2.0.so.0
#12 0x0805fba6 in main ()

Is there a way to disable the DPMS setting?

You could try changing the gconf method to be "nothing" which might work, also
you could ./configure --without-dpms-ext (not tested).

Out of interest, does the same system hang using xset dpms force on?

(In reply to comment #6)
> You could try changing the gconf method to be "nothing" which might work, also

I changed /apps/gnome-power-manager/action_button_power to "nothing", and it
didn't hang anymore. Or did you mean something else.

> you could ./configure --without-dpms-ext (not tested).

Not tested either.

> Out of interest, does the same system hang using xset dpms force on?

Works fine when run by hand.

I wonder if this has to do with the changes Adam made:
gnome-power-manager-2.17.92-dpms-query-less.patch

Much better g-p-m backtrace:
#0  0x00531402 in __kernel_vsyscall ()
#1  0x008864fb in *__GI___poll (fds=0x90fff4, nfds=1, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:83
#2  0x009a1a99 in _XWaitForReadable (dpy=0x8909750) at XlibInt.c:498
#3  0x009a1e7f in _XRead (dpy=0x8909750, data=0xbfee8dec "s�p", size=32) at
XlibInt.c:1087
#4  0x009a2844 in _XReply (dpy=0x8909750, rep=0xbfee8dec, extra=0, discard=1) at
XlibInt.c:1714
#5  0x00a8a8c3 in DPMSInfo (dpy=0x8909750, power_level=0xbfee8e40,
state=0xbfee8e43 "") at DPMS.c:280
#6  0x08050b1d in x11_get_mode (dpms=<value optimized out>, mode=0xbfee8e6c,
error=0x1) at gpm-dpms.c:233
#7  0x08051cc1 in poll_dpms_mode (dpms=0x8932b60) at gpm-dpms.c:759
#8  0x00b74bf6 in ?? () from /lib/libglib-2.0.so.0
#9  0x00b74622 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#10 0x00b775ff in ?? () from /lib/libglib-2.0.so.0
#11 0x00b779a9 in g_main_loop_run () from /lib/libglib-2.0.so.0
#12 0x0805fba6 in main (argc=1, argv=Cannot access memory at address 0x5

The Xorg backtrace is pretty useless...
Thread 1 (Thread -1208146208 (LWP 2934)):
#0  0x00bdd402 in __kernel_vsyscall ()
#1  0x00888f9d in ___newselect_nocancel () from /lib/libc.so.6
#2  0x081b4593 in WaitForSomething (pClientsReady=0xbfdbf710) at WaitFor.c:238
#3  0x080891ed in Dispatch () at dispatch.c:383
#4  0x08071045 in main (argc=10, argv=0xbfdbfc34, envp=0x0) at main.c:445
#0  0x00bdd402 in __kernel_vsyscall ()

And same problem with Adam's patch backed-off.

I believe that's also what's causing my laptop not to come back from suspend
after I've closed the lid.

I'll need to test with a different driver, I guess, as it seems to work for
everyone else.

Still the same problem with the i810 driver. I'm running out of ideas here.
Adam, any hints on what I should look for?

I ran g-p-m under valgrind, didn't get the log out dialog the first time I
pressed the power button, and X stayed alive. The second time I pressed it, X
fell over without a warning. I think that the dpms bits in libXext are probably
missing some sanity checking and/or g-p-m is pushing garbage to the DPMS library.

To summarise so far:
- g-p-m is hung, killing it won't do anything
- the display isn't updating, but the cursor still moves with the mouse
- killing Xorg won't restart it (and leave the machine unusable)
- network still works (that's how I got the backtraces)
- can't switch to a virtual console
- couldn't find anything interesting in the output of Alt+SysRq+T (launched via
/proc/sysrq-trigger)
- happens with i810 and intel drivers
- "xset dpms force on/off" works properly
- no errors when g-p-m is run under valgrind

I updated to the latest available BIOS for this machine (A04, it contained some
"Update Intel 945GMS VBIOS."), as well as the latest gnome-power-manager
(2.18.2), to no avail.

"xdpyinfo -display :0" launched from a network console hangs as well.
"chvt 1" will change the VT in use, Ctrl+Alt+F1 doesn't work (as mentioned above).

Looks like this is a X display driver bug, yes? Reassigning then...

Still the same problem with xorg-x11-drv-i810-devel-2.0.0-2.fc7

Huh, make that xorg-x11-drv-i810-2.0.0-2.fc7

I tested this with Richard today, and gnome-power-manager-2.18.3 "fixes" it
(probably because it doesn't poll the DPMS as often).

Could we update it before the release?

Well, bugger.

The problem isn't gnome-power-manager at all, or X.org, the DPMS hang was just a
red herring. The problem is that gnome-session doesn't show any dialogue, and
"hangs" in:

#0  0x00c12402 in __kernel_vsyscall ()
#1  0x00ec4d53 in *__GI___poll (fds=0xf4eff4, nfds=12, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:87
#2  0x005a8633 in g_main_context_iterate (context=0x9ec4648, block=1,
dispatch=1, self=0x9ec5dc0) at gmain.c:2979
#3  0x005a89a9 in IA__g_main_loop_run (loop=0xa11cd40) at gmain.c:2881
#4  0x001aec2b in gtk_dialog_run () from /usr/lib/libgtk-x11-2.0.so.0
#5  0x0805890e in maybe_display_gui () at logout.c:508
#6  0x08051ec0 in process_save_request (client=0x9ee9770, save_type=0,
shutdown=1, interact_style=2, fast=0, global=1) at manager.c:1199
#7  0x080520fe in save_yourself_request (connection=0x9ee9848, data=0x9ee9770,
save_type=0, shutdown=1, interact_style=2, fast=0, global=1) at manager.c:1300
#8  0x0055192c in _SmsProcessMessage () from /usr/lib/libSM.so.6
#9  0x00540f01 in IceProcessMessages () from /usr/lib/libICE.so.6
#10 0x04c01735 in ?? () from /usr/lib/libgnomeui-2.so.0
#11 0x005ced8d in g_io_unix_dispatch (source=0x9eea468, callback=0x4c01700,
user_data=0x9ee9b88) at giounix.c:162
#12 0x005a5622 in IA__g_main_context_dispatch (context=0x9ec4648) at gmain.c:2045
#13 0x005a85ff in g_main_context_iterate (context=0x9ec4648, block=1,
dispatch=1, self=0x9ec5dc0) at gmain.c:2677
#14 0x005a89a9 in IA__g_main_loop_run (loop=0x9ee1698) at gmain.c:2881
#15 0x0022e6a4 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0

But I don't see any logout dialogue. Using metacity works fine.

compiz-0.3.6-8.fc7
gnome-session-2.18.0-5.fc7

Reproducer:
1. Get in the session
2. Make sure compiz/gtk-window-decorator is running (in Desktop Effects)
3. Press the power button, or run by hand:
gnome-session-save --kill

Here's a backtrace of compiz hanging:
#0  0x00dd4402 in __kernel_vsyscall ()
#1  0x00a36d1b in *__GI___poll (fds=0xac0ff4, nfds=1, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:83
#2  0x0014fa99 in _XWaitForReadable (dpy=0x88fdc50) at XlibInt.c:498
#3  0x0014fe7f in _XRead (dpy=0x88fdc50, data=0xbf8f69f4 "� �f[\004`", size=32)
at XlibInt.c:1087
#4  0x00150844 in _XReply (dpy=0x88fdc50, rep=0xbf8f69f4, extra=0, discard=1) at
XlibInt.c:1714
#5  0x0013231c in _XGetWindowAttributes (dpy=0x88fdc50, w=6292504,
attr=0x8963320) at GetWAttrs.c:116
#6  0x00132472 in XGetWindowAttributes (dpy=0x88fdc50, w=6292504,
attr=0x8963320) at GetWAttrs.c:151
#7  0x08062e72 in addWindow (screen=0x8906f10, id=6292504, aboveId=6292479) at
window.c:1770
#8  0x08064d85 in handleEvent (d=0x80727e0, event=0xbf8f75f8) at event.c:1233
#9  0x00293e15 in decorHandleEvent (d=0x80727e0, event=0xbf8f75f8) at
decoration.c:1068
#10 0x002b9a68 in fadeHandleEvent (d=0x80727e0, event=0xbf8f75f8) at fade.c:583
#11 0x002be49a in minHandleEvent (d=0x80727e0, event=0xbf8f75f8) at minimize.c:776
#12 0x0047df09 in rotateHandleEvent (d=0x80727e0, event=0xbf8f75f8) at rotate.c:1577
#13 0x00e21eff in zoomHandleEvent (d=0x80727e0, event=0xbf8f75f8) at zoom.c:658
#14 0x0032905b in moveHandleEvent (d=0x80727e0, event=0xbf8f75f8) at move.c:620
#15 0x00482acb in resizeHandleEvent (d=0x80727e0, event=0xbf8f75f8) at resize.c:671
#16 0x00489df7 in switchHandleEvent (d=0x80727e0, event=0xbf8f75f8) at
switcher.c:1277
#17 0x08051cc1 in eventLoop () at display.c:1965
#18 0x0804eb25 in main (argc=3, argv=0xbf8f7b44) at main.c:242

As per Ray's advice, enabling a11y works-around the problem, as it doesn't draw
the iris, thus doesn't grab the server.

Reassigning to Ray, the F7 fix is to disable the server grab if the screen is
composited.

tagged for f7.