Created attachment 994813 [details]
File: backtrace

Created attachment 994814 [details]
File: cgroup

Created attachment 994815 [details]
File: core_backtrace

Created attachment 994816 [details]
File: dso_list

Created attachment 994817 [details]
File: environ

Created attachment 994818 [details]
File: exploitable

Created attachment 994819 [details]
File: limits

Created attachment 994820 [details]
File: maps

Created attachment 994821 [details]
File: open_fds

Created attachment 994822 [details]
File: proc_pid_status

Created attachment 994823 [details]
File: var_log_messages

Sorry, i can't reproduce it because my mouse dongle isn't show in mate-power-statistics.
But i've linked your report to another upstream report which looks similar to me.
https://github.com/mate-desktop/mate-power-manager/issues/129

Please can you test this fixed upower scratch build?
http://koji.fedoraproject.org/koji/taskinfo?taskID=9132203

No, it crashes much the same way. Here's the top of the backtrace from gdb:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff725b7d6 in up_device_get_object_path (device=0x7ea8f0) at up-device.c:179
179             g_return_val_if_fail (UP_IS_DEVICE (device), NULL);
(gdb) bt
#0  0x00007ffff725b7d6 in up_device_get_object_path (device=0x7ea8f0) at up-device.c:179
#1  0x0000000000406747 in gpm_stats_device_removed_cb ()

It seems like the same issue persists. Moreover, it now crashes if I click on the "Mouse battery" entry - when the dongle is in place. This worked before, but now it aborts with:

Program received signal SIGABRT, Aborted.
0x00007ffff3c038c7 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
55        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
#0  0x00007ffff3c038c7 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
#1  0x00007ffff3c0552a in __GI_abort () at abort.c:89
#2  0x00007ffff451f9b5 in g_assertion_message (domain=domain@entry=0x0, file=file@entry=0x40f30c "gpm-upower.c", line=line@entry=656, func=func@entry=0x40fa20 "gpm_device_state_to_localised_string", message=message@entry=0x7d4770 "code should not be reached") at gtestutils.c:2291
#3  0x00007ffff451fa4a in g_assertion_message_expr (domain=0x0, file=0x40f30c "gpm-upower.c", line=656, func=0x40fa20 "gpm_device_state_to_localised_string", expr=<optimized out>) at gtestutils.c:2306
#4  0x000000000040dc19 in  ()
#5  0x0000000000407b4b in gpm_stats_update_info_page_details ()
#6  0x0000000000407fa5 in gpm_stats_update_info_data_page ()

How can I build these packages myself? I might be able to fix the issue and submit a patch.

