We're a bit too fast for usbmuxd to have noticed the USB device getting
plugged in, so defer until either the device is 1) noticed by usbmuxd
and 2) paired.
https://bugs.freedesktop.org/show_bug.cgi?id=88950
This makes it easier to find real memory leaks with valgrind. After
calling the up_backend_unplug functions, you cannot restart it with
up_backend_coldplug since the lists are cleared.
Tested with Linux only (not on *BSD; dummy compiles).
https://bugs.freedesktop.org/show_bug.cgi?id=82659
up_daemon_get_daemon takes a reference on UpDaemon, so it must be
properly dereferenced. Similar for up_daemon_get_devices_list which
references an UpDeviceList.
The display device was allocated in init, but never released either.
https://bugs.freedesktop.org/show_bug.cgi?id=82659
Whenever the daemon is polling on a device, a new signal is connected to
the object. This signal was not disconnected when polling stops which
resulted in a memory leak. Furthermore, whenever the "warning-level"
property is updated, the signal would result in an exponentially raising
call count (this happens when the battery percentage changes for
example).
https://bugs.freedesktop.org/show_bug.cgi?id=82659
Reported-by: Alexander Jesner <alexander@jesner.eu>
Signed-off-by: Peter Wu <peter@lekensteyn.nl>
up_wakeups_get_cmdline returns allocated memory and
up_wakeup_item_set_cmdline duplicates it. Therefore free the former
after setting it on the item.
https://bugs.freedesktop.org/show_bug.cgi?id=82659
Reproducible by executing `upower -d` or by calling the DBus method
org.freedesktop.UPower.Device.GetStatistics(charging).
up_device_get_statistics ->
up_history_get_profile_data ->
up_stats_item_new.
https://bugs.freedesktop.org/show_bug.cgi?id=82659
dbus_g_method_return[_error] does not claim the passed parameters, the
caller must free it theirselves.
complex is filled with an GValueArray pointer (see
UP_DBUS_STRUCT_DOUBLE_DOUBLE) but its contents are not freed (memleak!).
This patch introduces a deprecation warning due to the use
g_value_array_free, but since UP_DBUS_STRUCT_DOUBLE_DOUBLE is a
GValueArray, this is unavoidable.
https://bugs.freedesktop.org/show_bug.cgi?id=82659
Under certain conditions lockdownd_client_free was called
twice for same client. This caused SIGSEGV.
This patch addresses this issue
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
Signed-off-by: Richard Hughes <richard@hughsie.com>
Commit 5ddfe0d (all: Use g_get_real_time() when possible) replaced calls
to g_get_current_time() with g_get_real_time(), however, we also need to
convert the return value from microseconds to seconds.
Signed-off-by: Richard Hughes <richard@hughsie.com>
Cppcheck found it as a logical conjunction always evaluates to
false: EXPR < 32 && EXPR > 126. Change the expression to an Or.
https://bugs.freedesktop.org/show_bug.cgi?id=71066
Signed-off-by: Richard Hughes <richard@hughsie.com>
This is better design to catching regressions and problems in a more
pin-pointed fashion. This also avoids having to restart the umockdev testbed
due to changing the environment variables with stop/start_daemon().
up-self-test.c: In function ‘up_test_history_func’:
up-self-test.c:274:2: warning: implicit declaration of function ‘rmdir’ [-Wimplicit-function-declaration]
rmdir (history_dir);
With the removal of the suspend/hibernate code, there's no longer
a need for upower to depend on polkit. This patch removes the old
polkit code.
Signed-off-by: Richard Hughes <richard@hughsie.com>
The IsDocked property has been incorrect for a number of laptops for a
while, as it thought that laptops with hybrid graphics cards were always
docked.
The alternative would have been to use the platform/dock_station
devices, but those are only exported for ACPI docking stations.
Instead, whether an external display is attached (which isn't really
docking) should be checked in the same place where the policy depending
on the value should be applied, such as gnome-settings-daemon.
https://bugs.freedesktop.org/show_bug.cgi?id=36818
On the Lenovo A600 all-in-one, there's a HCI/HID dual-mode Broadcom
device which will try to get the battery level of the supplied
mouse and keyboard, but will usually fail to do so.
So we have a battery of type "battery" (it's not either a mouse or
a keyboard, as it's supposed to handle both) but our display device
battery code doesn't check whether those batteries are power supplies
or not, using this "empty" (0% after the check timed out) battery in
the shutdown policy.
Check better for power supply devices, not all the "battery" types
are power supply batteries, they might be non-power supply ones
from unknown device types.
In addition to build time - this increases compatibilty with OSTree,
which starts out with an empty /var.
Signed-off-by: Richard Hughes <richard@hughsie.com>
This has 2 effects:
- we never stop polling (we used to stop polling when the
battery was marked as fully-charged, but that can happen when
the battery is discharging too)
- when in an unknown state, we will poll through the daemon,
and through our unknown poll. This isn't a problem as there'll
another 115 seconds of wait until we get to poll through the
daemon again.
