Description of problem: This is a funny one. I've an external firewire HDD, with encrypted partition using LUKS. This HDD is almost always connected to the PC, so it is *not* automounted on hot plug (since it is not hot plugged). In order to mount/umount it, I usually use nautilus. Now and then, just during or after (difficult to time it) mounting/umounting, the gnome-applet-timer crashes, with a pop-up asking if the applet should be reloaded. Version-Release number of selected component (if applicable): gnome-applet-timer-2.0.1-9.fc10.x86_64 How reproducible: Not always, but often Steps to Reproduce: 1. install the applet on one gnome-panel 2. mount/umount this external HDD from nautilus Actual results: The applet crashes and a pop-up ask if it should be reloaded. Expected results: Well, nothing about the applet. Additional info: A "dmesg" just after the event, reports: ... python[3154]: segfault at 1 ip 00007f2c14bb55c0 sp 00007fff2348b170 error 4 in libgobject-2.0.so.0.1800.4[7f2c14b8e000+41000] ... So, this could be a python problem, which could be confirmed by the fact that, maybe, also other python applications crashed during the "gnome-mount" operation (but I cannot confirm exactly, sorry). It would also interesting to understand which implications this could have. Since we are dealing with an encrypted thing, with password, I wonder if there could be some leakage somewhere. This could be, in the end, a security issue.
Indeed, this is really strange. Please try to reproduce it with more debug info by performing the following steps: 1. remove all instances of the applet from your panel 2. run /usr/lib/timer-applet/timer-applet in a terminal 3. add the applet to your panel again 3. mount/unmount your external drive until the applet crashes 4. attach the output from the terminal to this bug.
One thing I forgot, this is an x86_64 installation, maybe this could make the difference. Anyway, here it is, not so much, to be honest: $> /usr/lib64/timer-applet/timer-applet Using these definitions: GETTEXT_PACKAGE: timer-applet LOCALE_DIR: /usr/share/locale RESOURCES_DIR: /usr/share/timer-applet IMAGES_DIR: /usr/share/pixmaps Timer Manager D-Bus object path: /net/sourceforge/timerapplet/TimerApplet/TimerManager At that point it crashed while mounting the LUKS volume 2 out of 3 times. Of course, I also re-added the applet to the panel. The D-Bus thing could have something to do. I do not know how it works, but maybe a message is broadcasted from gnome-mount and the applet (or python) does not like it. Hope this helps, pg
Thanks, this helps a lot. I think that dbus is the culprit here, because we had some libnotify/dbus issues previously in bug # 471465. Looks like the patch in this release isn't working properly. Upstream pushed a new version, but I have updated it only in rawhide. Please try if the updated package from http://koji.fedoraproject.org/koji/taskinfo?taskID=1301994 fixes your problem.
Thanks for the update. Unfortunately, this seems to have some issues, I cannot add it to the panel, an error is returned. From command line, I get: $> /usr/lib64/timer-applet/timer-applet Using these definitions: GETTEXT_PACKAGE: timer-applet LOCALE_DIR: /usr/share/locale RESOURCES_DIR: /usr/share/timer-applet IMAGES_DIR: /usr/share/pixmaps Traceback (most recent call last): File "/usr/lib64/timer-applet/timer-applet", line 25, in <module> from timerapplet.controllers import GlobalController, TimerApplet, TimerService, TimerManagerService File "/usr/lib/python2.5/site-packages/timerapplet/controllers/__init__.py", line 18, in <module> from TimerApplet import TimerApplet File "/usr/lib/python2.5/site-packages/timerapplet/controllers/TimerApplet.py", line 26, in <module> import gst ImportError: No module named gst Maybe some dependencies is missing? I hope "gst" does not refer to gstreamer... pg
(In reply to comment #4) > I hope "gst" does not refer to gstreamer... Sorry to disappoint you, but actually it does. Upstream has switched to gstplay instead of the obsolete nome.sound_play function. Thanks for catching this, I will roll a new pakage with proper dependencies. Meanwhile, please install gstreamer-python and try again. TIA!
(In reply to comment #5) > Sorry to disappoint you, but actually it does. Upstream has switched to gstplay > instead of the obsolete nome.sound_play function. Thanks for catching this, I Ops...! :-) Well, I was just surprised to see that a small gadget needs quite an infrastructure to work. Nevermind, it is not a problem. > will roll a new pakage with proper dependencies. Meanwhile, please install > gstreamer-python and try again. TIA! OK, I installed the dependency and re-added the applet. The very first "mount" led to a crash, but successive trial could not reproduce the problem. I also tried to repeat the procedure with the command line, but I was not able to crash the applet again. Even if, after some mount/umount, the command line part exited, without any error, but the applet was still working. Nevertheless, I think this could be considered fixed. If it happens again I'll put a note here. Thanks again, pg
Sorry, I was too fast. I tried a mount again and the applet crashed. Maybe now is more robust, but not really fully fixed. pg
Can you please try again after logging out and in again or even rebooting, just to make sure?
(In reply to comment #8) > Can you please try again after logging out and in again or even rebooting, just > to make sure? It could be this made the trick, since after reboot (I guess logout/login would have been enough) I had 3 applet on the panel. Anyway, after removing all 3 and re-adding the timer (and verifying there is only one), I tried several times to mount/umount the LUKS volume. I did not get any crash so far, so maybe it is OK. Thanks, pg
Ok, then I assume that it is fixed with the update I'm going to push out. The bug will be ON_QA for a while, please report if the bug hits you again. Thanks a lot for your bug report and your help to debug the problem!
gnome-applet-timer-2.1.2-2.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/gnome-applet-timer-2.1.2-2.fc10
gnome-applet-timer-2.1.2-2.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update gnome-applet-timer'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3718
In the last few days I was mounting/umountig the LUKS volume, without problems. Just right now, while mounting, the applet crashed again. So, maybe there is still something left to check. Hope this helps, pg
I'll need to talk about this with upstream. Stay tuned.
gnome-applet-timer-2.1.2-2.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
I guess this should not be closed, since the problem is still there, albeit it happens not so often as before. Actually, I got the crash still 1/2~1/3 of the times I mount the LUKS disk. pg
Some news. I'm now on F-11 and, while I did not see (yet) the problem with the external HDD I used before, I could get the crash (python segfault) with another external USB storage, which is connected/mounted, or umounted/disconnected, by scripts. It seems some operation in the scripts causes a segfault. The "start" scripts does: mdadm -A ... && lvchange -ay ... && cryptsetup luksOpen ... && mount ... The "stop" script does the reverse, i.e. umount, luksClose, -an, --stop... One (or more) of the operations crashes the applet. Hope this helps, piergiorgio
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. 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 WONTFIX if it remains open with a Fedora 'version' of '10'. 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 prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I "updated" this to f11, because, while the situation is much better, still sometimes I experienced the crash while mounting the luks disk. I will see after f12, if no problems occur, then, I think, it would be possible to let this issue fall off. bye, pg
Thanks for updateing the bug to F11. I'm not a friend of the bugzappers who just close down bugs, I prefer fixing them properly. Please test in F12 again. With abrt, the automatic bug reporting tool, we should be able to get a nice traceback without too much hassle. TIA!
Hi, short update, with F12 I never saw the issue again, so it seems it is somehow gone. bye, pg
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 WONTFIX if it remains open with a Fedora 'version' of '11'. 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 prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 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. Thank you for reporting this bug and we are sorry it could not be fixed.