! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
memory leaks & corruption
Status:
RESOLVED: FIXED
Product:
Xfce4-power-manager
Component:
General

Comments

Description Konstantin Svist 2009-09-13 01:26:55 CEST
It all started with a simple problem: I set the setting to dim the screen to 10s while on AC power and didn't see the screen dim.
After some tracing, I saw this in src/xfpm-brightness-hal.c, lines 387-410:

* after calling xfpm_brightness_get_user_timeouts, on_battery retrieves the value properly -- but on_ac returns 0 all the time.
* adding a new variable into the definition (line 388: guint16 on_ac, on_battery;) and using it instead of on_ac fixes the problem
* reordering the variable definitions as "guint16 on_battery, on_ac;" also fixes the problem

I don't have much experience with C, but I suspect some messy business is going on with memory misalignment or stack overflows.
I've compiled PM with -g3 -O0 and ran it with valgrind. Here's some output:

<pre>
==1777== 168 (64 direct, 104 indirect) bytes in 2 blocks are definitely lost in loss record 100 of 215
==1777==    at 0x4006F3D: malloc (vg_replace_malloc.c:207)
==1777==    by 0x767E06: XSyncListSystemCounters (in /usr/lib/libXext.so.6.4.0)
==1777==    by 0x805CC78: xfpm_idle_init (xfpm-idle.c:266)
==1777==    by 0x799C6E: g_type_create_instance (in /lib/libgobject-2.0.so.0.2000.4)
==1777==    by 0x77E9F7: (within /lib/libgobject-2.0.so.0.2000.4)
==1777==    by 0x77FBDB: g_object_newv (in /lib/libgobject-2.0.so.0.2000.4)
==1777==    by 0x7807D9: g_object_new_valist (in /lib/libgobject-2.0.so.0.2000.4)
==1777==    by 0x78095D: g_object_new (in /lib/libgobject-2.0.so.0.2000.4)
==1777==    by 0x805CE61: xfpm_idle_new (xfpm-idle.c:321)
==1777==    by 0x804FC18: xfpm_engine_init (xfpm-engine.c:572)
==1777==    by 0x799C6E: g_type_create_instance (in /lib/libgobject-2.0.so.0.2000.4)
==1777==    by 0x77E9F7: (within /lib/libgobject-2.0.so.0.2000.4)
</pre>

This one is caused by not freeing the array returned by XSyncListSystemCounters (xfpm-idle.c:266). The doc is pretty clear on that :)
To fix, just insert "XSyncFreeSystemCounterList(counters);" in line 273


Unfortunately it doesn't fix my problem.. but I'll continue looking for a little while.
Comment 1 Ali Abdallah editbugs 2009-09-28 13:11:44 CEST
Sorry for the late reply, i was on vacation.

Changing the variable declaration from guint16 to guint fixes the problem also, i dunno why, but anyway i have to include this fix for the next release which is coming soon.
Comment 2 Konstantin Svist 2009-09-30 20:36:09 CEST
Don't forget XSyncFreeSystemCounterList :)
Comment 3 Ali Abdallah editbugs 2009-10-01 06:49:25 CEST
(In reply to comment #2)
> Don't forget XSyncFreeSystemCounterList :)

I had this before in the code, but i remove the free stuff since it was causing a crash, i will retest it.
Comment 4 Konstantin Svist 2009-10-06 02:34:33 CEST
(In reply to comment #3)

What were the conditions of crash? Think I could replicate it?
Comment 5 Ali Abdallah editbugs 2009-10-06 07:28:51 CEST
(In reply to comment #4)
> (In reply to comment #3)
> 
> What were the conditions of crash? Think I could replicate it?

Seems that i'm not able to reproduce the problem that i had anymore, XSyncFreeSystemCounterList(counters); call added to git.

Thanks.
Comment 6 Konstantin Svist 2009-10-07 21:24:42 CEST
Looks like original bug is now gone, even if I restore the code in xfpm-engine.c to the "buggy" one.
I'll investigate it some more with rev 0458addb7891e79112e21bf0d09f97c627c63265, because I don't like ghost-in-the-machine bugs (implication here is that the bug just shifted elsewhere)
I'll post again if I find something.
Comment 7 Konstantin Svist 2010-07-09 07:25:02 CEST
Recent version (0.8.5) doesn't seem to have any of these problems, I think this bug can be closed.

Bug #5759

Reported by:
Konstantin Svist
Reported on: 2009-09-13
Last modified on: 2011-09-09

People

Assignee:
Ali Abdallah
CC List:
0 users

Version

Version:
0.8.3.1

Attachments

Additional information