GNOME Bugzilla – Bug 589993
Entry disappears from DB if edited while the minute changes
Last modified: 2009-08-10 12:41:37 UTC
Example: It's now 11:28 and Hamster is tracking an activity since 10:14. I want to edit the note about the activity, so I click once on the panel, and then on the icon with the notebook page / pencil on it. If while I am editing the system clock goes to 11:29, when I press "Save" the entry disappears from the DB, with Hamster signalling "No activity" on the taskbar.
Just wished to inform that occasionally the problem presents itself even if the clock is not turning over the minutes, but I could not notice any other recurrent pattern that might be of help in understanding what triggers the bug. :(
Hmmm, i can not really replicate the bug. There must be something else that is triggering the condition.
you might try running hamster from console. remove hamster from panel and do /usr/lib/hamster-applet/hamster-applet -w > log.txt and see if you can trigger the bug. resulting log.txt will contain all the sql statements, feel free to attach it to this bug. Thanks!
Well, in the first place I suppose it's me who has to thank you for the very quick response! :) Odd enough, if I run the applet in windowed mode the bug does not seem to happen (I made about 20 attempts, without success). In the docked version (on the gnome-pane) of it, the bug was triggered at the second attempt. I would be happy to log the events for you, if you could suggest me a way to kill the applet that is already running ("sudo killall -9 hamster-applet" returns "hamster-applet: no process killed"). I assume that once killed, I should then run the line of code above without the -w parameter... Thanks :)
hamster as such has no process. it's hiding behind the big brother "python" so you can killall it (most of the time hamster's only one doing that, we had part of code changing the process name but something was bad with that code, don't really remember.) but code wise there is really no difference between docked and terminal version, which could mean that either it is random, and randomness is bit troubling, or there are some special conditions we are not afraid of. i'd love to help i just don't know how (apart from fixing "something"). well, one thing you could do, since we are so close to shipping 2.28, is run bleeding edge hamster from git master. instructions for that are in http://projecthamster.wordpress.com/building-and-running/
Created attachment 139579 [details] Log of the crash in windowed mode
Created attachment 139580 [details] Log of the crash in windowed mode
Sorry. I missed to understand how this bug tracking system works, so this text was to be found before the attached file.... ------- Hi, first of all thank you very much for the supportive spirit in this! It's a period I am posting a lot of bugs to different communities and I have to say that it's amazing how different can react to that. My unscientific approach so far is that python projects answer kindly, php ones harshly, it would be interesting to make a more in-depth study on coding principles and programmers' mood... Anyhow... let's not digress. I finally managed to get hamster windowed to crash. I am posting here the output in the console and attaching the log file. ---- /usr/lib/hamster-applet/hamster-applet -w > ~/log.txt ** (hamster-applet:18729): WARNING **: Binding '<Super>H' failed! /usr/lib/python2.6/dist-packages/hamster/applet.py:337: GtkWarning: gtk_cell_layout_set_attributes: assertion `GTK_IS_CELL_RENDERER (cell)' failed self.activity_list.set_property("text-column", 2) /usr/lib/python2.6/dist-packages/hamster/add_custom_fact.py:114: GtkWarning: gtk_cell_layout_set_attributes: assertion `GTK_IS_CELL_RENDERER (cell)' failed self.activity_list.set_property("text-column", 2) (hamster-applet:18729): Bonobo-WARNING **: Never got frame, control died - abnormal exit condition
Sorry for delay, Mac - i'm half on vacation so hamster get's some offline too :) Two warnings and that "never got frame" is pretty minor and not related to the case really. The attached log file though has no evidence of deletion but the end time of the fact got updated and the date is two days in future (from your comment). Ooh, i got an idea - if you generated the bug with 2.26 and are running a 686 machine, it could be you have caught the infamous Bug 568797. Could you maybe verify if that disappearance was a fact in future instead of a delete? As for your unscientific studies - i'm afraid no generalization can be made in open source - everybody is up to his own and the best way to survive is to try to be kind. But everybody breaks once in a while :)
Hi! No problem with the delay, I am - ehm, WAS - on a break too. Yes, after a few attempts, I can confirm that occasionally the year of the event changes, for example two minutes ago I got an event which date got reset to 62. I will try to install the latest version from the repo sometimes this week, from the latest entries on your blog it seems that there are a few nice goodies included! :) Thank you for the assistance. I am going to change the status of the bug to duplicate, then. Many thanks, Mac. *** This bug has been marked as a duplicate of 568797 ***