(In reply to skalaren_alpinist from comment #15)
> How can I build these packages myself? I might be able to fix the issue and
> submit a patch.

Thank you, this is simple.
1. install rpm-build
2. download latest m-p-m srpm from koji https://kojipkgs.fedoraproject.org//packages/mate-power-manager/1.8.1/2.fc21/src/mate-power-manager-1.8.1-2.fc21.src.rpm
3. rpm -ivh mate-power-manager-1.8.1-2.fc21.src.rpm
Now you will find all needed files in /home/user/rpmbuild
4. Edit the spec file and add a '+' after the line '%patch0 -p1 -b .dbus'
This will break/stop the build at that point!
5. Do rpmbuild -ba mate-power-manger.spec
6. After the build is stopped with the '+' you'll find an extract folder under /home/user/rpmbuild/BUILD.
This folder you can use to create a patch.
7. Add the patch to spec file and /home/user/rpmbuild/SOURCES
8. remove the '+' from spec file and start the build again.

This is the way how i create patches.

PS: Can you provide a stacktrace with 'thread apply all bt full' please?
see http://fedoraproject.org/wiki/StackTraces#gdb

Your trace shows the crash in https://github.com/mate-desktop/mate-power-manager/blob/master/src/gpm-upower.c#L621
That means the "state" argument contains some unknown value.
we don't handle the first enum value, UNKNOWN: http://cgit.freedesktop.org/upower/tree/libupower-glib/up-types.h#n54
This sratch build has a patch to fix that.
Can you please try http://koji.fedoraproject.org/koji/taskinfo?taskID=9136883  ?

^^^^

Another user experienced a similar problem:

Removin battery while running.

reporter:       libreport-2.3.0
backtrace_rating: 4
cmdline:        /usr/bin/mate-power-statistics --device /org/freedesktop/UPower/devices/battery_BAT0
crash_function: up_device_get_object_path
executable:     /usr/bin/mate-power-statistics
kernel:         3.18.7-200.fc21.i686+PAE
package:        mate-power-manager-1.8.1-2.fc21
reason:         mate-power-statistics killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            1000

Created attachment 997992 [details]
File: backtrace

Can you please test both linked scratch builds (upower + matepower-manager) ?
comment 13 and 17

(In reply to Wolfgang Ulbrich from comment #17)
> Your trace shows the crash in
> https://github.com/mate-desktop/mate-power-manager/blob/master/src/gpm-
> upower.c#L621
> That means the "state" argument contains some unknown value.
> we don't handle the first enum value, UNKNOWN:
> http://cgit.freedesktop.org/upower/tree/libupower-glib/up-types.h#n54
> This sratch build has a patch to fix that.
> Can you please try
> http://koji.fedoraproject.org/koji/taskinfo?taskID=9136883  ?

No, the crash persists. I'll attach a full backtrace, as instructed.

Created attachment 999016 [details]
Full backtrace of the crash with mate-power-manager-1.8.1-3 and upower-0.99.2-2

Can you check if upower itself can monitor you mouse?
upower --monitor-detail
Here you see why upower scratch build is needed.
https://bugzilla.redhat.com/show_bug.cgi?id=1128390

Uptream ask you to try your device with a PC if you got one, to be shure that the issue isn't caused by to have 2 batterys (Laptop + mouse).
Sorry, it's a bit hard to debug a issue if anyone has a wireless mouse with battery statisits support.

...next round of testing.
Upstream has fixed a missing port to upower-0.99.
http://koji.fedoraproject.org/koji/taskinfo?taskID=9191968
Please test it together with upower-0.99.2-2.

Tested with the requested versions:

# rpm -qa | egrep 'upower|mate-power-manager'
mate-power-manager-debuginfo-1.8.1-4.fc21.x86_64
upower-0.99.2-2.fc21.x86_64
upower-debuginfo-0.99.2-2.fc21.x86_64
upower-devel-0.99.2-2.fc21.x86_64
mate-power-manager-1.8.1-4.fc21.x86_64

The problem persists, the same crash as before.

upower alone monitors the mouse dongle disconnect:

[vesko@tank ~]$ upower --monitor-detail
Monitoring activity from the power daemon. Press Ctrl+C to cancel.
[13:12:03.027]  device removed:   /org/freedesktop/UPower/devices/mouse_0003o046DoC52Fx0008

... snip
this is followed by 12 (!) messages about "device changed" about the laptop battery: /org/freedesktop/UPower/devices/battery_BAT0

All messages come within 8 milliseconds.

Reconnecting the dongle is also noted:

[13:18:06.479]  device added:     /org/freedesktop/UPower/devices/mouse_0003o046DoC52Fx000A
  native-path:          /sys/devices/pci0000:00/0000:00:14.0/usb1/1-6/1-6:1.1/0003:046D:C52F.000A
  vendor:               Logitech, Inc.
  model:                M315/M235
  serial:               F0C2F2D8
  power supply:         no
  updated:              Fri 13 Mar 2015 01:18:06 PM EET (0 seconds ago)
  has history:          yes
  has statistics:       no
  mouse
    present:             no
    rechargeable:        yes
    state:               unknown
    warning-level:       none
    percentage:          0%
    icon-name:          'battery-missing-symbolic'
  History (charge):
    1426245486  0.000   unknown
  History (rate):
    1426245486  0.000   unknown

(In reply to Wolfgang Ulbrich from comment #25)
> Uptream ask you to try your device with a PC if you got one, to be shure
> that the issue isn't caused by to have 2 batterys (Laptop + mouse).
> Sorry, it's a bit hard to debug a issue if anyone has a wireless mouse with
> battery statisits support.

I don't have a stand-alone PC with Fedora 21. To test your idea, here's what I did. I disconnected my laptop battery (the laptop is plugged to AC power), now mate-power-statistics DOESN'T crash. It shows the mouse battery entry in the list. When you remove the dongle, it disappears from the list, when you reconnect it, it reappears. All works as expected, so your insight is probably correct.

A possibly unrelated problem is that mate-power-statistics no longer shows the correct info about the mouse battery. It used to be show it at 90% charge, now it lists "unknown state" and "Percentage" is 0%.

Just after posting the previous comment, another crash in mate-power-statistics with the same setup (just mouse, laptop battery removed).

To inspect further, I ran in through valgrind:

[vesko@tank ~]$ valgrind mate-power-statistics
==3809== Memcheck, a memory error detector
==3809== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==3809== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==3809== Command: mate-power-statistics
==3809== 
==3809== Invalid read of size 4
==3809==    at 0x4067A0: gpm_stats_device_removed_cb (gpm-statistics.c:1275)
==3809==    by 0x7D9D9AF: g_cclosure_marshal_VOID__STRINGv (gmarshal.c:1004)
==3809==    by 0x7D9AF63: _g_closure_invoke_va (gclosure.c:831)
==3809==    by 0x7DB4B5F: g_signal_emit_valist (gsignal.c:3218)
==3809==    by 0x7DB53AE: g_signal_emit (gsignal.c:3365)
==3809==    by 0xB6C2DAF: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2)
==3809==    by 0xB6C2817: ffi_call (in /usr/lib64/libffi.so.6.0.2)
==3809==    by 0x7D9B553: g_cclosure_marshal_generic (gclosure.c:1448)
==3809==    by 0x7D9AD34: g_closure_invoke (gclosure.c:768)
==3809==    by 0x7DACA41: signal_emit_unlocked_R (gsignal.c:3553)
==3809==    by 0x7DB4200: g_signal_emitv (gsignal.c:3048)
==3809==    by 0x57AE28B: up_client_glue_proxy_g_signal (up-client-glue.c:1326)
==3809==  Address 0x19827d18 is 8 bytes inside a block of size 32 free'd
==3809==    at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3809==    by 0x84767FE: g_free (gmem.c:190)
==3809==    by 0x848DC43: g_slice_free1 (gslice.c:1112)
==3809==    by 0x84458A4: ptr_array_free (garray.c:1103)
==3809==    by 0x4062CE: main (gpm-statistics.c:1877)
==3809== 
==3809== Invalid read of size 8
==3809==    at 0x4067C2: gpm_stats_device_removed_cb (gpm-statistics.c:1276)
==3809==    by 0x7D9D9AF: g_cclosure_marshal_VOID__STRINGv (gmarshal.c:1004)
==3809==    by 0x7D9AF63: _g_closure_invoke_va (gclosure.c:831)
==3809==    by 0x7DB4B5F: g_signal_emit_valist (gsignal.c:3218)
==3809==    by 0x7DB53AE: g_signal_emit (gsignal.c:3365)
==3809==    by 0xB6C2DAF: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2)
==3809==    by 0xB6C2817: ffi_call (in /usr/lib64/libffi.so.6.0.2)
==3809==    by 0x7D9B553: g_cclosure_marshal_generic (gclosure.c:1448)
==3809==    by 0x7D9AD34: g_closure_invoke (gclosure.c:768)
==3809==    by 0x7DACA41: signal_emit_unlocked_R (gsignal.c:3553)
==3809==    by 0x7DB4200: g_signal_emitv (gsignal.c:3048)
==3809==    by 0x57AE28B: up_client_glue_proxy_g_signal (up-client-glue.c:1326)
==3809==  Address 0x19827d10 is 0 bytes inside a block of size 32 free'd
==3809==    at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)                                                                                                                                                     
==3809==    by 0x84767FE: g_free (gmem.c:190)                                                                                                                                                                                                 
==3809==    by 0x848DC43: g_slice_free1 (gslice.c:1112)                                                                                                                                                                                       
==3809==    by 0x84458A4: ptr_array_free (garray.c:1103)                                                                                                                                                                                      
==3809==    by 0x4062CE: main (gpm-statistics.c:1877)                                                                                                                                                                                         
==3809==                                                                                                                                                                                                                                      
==3809== Invalid read of size 8                                                                                                                                                                                                               
==3809==    at 0x4067C8: gpm_stats_device_removed_cb (gpm-statistics.c:1277)                                                                                                                                                                  
==3809==    by 0x7D9D9AF: g_cclosure_marshal_VOID__STRINGv (gmarshal.c:1004)                                                                                                                                                                  
==3809==    by 0x7D9AF63: _g_closure_invoke_va (gclosure.c:831)                                                                                                                                                                               
==3809==    by 0x7DB4B5F: g_signal_emit_valist (gsignal.c:3218)                                                                                                                                                                               
==3809==    by 0x7DB53AE: g_signal_emit (gsignal.c:3365)                                                                                                                                                                                      
==3809==    by 0xB6C2DAF: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2)                                                                                                                                                                     
==3809==    by 0xB6C2817: ffi_call (in /usr/lib64/libffi.so.6.0.2)                                                                                                                                                                            
==3809==    by 0x7D9B553: g_cclosure_marshal_generic (gclosure.c:1448)                                                                                                                                                                        
==3809==    by 0x7D9AD34: g_closure_invoke (gclosure.c:768)                                                                                                                                                                                   
==3809==    by 0x7DACA41: signal_emit_unlocked_R (gsignal.c:3553)                                                                                                                                                                             
==3809==    by 0x7DB4200: g_signal_emitv (gsignal.c:3048)                                                                                                                                                                                     
==3809==    by 0x57AE28B: up_client_glue_proxy_g_signal (up-client-glue.c:1326)                                                                                                                                                               
==3809==  Address 0x19865810 is 0 bytes inside a block of size 128 free'd                                                                                                                                                                     
==3809==    at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)                                                                                                                                                     
==3809==    by 0x84767FE: g_free (gmem.c:190)
==3809==    by 0x84458CA: ptr_array_free (garray.c:1089)
==3809==    by 0x4062CE: main (gpm-statistics.c:1877)
==3809== 
==3809== Invalid read of size 4
==3809==    at 0x4067BB: gpm_stats_device_removed_cb (gpm-statistics.c:1275)
==3809==    by 0x7D9D9AF: g_cclosure_marshal_VOID__STRINGv (gmarshal.c:1004)
==3809==    by 0x7D9AF63: _g_closure_invoke_va (gclosure.c:831)
==3809==    by 0x7DB4B5F: g_signal_emit_valist (gsignal.c:3218)
==3809==    by 0x7DB53AE: g_signal_emit (gsignal.c:3365)
==3809==    by 0xB6C2DAF: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2)
==3809==    by 0xB6C2817: ffi_call (in /usr/lib64/libffi.so.6.0.2)
==3809==    by 0x7D9B553: g_cclosure_marshal_generic (gclosure.c:1448)
==3809==    by 0x7D9AD34: g_closure_invoke (gclosure.c:768)
==3809==    by 0x7DACA41: signal_emit_unlocked_R (gsignal.c:3553)
==3809==    by 0x7DB4200: g_signal_emitv (gsignal.c:3048)
==3809==    by 0x57AE28B: up_client_glue_proxy_g_signal (up-client-glue.c:1326)
==3809==  Address 0x19827d18 is 8 bytes inside a block of size 32 free'd
==3809==    at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3809==    by 0x84767FE: g_free (gmem.c:190)
==3809==    by 0x848DC43: g_slice_free1 (gslice.c:1112)
==3809==    by 0x84458A4: ptr_array_free (garray.c:1103)
==3809==    by 0x4062CE: main (gpm-statistics.c:1877)
==3809== 
==3809== Invalid read of size 4
==3809==    at 0x8445266: g_ptr_array_remove_index_fast (garray.c:1224)
==3809==    by 0x4067E9: gpm_stats_device_removed_cb (gpm-statistics.c:1278)
==3809==    by 0x7D9D9AF: g_cclosure_marshal_VOID__STRINGv (gmarshal.c:1004)
==3809==    by 0x7D9AF63: _g_closure_invoke_va (gclosure.c:831)
==3809==    by 0x7DB4B5F: g_signal_emit_valist (gsignal.c:3218)
==3809==    by 0x7DB53AE: g_signal_emit (gsignal.c:3365)
==3809==    by 0xB6C2DAF: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2)
==3809==    by 0xB6C2817: ffi_call (in /usr/lib64/libffi.so.6.0.2)
==3809==    by 0x7D9B553: g_cclosure_marshal_generic (gclosure.c:1448)
==3809==    by 0x7D9AD34: g_closure_invoke (gclosure.c:768)
==3809==    by 0x7DACA41: signal_emit_unlocked_R (gsignal.c:3553)
==3809==    by 0x7DB4200: g_signal_emitv (gsignal.c:3048)
==3809==  Address 0x19827d18 is 8 bytes inside a block of size 32 free'd
==3809==    at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3809==    by 0x84767FE: g_free (gmem.c:190)
==3809==    by 0x848DC43: g_slice_free1 (gslice.c:1112)
==3809==    by 0x84458A4: ptr_array_free (garray.c:1103)
==3809==    by 0x4062CE: main (gpm-statistics.c:1877)
==3809== 
==3809== Invalid read of size 8
==3809==    at 0x8445270: g_ptr_array_remove_index_fast (garray.c:1226)
==3809==    by 0x4067E9: gpm_stats_device_removed_cb (gpm-statistics.c:1278)
==3809==    by 0x7D9D9AF: g_cclosure_marshal_VOID__STRINGv (gmarshal.c:1004)
==3809==    by 0x7D9AF63: _g_closure_invoke_va (gclosure.c:831)
==3809==    by 0x7DB4B5F: g_signal_emit_valist (gsignal.c:3218)
==3809==    by 0x7DB53AE: g_signal_emit (gsignal.c:3365)
==3809==    by 0xB6C2DAF: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2)
==3809==    by 0xB6C2817: ffi_call (in /usr/lib64/libffi.so.6.0.2)
==3809==    by 0x7D9B553: g_cclosure_marshal_generic (gclosure.c:1448)
==3809==    by 0x7D9AD34: g_closure_invoke (gclosure.c:768)
==3809==    by 0x7DACA41: signal_emit_unlocked_R (gsignal.c:3553)
==3809==    by 0x7DB4200: g_signal_emitv (gsignal.c:3048)
==3809==  Address 0x19827d10 is 0 bytes inside a block of size 32 free'd
==3809==    at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3809==    by 0x84767FE: g_free (gmem.c:190)
==3809==    by 0x848DC43: g_slice_free1 (gslice.c:1112)
==3809==    by 0x84458A4: ptr_array_free (garray.c:1103)
==3809==    by 0x4062CE: main (gpm-statistics.c:1877)
==3809== 
==3809== Invalid read of size 8
==3809==    at 0x8445276: g_ptr_array_remove_index_fast (garray.c:1226)
==3809==    by 0x4067E9: gpm_stats_device_removed_cb (gpm-statistics.c:1278)
==3809==    by 0x7D9D9AF: g_cclosure_marshal_VOID__STRINGv (gmarshal.c:1004)
==3809==    by 0x7D9AF63: _g_closure_invoke_va (gclosure.c:831)
==3809==    by 0x7DB4B5F: g_signal_emit_valist (gsignal.c:3218)
==3809==    by 0x7DB53AE: g_signal_emit (gsignal.c:3365)
==3809==    by 0xB6C2DAF: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2)
==3809==    by 0xB6C2817: ffi_call (in /usr/lib64/libffi.so.6.0.2)
==3809==    by 0x7D9B553: g_cclosure_marshal_generic (gclosure.c:1448)
==3809==    by 0x7D9AD34: g_closure_invoke (gclosure.c:768)
==3809==    by 0x7DACA41: signal_emit_unlocked_R (gsignal.c:3553)
==3809==    by 0x7DB4200: g_signal_emitv (gsignal.c:3048)
==3809==  Address 0x19865818 is 8 bytes inside a block of size 128 free'd
==3809==    at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3809==    by 0x84767FE: g_free (gmem.c:190)
==3809==    by 0x84458CA: ptr_array_free (garray.c:1089)
==3809==    by 0x4062CE: main (gpm-statistics.c:1877)
==3809== 
==3809== Invalid read of size 8
==3809==    at 0x844527A: g_ptr_array_remove_index_fast (garray.c:1228)
==3809==    by 0x4067E9: gpm_stats_device_removed_cb (gpm-statistics.c:1278)
==3809==    by 0x7D9D9AF: g_cclosure_marshal_VOID__STRINGv (gmarshal.c:1004)
==3809==    by 0x7D9AF63: _g_closure_invoke_va (gclosure.c:831)
==3809==    by 0x7DB4B5F: g_signal_emit_valist (gsignal.c:3218)
==3809==    by 0x7DB53AE: g_signal_emit (gsignal.c:3365)
==3809==    by 0xB6C2DAF: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2)
==3809==    by 0xB6C2817: ffi_call (in /usr/lib64/libffi.so.6.0.2)
==3809==    by 0x7D9B553: g_cclosure_marshal_generic (gclosure.c:1448)
==3809==    by 0x7D9AD34: g_closure_invoke (gclosure.c:768)
==3809==    by 0x7DACA41: signal_emit_unlocked_R (gsignal.c:3553)
==3809==    by 0x7DB4200: g_signal_emitv (gsignal.c:3048)
==3809==  Address 0x19827d28 is 24 bytes inside a block of size 32 free'd
==3809==    at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3809==    by 0x84767FE: g_free (gmem.c:190)
==3809==    by 0x848DC43: g_slice_free1 (gslice.c:1112)
==3809==    by 0x84458A4: ptr_array_free (garray.c:1103)
==3809==    by 0x4062CE: main (gpm-statistics.c:1877)
==3809== 
==3809== Invalid write of size 4
==3809==    at 0x84452A7: g_ptr_array_remove_index_fast (garray.c:1234)
==3809==    by 0x4067E9: gpm_stats_device_removed_cb (gpm-statistics.c:1278)
==3809==    by 0x7D9D9AF: g_cclosure_marshal_VOID__STRINGv (gmarshal.c:1004)
==3809==    by 0x7D9AF63: _g_closure_invoke_va (gclosure.c:831)
==3809==    by 0x7DB4B5F: g_signal_emit_valist (gsignal.c:3218)
==3809==    by 0x7DB53AE: g_signal_emit (gsignal.c:3365)
==3809==    by 0xB6C2DAF: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2)
==3809==    by 0xB6C2817: ffi_call (in /usr/lib64/libffi.so.6.0.2)
==3809==    by 0x7D9B553: g_cclosure_marshal_generic (gclosure.c:1448)
==3809==    by 0x7D9AD34: g_closure_invoke (gclosure.c:768)
==3809==    by 0x7DACA41: signal_emit_unlocked_R (gsignal.c:3553)
==3809==    by 0x7DB4200: g_signal_emitv (gsignal.c:3048)
==3809==  Address 0x19827d18 is 8 bytes inside a block of size 32 free'd
==3809==    at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3809==    by 0x84767FE: g_free (gmem.c:190)
==3809==    by 0x848DC43: g_slice_free1 (gslice.c:1112)
==3809==    by 0x84458A4: ptr_array_free (garray.c:1103)
==3809==    by 0x4062CE: main (gpm-statistics.c:1877)

