Hi, since upgrade to xfpm 0.8.4 I get quite often crashes with: The program 'xfce4-power-manager' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 3811 error_code 8 request_code 131 minor_code 6) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) It might be related to GTK+ 2.18, seeing the stuff about gdk_x_error(). I don't really know how to debug more. I use xserver 1.6.99.903 if that matters.
Probably it is related to Gtk+ 2.18, but i need more details, it is crashing immediately after starting it up? or when changing the brightness level? I never encounter a crash like that on my system.
It seems that it mainly crash when suspending (or maybe when shutting down the LCD). I'll rebuild with debugging to add more info.
ok, seems related to the LID close event, so maybe it's more a problem with the X upgrade. It's not 100% reproducible, I just suspended 3 times in a row and it worked fine. I'll try to get a backtrace but I'm not sure it's possible with an X error
(In reply to comment #3) > ok, seems related to the LID close event, so maybe it's more a problem with the > X upgrade. > > It's not 100% reproducible, I just suspended 3 times in a row and it worked > fine. I'll try to get a backtrace but I'm not sure it's possible with an X > error Ok, 4th time it crashed, but not coredump.
Created attachment 2558 XSync on lid close
It is not reproducible on my system, but anyway try the attached patch.
(In reply to comment #6) > It is not reproducible on my system, but anyway try the attached patch. With patch applied, I get the following output when it crashes: TRACE[xfpm-button-hal.c:128] xfpm_button_hal_device_changed_cb(): Emitting signal lid event : pressed TRUE TRACE[xfpm-dpms.c:301] xfpm_dpms_lid_event_cb(): pressed: TRUE TRACE[xfpm-engine.c:245] xfpm_engine_lid_event(): LID close event : ((XfpmLidTriggerAction) LID_TRIGGER_SUSPEND) TRACE[xfpm-engine.c:198] xfpm_engine_shutdown_request(): Going to do Suspend TRACE[xfpm-dpms.c:237] xfpm_dpms_force_off(): Start TRACE[xfpm-dpms.c:250] xfpm_dpms_force_off(): Checking if we have multiple monitor : no TRACE[xfpm-dpms.c:251] xfpm_dpms_force_off(): Forcing DPMSModeOff The program 'xfce4-power-manager' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 505 error_code 8 request_code 131 minor_code 6) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.)
(In reply to comment #7) > (In reply to comment #6) > > It is not reproducible on my system, but anyway try the attached patch. > > With patch applied, I get the following output when it crashes: > > TRACE[xfpm-button-hal.c:128] xfpm_button_hal_device_changed_cb(): Emitting > signal lid event : pressed TRUE > TRACE[xfpm-dpms.c:301] xfpm_dpms_lid_event_cb(): pressed: TRUE > TRACE[xfpm-engine.c:245] xfpm_engine_lid_event(): LID close event : > ((XfpmLidTriggerAction) LID_TRIGGER_SUSPEND) > TRACE[xfpm-engine.c:198] xfpm_engine_shutdown_request(): Going to do Suspend > > TRACE[xfpm-dpms.c:237] xfpm_dpms_force_off(): Start > TRACE[xfpm-dpms.c:250] xfpm_dpms_force_off(): Checking if we have multiple > monitor : no > TRACE[xfpm-dpms.c:251] xfpm_dpms_force_off(): Forcing DPMSModeOff > The program 'xfce4-power-manager' received an X Window System error. > This probably reflects a bug in the program. > The error was 'BadMatch (invalid parameter attributes)'. > (Details: serial 505 error_code 8 request_code 131 minor_code 6) > (Note to programmers: normally, X errors are reported asynchronously; > that is, you will receive the error a while after causing it. > To debug your program, run it with the --sync command line > option to change this behavior. You can then get a meaningful > backtrace from your debugger if you break on the gdk_x_error() function.) Since we aren't the only one in trouble here, do you have time to try gpm i think it should crash also, because the code of switching off the lcd is the same with this patch.
Also could be very useful if you disable suspend on lid event and just try to close and open your lid device.
(In reply to comment #9) > Also could be very useful if you disable suspend on lid event and just try to > close and open your lid device. Ok, I just tried to disable suspend (using "do nothing") and close the LID. xfpm crashed, this time with: Details: 1428 error_code: 8 request_code: 131 minor_code: 6 I'll see if I can try with gpm. Cheers and thanks for the help
(In reply to comment #8) > Since we aren't the only one in trouble here, do you have time to try gpm i > think it should crash also, because the code of switching off the lcd is the > same with this patch. gpm doesn't crash when configured to “do nothing” and closing the LID.
I've downgraded xserver to 1.6.4 and xserver-xorg-video-intel to 2.9.0 and it *seems* that xfpm doesn't crash anymore (at least I couldn't reproduce for the moment) So it may very well be related to the intel DDX driver. I'll let the bug open for now, and will try from time to time the new driver and server to check if the bug's still here. I'll ask X people to if they have an idea.
> gpm doesn't crash when configured to “do nothing” and closing the LID. But if it is configured to blank the screen then it should crash, xfpm if configured to do nothing it automatically switch off the screen when the lid is closed and no external monitor is connected.
(In reply to comment #12) > I've downgraded xserver to 1.6.4 and xserver-xorg-video-intel to 2.9.0 and it > *seems* that xfpm doesn't crash anymore (at least I couldn't reproduce for the > moment) > > So it may very well be related to the intel DDX driver. I'll let the bug open > for now, and will try from time to time the new driver and server to check if > the bug's still here. I'll ask X people to if they have an idea. Thanks for you effort on this, i expected something like that, which intel device you have by the way, i have intel 945 GMA so i hope i should be able to reproduce the problem and do more debugging.
(In reply to comment #13) > > gpm doesn't crash when configured to “do nothing” and closing the LID. > > But if it is configured to blank the screen then it should crash, xfpm if > configured to do nothing it automatically switch off the screen when the lid is > closed and no external monitor is connected. Hmhm, I didn't try, so I'll upgrade X again to let you know. (In reply to comment #14) > (In reply to comment #12) > > I've downgraded xserver to 1.6.4 and xserver-xorg-video-intel to 2.9.0 and it > > *seems* that xfpm doesn't crash anymore (at least I couldn't reproduce for the > > moment) > > > > So it may very well be related to the intel DDX driver. I'll let the bug open > > for now, and will try from time to time the new driver and server to check if > > the bug's still here. I'll ask X people to if they have an idea. > > Thanks for you effort on this, i expected something like that, which intel > device you have by the way, i have intel 945 GMA so i hope i should be able to > reproduce the problem and do more debugging. Intel GMA965
Hmmh, now I've upgraded again, and I can't reproduce anymore, nor in xfpm nor in gpm. I'll let you know
(In reply to comment #16) > Hmmh, now I've upgraded again, and I can't reproduce anymore, nor in xfpm nor > in gpm. I'll let you know I managed to reproduce (I guess the monitor controls were disabled). And gpm doesn't seem to crash.
(In reply to comment #17) > I managed to reproduce (I guess the monitor controls were disabled). And gpm > doesn't seem to crash. With the lid configured to do nothing or to do suspend? Strange to me that gpm doesn't crash, xfpm and gpm have the same code for switching off the lcd on lid event.
(In reply to comment #18) > (In reply to comment #17) > > I managed to reproduce (I guess the monitor controls were disabled). And gpm > > doesn't seem to crash. > > With the lid configured to do nothing or to do suspend? “Do nothing” for xfpm “Blank screen” for gpm
(In reply to comment #19) > (In reply to comment #18) > > (In reply to comment #17) > > > I managed to reproduce (I guess the monitor controls were disabled). And gpm > > > doesn't seem to crash. > > > > With the lid configured to do nothing or to do suspend? > > “Do nothing” for xfpm > “Blank screen” for gpm Don't know from where to start but please try to give me more info from gdb breaking gdk_x_error gdb xfce4-power-manager break gdk_x_error run and then try to reproduce the problem printing the backtrace here.
Created attachment 2577 Backtrace on gdk_x_error()
Here's the backtrace. Hope it can help...
Created attachment 2615 Check if DPMS is disabled before calling DPMS functions. Please try the latest patch and see if this fixes the problem for you. I think the problem is coming from the fact that DPMS seems to be disabled when i force off, so i'm getting an X error, i saw this from the latest backtrace. >dpms = 0x665f60 > power_level = 0 > state = 0 '\0'
It seems that master is quite robust at the moment, it didn't (yet?) crash, so you might have found the problem :)
(In reply to comment #24) > It seems that master is quite robust at the moment, it didn't (yet?) crash, so > you might have found the problem :) Great to hear that, i think it is ready to a 0.8.4.1 this week-end probably, but well people are complaining about the key mapping :(.