gnome-power-manager crashes on low battery

StacktraceTop:gpm_cell_array_charge_low_cb (cell_array=0x13e33f0, percent=<value optimized out>,
IA__g_closure_invoke (closure=0x15f13c0, return_value=0x0, n_param_values=2,
signal_emit_unlocked_R (node=0x15ec2d0, detail=0, instance=0x13e33f0, emission_return=0x0,
IA__g_signal_emit_valist (instance=0x13e33f0, signal_id=<value optimized out>, detail=0,
IA__g_signal_emit (instance=0x13e33f0, signal_id=4416455, detail=1159735850)

Happens on 25% battery for me (see duplicate bug 269636). This also prevents g-p-m from starting when battery is <= 25% for me.

Happens to me as well, around 10%. My battery indicator turns red around the same time, so I believe this problem is triggered by the battery's 'critical' status.

Me too, regardless of charge level.

Ubu Intrepid 8.10 on HP Pavilion dv6500

Hi,

here on latest Intrepid, GPM crashes at 25% and can't start anymore.
BUT, if I launch it manually from terminal with --verbose --no-daemon, it starts correctly and stays up (records battery related events, lid close/open, etc).

I get the same behaviour in version 2.24.0-0ubuntu3.

Also, when I run g-p-m in terminal with --no-daemon --verbose, I get the following, quite suspicious output:

 - ** EMIT: charge-low

** (gnome-power-manager:19145): CRITICAL **: gpm_cell_array_charge_low_cb: assertion `engine != NULL' failed

Some GDB backtracing tells me that the crash seems to happen on line 799 in gpm-engine.c (that is AFTER the ubuntu patches are applied). I fail to fix it with my limited C knowledge, though...

Actually, as far as I can tell, the problem exists (and on the same line of code, too) even without the ubuntu/debian patches. I couldn't get the thing to run without having the package installed (whined about gconf schemas), so my investigations may not be correct. If they are is correct, though, the problem is either in upstream or in the libraries or something like that.

(Sorry for the multiple comments, but I feel like this should be fixed before intrepid's release...)

Yesterday, I found out using live CD's that the problem only seems to exists when using amd64 architecture.

Some thorough investigation by me and a friend (with better C knowledge) has led us to the macro _G_TYPE_CIT, defined at row 1479 in gobject/gtype.h of the glib headers. The segfault seems to be caused by the pointer to __inst->g_class (__inst is defined using a cast of the GpmEngine instance to a GTypeInstance inside the macro). valgrind gives the error "invalid read of size 8" and whines about that pointer (found by entering some fprintf's in the macro). Also, that pointer (as used in the macro) is suddenly 64 bits instead of 32 bits like the rest of the pointers in that macro. My friend is still digging deep in glib's headers to get enlightenment on the issue.

The weird thing is that Hardy's version of gnome-power-manager, with seemingly identical code for the problematic(?) files, still works just fine... The Makefile's don't seem to have any strange differences either.

After some more hours of debugging we have pinpointed the problem to a (most probable) memory corruption, memory seemingly owned by glib... (Queue enthusiastic wahoo's.)

As to why or where this is happening, we haven't got a clue (yet?).

More detailed explanation:
The GpmEngine pointer (mostly named "engine" in gpm-engine.c) is, accordingly to GDB, correctly sent to g_signal_connect (from gpm_engine_init in gpm-engine.c). However, when gpm_cell_array_charge_low_cb is called from glib's event handler, the engine pointer is a different one. When running Hardy's version of g-p-m in Intrepid, this doesn't happen.

We managed to get Intrepid's version working using a very very very very /.../ very very very fugly hack... That is, we saved the pointer generated in gpm_engine_new (like everything else, in gpm-engine.c) to a global (static) variable, and then restored it inside gpm_cell_array_charge_low_cb. Ta-da, no segfault when charge-low should be emitted! (eh... wahoo?) Like I said, this is fugly, but at least we've demonstrated the problem.

Unless this is fixed before Intrepid's release, I suggest a revert to Hardy's version is made. We can't have g-p-m crashing on all amd64 laptops out there...

I can second this (gpm 2.24.0-0ubuntu3). Valgrind says:

==19505== Invalid read of size 8
==19505== at 0x40CB40: gpm_cell_array_charge_low_cb (gpm-engine.c:799)
==19505== by 0xCE2425C: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1800.1)
==19505== by 0xCE39F5C: (within /usr/lib/libgobject-2.0.so.0.1800.1)
==19505== by 0xCE3B607: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1800.1)
==19505== by 0xCE3BB32: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.1800.1)
==19505== by 0x411AA4: gpm_cell_array_collection_changed (gpm-cell-array.c:784)
==19505== by 0x411F22: gpm_cell_array_add_device_id (gpm-cell-array.c:839)
==19505== by 0x412092: gpm_cell_array_coldplug (gpm-cell-array.c:877)
==19505== by 0x41217F: gpm_cell_array_refresh (gpm-cell-array.c:943)
==19505== by 0xCE2425C: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1800.1)
==19505== by 0xCE39F5C: (within /usr/lib/libgobject-2.0.so.0.1800.1)
==19505== by 0xCE3B607: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1800.1)
==19505== Address 0x3a54494d45202a2a is not stack'd, malloc'd or (recently) free'd

ERROR: Caught a segmentation fault while loading plugin file:
/usr/lib/gstreamer-0.10/libgstaudioresample.so

^--- bingo

Not sure why gstreamer's audio resampling lib is segfaulting, yet, but disabling "use sound to notify in event of an error" prevents the gpm crash by preventing it from trying to play a sound.

I don't think gstreamer is to blame. I don't get that error, and g-p-m still segfaults for me when I disable "use sound..."

Also as said before, somewhere, the engine pointer sent to gpm_cell_array_charge_low_cb (where the segfault occurs). Strange thing is athat the pointer Mike's valgrind log complains about (0x3a54494d45202a2a) is exactly the same as the pointer it complains about when I test it...

Hi I seem to hit this bug too.

When gpm crashes (my battery was discharging), I can relaunch it with "gnome-power-manager --verbose --no-daemon", after having plugged AC in, and it seems stable (it hasn't recrashed since manual launch). At relaunch, it shows 11% battery.

just after having launched it manually, I encountered my bug https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/267109 . I killed the uid-0 daemon, and everything went fine since. I attach the complete gpm log since I launched it manually, in case someone can see something interesting in it.

This must be my problem too. I'm not sure what charge level it was but it was relatively low.

Hp tx2000z

used the above command (gnome-power-manager --verbose --no-daemon)
and it gives a 4.0% charge (which I don't think is right but it doesn't crash)
Kory

Well in defiance of my previous belief, My computer really was at 4% because my laptop turned off a minute after I posted that.
So I guess the only time the power manager crashes is when the battery is discharging and gets around 15% or so..
Kory

i also get the crash with "use sound to notify in event of an error" disabled.

I confirm the bug on an amd64 box. Hope you get it solved soon (and wahoo for the investigation above :) )

> Also as said before, somewhere, the engine pointer sent to
> gpm_cell_array_charge_low_cb (where the segfault occurs). Strange thing
> is athat the pointer Mike's valgrind log complains about
> (0x3a54494d45202a2a) is exactly the same as the pointer it complains
> about when I test it..
It is exactly the same probably because it is text:
3a :
54 T
49 I
4d M
45 E
20 space
2a *
2a *

Hope this helps.

-- Jan Evert

In a brief glance, I can't find anywhere a TIME string could be coming from - TIME as a string literal doesn't appear anywhere in the compiled binary that I can see, nor does a toupper call.

How very novel.

hi,

power manager crashed when battery about 25%

Shouldn't this bug be considered of high or even critical importance?
I mean, it apparently affects all amd64 laptop users and intrepid is due to be released next week.

This bug should be marked critical, yes.

Recompiling libglib with GCC/G++ 4.2 and then recompiling gnome-power-mangler against that yielded no change.

Nor did compiling vanilla gnome-power-mangler.

Tragic.

Hi,

I believe that I have a fix for the bug. I have someone testing the patch,
and if they show that it is good then I will organise an upload.

Thanks,

James

So sorry to say, James - bug still recurs with your patch.

Rich,

If somebody could catch the bug in the debugger then at least the full text can be found.
It does not necessarily need to come from the g-p-m binary. It could be from any of the loaded libs or even have been loaded from configuration.

But if this is text then one possible option how it got there is through a *sprintf call with a too short buffer and no return value checking.

I've triggered this bug with gdb attached a number of times. Tragically, I don't have gdb with the back-step patches installed, or this would be infinitely easier.

Will produce complete text in a moment.

Sorry boys and girls, it seems I had a bug in my installation environment (one of my attempts to build from trunk left remnants in /usr/local that I just found and cleaned out.)

Testing patch again to see whether this does, indeed, not fix it.

Patch resolves the bug.

As a sidenote, some more investigation (by my friend) has come to the conclusion that the faulty pointer doesn't mean ":TIME **", it means "** EMIT:"...

The full string is "** EMIT: charge-low" (only the first 8 bytes are used as a 64-bit 'pointer').

Hi,

Please sponsor this change in to Intrepid.

Thanks,

James

I can confirm that James' patch fixes the problem.

Taking for sponsoring.

This bug was fixed in the package gnome-power-manager - 2.24.0-0ubuntu5

---------------
gnome-power-manager (2.24.0-0ubuntu5) intrepid; urgency=low

  * debian/patches/20_fix_percentage_closures.patch: When unit->percentage
    was changed to a float for 2.24 not all the signals that deal in
    percentages had their signatures updated. Use the correct type for
    the signals that take a percentage (LP: #269083)
    - http://bugzilla.gnome.org/show_bug.cgi?id=550817

 -- James Westby <email address hidden> Mon, 13 Oct 2008 23:54:30 +0100