This probably explains the sporadic crashes.
The exact sequence of events are as follows:

1) Laptop battery removed, laptop on AC power, mouse dongle is inserted and mouse is turned on
2) mate-power-statistics is ran through valgrind, shown above
3) mate-power-statistics powers up, showing three entries: AC Power, Mouse, and Processor. Mouse has the correct icon and is shown at 90% charge
4) unplug the dongle. valgrind spits all these error messages. No crash, but probably because of luck.
5) reconnect the dongle. No further valgrind messages, Mouse reappears at the bottom of the list (so now the order is AC Power, Processor and Mouse). Mouse is shown with a red icon as if the battery is empty, and is shown at 0%.

Hope that helps.

Summary:
If both batterys are use it crashes and stacktrace looks same like https://bugzilla.redhat.com/attachment.cgi?id=999016 , right?
If not can you provide a new one for this case please?

Only using mouse battery doesn't crash always, but power value is wrong after plugout/in the tongle.
Can you try to create a stacktrace for this case if it crashes please?
It's easier for upstream to work with a stacktrace.

Thank you

Created attachment 1001380 [details]
Backtrace with mate-power-manager-1.8.1-4 and upower-0.99.2-2. Mouse battery only.

The backtrace for a crash in mate-power-statistics with mouse battery only.

