It's required for the g_autoptr() support we use. For older
distributions shipping older versions of polkit, it is recommended that
you backport the g_autoptr() support to your version of polkit and
amend the required version in this project.
The HoldProfile method was correctly throwing an error back to the
caller but was still carrying on to hold a profile.
This could cause a double-free in the daemon, and unwanted profile
changes for users.
** (power-profiles-daemon:55299): DEBUG: 10:48:10.411: (:1.0) requesting to hold profile 'performance', reason: ''
** (power-profiles-daemon:55299): DEBUG: 10:48:10.422: Setting active profile 'performance' for reason 'program-hold' (current: 'balanced')
==55299== Invalid read of size 8
==55299== at 0x4AA40F9: g_type_check_instance_is_fundamentally_a (gtype.c:4088)
==55299== by 0x4A8DA08: g_object_unref (gobject.c:3484)
==55299== by 0x4B17702: UnknownInlinedFun (gmain.c:1666)
==55299== by 0x4B17702: g_source_callback_unref (gmain.c:1659)
==55299== by 0x4B1B8BB: g_source_destroy_internal (gmain.c:1331)
==55299== by 0x4B1D47F: UnknownInlinedFun (gmain.c:3411)
==55299== by 0x4B1D47F: g_main_context_dispatch (gmain.c:4099)
==55299== by 0x4B72287: g_main_context_iterate.constprop.0 (gmain.c:4175)
==55299== by 0x4B1C902: g_main_loop_run (gmain.c:4373)
==55299== by 0x403C10: main (power-profiles-daemon.c:1006)
==55299== Address 0x54edc60 is 0 bytes inside a block of size 104 free'd
==55299== at 0x48430E4: free (vg_replace_malloc.c:872)
==55299== by 0x4B220BC: g_free (gmem.c:199)
==55299== by 0x4B3C6FF: g_slice_free1 (gslice.c:1183)
==55299== by 0x4AA2EF4: g_type_free_instance (gtype.c:2008)
==55299== by 0x49B4840: g_dbus_method_invocation_return_value_internal (gdbusmethodinvocation.c:528)
==55299== by 0x4064F2: hold_profile (power-profiles-daemon.c:568)
==55299== by 0x4064F2: handle_method_call (power-profiles-daemon.c:711)
==55299== by 0x49A4451: call_in_idle_cb.lto_priv.0 (gdbusconnection.c:4916)
==55299== by 0x4B1952A: g_idle_dispatch (gmain.c:5897)
==55299== by 0x4B1D33E: UnknownInlinedFun (gmain.c:3381)
==55299== by 0x4B1D33E: g_main_context_dispatch (gmain.c:4099)
==55299== by 0x4B72287: g_main_context_iterate.constprop.0 (gmain.c:4175)
==55299== by 0x4B1C902: g_main_loop_run (gmain.c:4373)
==55299== by 0x403C10: main (power-profiles-daemon.c:1006)
==55299== Block was alloc'd at
==55299== at 0x484086F: malloc (vg_replace_malloc.c:381)
==55299== by 0x4B257A8: g_malloc (gmem.c:106)
==55299== by 0x4B3D1E4: g_slice_alloc (gslice.c:1072)
==55299== by 0x4B3D84D: g_slice_alloc0 (gslice.c:1098)
==55299== by 0x4AA81F4: g_type_create_instance (gtype.c:1911)
==55299== by 0x4A8FCAC: g_object_new_internal (gobject.c:1945)
==55299== by 0x4A90C7C: g_object_new_with_properties (gobject.c:2114)
==55299== by 0x4A91780: g_object_new (gobject.c:1785)
==55299== by 0x49D8033: UnknownInlinedFun (gdbusmethodinvocation.c:369)
==55299== by 0x49D8033: schedule_method_call.constprop.0 (gdbusconnection.c:4946)
==55299== by 0x49A45B9: validate_and_maybe_schedule_method_call.lto_priv.0 (gdbusconnection.c:5048)
==55299== by 0x499C57A: UnknownInlinedFun (gdbusconnection.c:5091)
==55299== by 0x499C57A: UnknownInlinedFun (gdbusconnection.c:7172)
==55299== by 0x499C57A: UnknownInlinedFun (gdbusconnection.c:2344)
==55299== by 0x499C57A: on_worker_message_received (gdbusconnection.c:2258)
==55299== by 0x49B0082: UnknownInlinedFun (gdbusprivate.c:488)
==55299== by 0x49B0082: UnknownInlinedFun (gdbusprivate.c:484)
==55299== by 0x49B0082: UnknownInlinedFun (gdbusprivate.c:516)
==55299== by 0x49B0082: _g_dbus_worker_do_read_cb (gdbusprivate.c:801)
==55299==
(power-profiles-daemon:55299): GLib-GObject-CRITICAL **: 10:48:10.427: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
As power-profiles-daemon keeps getting built with slightly different
versions of pylint with newer warnings, disable pylint test by default
to avoid getting bug reports about it.
Closes: #52
If we are to run all the tests in parallel, we need to make sure that
each instance of the daemon gets its own configuration file, otherwise
all of them will be trying to change each other's config behind their
backs.
The drivers have needed to handle all the profiles they support since
c7fb31632b where we stopped using a
placeholder driver when a profile wasn't handled.
Remove restoring the problem from the on-disk kernel file, as was done
for the platform_profile, as we want to implement actual persistence
across reboots.
We need to be the ones saving that data, as the kernel doesn't know
whether the profile changes are temporary, or permanent, and whether the
user was the one initiating that change.
Make it possible for programmes to temporarily change the current
power profile, and "hold" that profile while they're performing a
task or waiting for an event to clear. This would be useful for:
- programmes with a finite workload to finish faster by investing more
energy resources (eg. compiling software or transcoding media)
- programmes with near constantly high workloads to avoid the costs of
transitioning between hardware profiles and causing stutters such
as games or 3D modelling programmes
- OS components to force power-saver mode while battery energy is
at a premium
Closes: #11
Co-Authored-By: Bastien Nocera <hadess@hadess.net>
The PerformanceInhibited property was there to convey that the
performance profile was unavailable, and that the daemon should switch
to a lower profile to avoid using the performance profile.
But it was difficult to communicate whether the daemon should switch
back to the performance profile when the inhibition disappeared, or
whether it should keep the same profile (the latter was what was
implemented).
There was also the problem that depending on the backend, the
performance profile might be able to provide a behaviour that wouldn't
match either of the unhampered performance profile, or the balanced
profile, but somewhere in between.
The PerformanceInhibited property is kept for compatibility reasons with
the existing consumer, GNOME 40. It will be removed in the future and
should not be relied on.
Closes: #24
If the kernel is built with platform_profile support,
g_file_get_contents() will fail, and we'll likely crash trying to
access ->message in the struct.
Don't forget to pass the error to g_file_get_contents().