To clarify: the % of mouse battery is now garbled most of the time, even if when you first start mate-power-statistics. It displays it correctly only intermittently. It was reporting 90% all the time, before I applied the updates you gave here, so this is a regression.

next round of testing
http://koji.fedoraproject.org/koji/taskinfo?taskID=9242287
Please test with upower-0.99.2-2 ?

(In reply to Wolfgang Ulbrich from comment #32)
> next round of testing
> http://koji.fedoraproject.org/koji/taskinfo?taskID=9242287
> Please test with upower-0.99.2-2 ?

Works for me with a M525

Dear reporter, upstream did help you a lot and is waiting for confirmation.
Please test.

Sorry for the delay.
Yes, it works for me as well - no crashes reported :)

There's a message, however, when you run mate-power-statistics in gdb:

(mate-power-statistics:6637): libupower-glib-CRITICAL **: up_device_get_object_path: assertion 'UP_IS_DEVICE (device)' failed

this is printed to the console when I unplug the dongle. More specifically:

1. I start mate-power-statistics with the mouse dongle plugged in.
2. I unplug the dongle, mate-power-statistics correctly detects the mouse is gone, the item is removed from the list of devices. No message is printed to the console.
3. Plug in the dongle again; device reappears in mate-power-statistics, no message is printed.
4. When I unplug, the above assertion is printed once.
5. A next round of plug and unplug - the above assertion is printed twice
6. Next round of plug and unplug - the above assertion is printed 3 times (all appear simultaneously)
7. Next round - message appears 4 times.

This may hint to some resource leak.

Also, now my mouse is listed at 0% and "unknown state" all the time. I guess the mouse can't really report the battery level (which seems reasonable for an alkaline battery), so I guess the 90% report I was seeing previously was fabricated; However, what's the use of showing the mouse device if the battery charge and consumption rate is not known anyway?

(In reply to skalaren_alpinist from comment #35)
> Sorry for the delay.
> Yes, it works for me as well - no crashes reported :)
Thanks for testing.
> 
> There's a message, however, when you run mate-power-statistics in gdb:
> 
> (mate-power-statistics:6637): libupower-glib-CRITICAL **:
> up_device_get_object_path: assertion 'UP_IS_DEVICE (device)' failed
> 
> this is printed to the console when I unplug the dongle. More specifically:
> 
> 1. I start mate-power-statistics with the mouse dongle plugged in.
> 2. I unplug the dongle, mate-power-statistics correctly detects the mouse is
> gone, the item is removed from the list of devices. No message is printed to
> the console.
> 3. Plug in the dongle again; device reappears in mate-power-statistics, no
> message is printed.
> 4. When I unplug, the above assertion is printed once.
> 5. A next round of plug and unplug - the above assertion is printed twice
> 6. Next round of plug and unplug - the above assertion is printed 3 times
> (all appear simultaneously)
> 7. Next round - message appears 4 times.
> 
> This may hint to some resource leak.
I noticed that glib-gio warnings too on my PC (without any batteries).
We think that those are low level warnings somewhere from glib/gtk.
You see that with gnome-power-statistis too.
On my laptop with only a general battery i don't see this warnings.
> 
> Also, now my mouse is listed at 0% and "unknown state" all the time. I guess
> the mouse can't really report the battery level (which seems reasonable for
> an alkaline battery), so I guess the 90% report I was seeing previously was
> fabricated;
This might be possible, i think your device was the fist device from logitech with stats support.
We have feedback from other guys with much modern logiteck devices, where a value is displayed.
> However, what's the use of showing the mouse device if the
> battery charge and consumption rate is not known anyway?
I think your device sends characteristics that is able to provide power stats.
But whithout having a technical paper about this function it's hard to say something.
Unfortunately, logitech provide any information about.

mate-power-manager-1.8.2-0.1.git20150319.dc4d2c3.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/mate-power-manager-1.8.2-0.1.git20150319.dc4d2c3.fc21

Package mate-power-manager-1.8.2-0.1.git20150319.dc4d2c3.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing mate-power-manager-1.8.2-0.1.git20150319.dc4d2c3.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-4350/mate-power-manager-1.8.2-0.1.git20150319.dc4d2c3.fc21
then log in and leave karma (feedback).

Sorry, the fix (1.8.1-5 and the 1.8.2-0) don't really fix my issue. I was wrong in comment #35, the package keeps crashing, however not every time. When testing in #35, I tried twice and it worked, so I assumed the problem was fixed.

Backtrace, generated from 1.8.2.0 is attached. Also, the following valgrind warnings appear:

===========================================================================

[vesko@tank ~]$ valgrind mate-power-statistics
==7547== Memcheck, a memory error detector
==7547== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==7547== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==7547== Command: mate-power-statistics
==7547== 
==7547== Invalid read of size 8
==7547==    at 0x57AC7CE: up_device_get_object_path (up-device.c:179)
==7547==    by 0x4067C0: ??? (in /usr/bin/mate-power-statistics)
==7547==    by 0x7D9D9AF: g_cclosure_marshal_VOID__STRINGv (gmarshal.c:1004)
==7547==    by 0x7D9AF63: _g_closure_invoke_va (gclosure.c:831)
==7547==    by 0x7DB4B5F: g_signal_emit_valist (gsignal.c:3218)
==7547==    by 0x7DB53AE: g_signal_emit (gsignal.c:3365)
==7547==    by 0xB6C2DAF: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2)
==7547==    by 0xB6C2817: ffi_call (in /usr/lib64/libffi.so.6.0.2)
==7547==    by 0x7D9B553: g_cclosure_marshal_generic (gclosure.c:1448)
==7547==    by 0x7D9AD34: g_closure_invoke (gclosure.c:768)
==7547==    by 0x7DACA41: signal_emit_unlocked_R (gsignal.c:3553)
==7547==    by 0x7DB4200: g_signal_emitv (gsignal.c:3048)
==7547==  Address 0x1a44d5b0 is 32 bytes inside a block of size 72 free'd
==7547==    at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7547==    by 0x84767FE: g_free (gmem.c:190)
==7547==    by 0x848DC43: g_slice_free1 (gslice.c:1112)
==7547==    by 0x7DBCD31: g_type_free_instance (gtype.c:1929)
==7547==    by 0xB6C2DAF: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2)
==7547==    by 0xB6C2817: ffi_call (in /usr/lib64/libffi.so.6.0.2)
==7547==    by 0x7D9B553: g_cclosure_marshal_generic (gclosure.c:1448)
==7547==    by 0x7D9AD34: g_closure_invoke (gclosure.c:768)
==7547==    by 0x7DACA41: signal_emit_unlocked_R (gsignal.c:3553)
==7547==    by 0x7DB4200: g_signal_emitv (gsignal.c:3048)
==7547==    by 0x57AE28B: up_client_glue_proxy_g_signal (up-client-glue.c:1326)
==7547==    by 0xB6C2DAF: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2)
==7547== 
==7547== Invalid read of size 8
==7547==    at 0x7DBD966: g_type_check_instance_is_a (gtype.c:3964)
==7547==    by 0x57AC7E5: up_device_get_object_path (up-device.c:179)
==7547==    by 0x4067C0: ??? (in /usr/bin/mate-power-statistics)
==7547==    by 0x7D9D9AF: g_cclosure_marshal_VOID__STRINGv (gmarshal.c:1004)
==7547==    by 0x7D9AF63: _g_closure_invoke_va (gclosure.c:831)
==7547==    by 0x7DB4B5F: g_signal_emit_valist (gsignal.c:3218)
==7547==    by 0x7DB53AE: g_signal_emit (gsignal.c:3365)                                                                                                                                                                                      
==7547==    by 0xB6C2DAF: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2)                                                                                                                                                                     
==7547==    by 0xB6C2817: ffi_call (in /usr/lib64/libffi.so.6.0.2)                                                                                                                                                                            
==7547==    by 0x7D9B553: g_cclosure_marshal_generic (gclosure.c:1448)                                                                                                                                                                        
==7547==    by 0x7D9AD34: g_closure_invoke (gclosure.c:768)                                                                                                                                                                                   
==7547==    by 0x7DACA41: signal_emit_unlocked_R (gsignal.c:3553)                                                                                                                                                                             
==7547==  Address 0x1a44d5b0 is 32 bytes inside a block of size 72 free'd                                                                                                                                                                     
==7547==    at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)                                                                                                                                                     
==7547==    by 0x84767FE: g_free (gmem.c:190)                                                                                                                                                                                                 
==7547==    by 0x848DC43: g_slice_free1 (gslice.c:1112)                                                                                                                                                                                       
==7547==    by 0x7DBCD31: g_type_free_instance (gtype.c:1929)                                                                                                                                                                                 
==7547==    by 0xB6C2DAF: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2)                                                                                                                                                                     
==7547==    by 0xB6C2817: ffi_call (in /usr/lib64/libffi.so.6.0.2)                                                                                                                                                                            
==7547==    by 0x7D9B553: g_cclosure_marshal_generic (gclosure.c:1448)                                                                                                                                                                        
==7547==    by 0x7D9AD34: g_closure_invoke (gclosure.c:768)                                                                                                                                                                                   
==7547==    by 0x7DACA41: signal_emit_unlocked_R (gsignal.c:3553)                                                                                                                                                                             
==7547==    by 0x7DB4200: g_signal_emitv (gsignal.c:3048)                                                                                                                                                                                     
==7547==    by 0x57AE28B: up_client_glue_proxy_g_signal (up-client-glue.c:1326)                                                                                                                                                               
==7547==    by 0xB6C2DAF: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2)                                                                                                                                                                     
==7547==                                                                                                                                                                                                                                      
                                                                                                                                                                                                                                              
(mate-power-statistics:7547): libupower-glib-CRITICAL **: up_device_get_object_path: assertion 'UP_IS_DEVICE (device)' failed

========================================================================

Sequence of events:

1. Start mate-power-statistics under valgrind
2. Unplug the dongle. Nothing happens
3. Plug the dongle. Nothing happens
4. Unplug the dongle. The above errors are printed.

I guess the issue persists in a more subtle form.

Without valgrind, the crash occurs after the 4th or 5th disconnect of the dongle. Under valgrind, it never crashes, but I guess it's a chance thing. Moreover, no further error messages are generated. I guess the same invalid memory access occurs deterministically.

Created attachment 1005041 [details]
Backtrace with mate-power-manager-1.8.2.

(In reply to skalaren_alpinist from comment #40)
> Created attachment 1005041 [details]
> Backtrace with mate-power-manager-1.8.2.

Hmm, is this with fixed upower version?
http://koji.fedoraproject.org/koji/buildinfo?buildID=621503

Yes. I had it with upower-0.99.2-2, but upgrading to 0.99.2-4 didn't change a thing.

mate-power-manager-1.8.2-0.1.git20150319.dc4d2c3.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.