GNOME Bugzilla – Bug 213775
expunge on exit not working (sometimes?)
Last modified: 2005-11-25 00:13:13 UTC
I am accessing a POP server and Inbox is a local folder. Repro: Enable "expunge on exit" in Mail Settings. Mark a message for deletion. Exit Evo. Result: The message remains. This is 100% repeatable for me.
Could you check the option is still set? If it is, could you try toggling it and see if it has any effect. I've tried this with several differnet mailboxes and it works fine with the current cvs code.
I tried deleting some messages, toggling to disabled, exiting, killev and then toggle to enabled and exiting. The messages still had not been expunged when I ran killev and started Evolution again. I am giving plenty of time for processes to exit before running killev.
Uh, dont run killev, you never said that, well of COURSE the option isn't going to work if you murder it before its finished. If its deadlocked thats an entirely different issue. Please get a backtrace. Is the disk busy? -> then its still expunging. Is it not? -> then its probably deadlocked.
There is no disk activity. And, I have submitted bugs for the various processes left hanging around after exiting Evo. I see no sign of a deadlock, because when I run killev, the remaining processes are wombat, bonobo-moniker-xmldb and evolution-alarm-notify. There don't appear to be any processes that would be involved in an expunge operation.
This bug goes away if I test with ORBit-0.5.11, bonobo 1.0.11 and bonobo-conf 0.13. I can't really consider this bug fixed, though, since I am unaware of any plan to include updated ORBit in the Evolution release. I also don't know if the CVS HEAD versions of bonobo and bonobo-conf will be included. To be clear, the disk activity continues longer than it did before. When I restart the client, mail has been expunged. Also interesting, bonobo-moniker-xmldb is no longer running after I exit Evolution. I suspect, now, that you were correct, NotZed, and the bonobo-moniker-xmldb was deadlocking. I did not realize that process played a role in the expunge functionality.
Thanks for the info. I think the shell is also interefereing with the speed of exit. It does a 'sleep' which for some reason interferes with the exit process when it goes into a loop waiting for things to exit. You can confirm this because if you run evolution-mail and evolution separately, then exit (with some deleted messages to expunge), you'll get something like 'waiting for component to die' every second from the shell and if the mailer is outputting any stuff (which it wont now, 'cause a lot of debug has been turned off), you'll see it start to sync and pause with the shell. Maybe? Well thats what i've seen anyway.
*** bug 214217 has been marked as a duplicate of this bug. ***
is this still reproducable? I just tried what you said and it spit out "waiting for mail component to die (1)" and then quit.
also note that I am running ORBit-0.5.8, bonobo-1.0.9 and bonobo-conf-0.12
jeff, notzed: miles is off the net for the weekend, so he won't respond until monday, most likely. In the meantime upping this to blocker as a tracker for the other hang on exit bugs (which I'm most likely going to dup off this one and close.)
The tile is a bit off, its not hanging on exit, its just sometimes busy, and when its not, its just not expunging on exit. Also miles seems to be the only opne getting it.
miles: are you still seeing this?
Yes, I am still seeing it. Once it starts happening, it doesn't stop happening until I exit Evolution while not viewing the Mail component. I seem to reliably be able to get expunge on exit to work by switching to the Summary component before exiting. NotZed gave me a patch for testing whether it might be the case that in the failure instance, the folder is being dereferenced (probably not the correct concept exactly, but you get the idea) before the expunge code is called. NotZed, here are my results: In neither the success or the failure case was your debugging code activated. SPecifically, I never saw output from the following printf statements: printf("Finalising folder: %s\n", camel_folder->full_name); printf("CamelVeeFolder '%s' starting sync\n", folder->full_name); printf("CamelVeeFolder '%s' syncing sybfolder '%s'\n", folder->full_name, f->full_name); For some reason, the code paths containing these debug statements is never taken. Also, my debug output from the success and error cases is as follows: SUCCESS ------- (In this case, you can see the Summary rendering output getting interrupted.) Image Image Image Entity: line 45: error: Entity 'aacute' not defined <title>Hispalinux está en el SIMO</title> ^ Vfolder 'Trash' subfolder changed 'home/miles/evolution/local/Inbox' changed 0 added 0 removed 2 removing uid '7413' removing uid '7414' FAILURE ------- evolution-mail-CRITICAL **: file mail-display.c: line 991 (load_http): assertion `ba != NULL' failed. evolution-mail-CRITICAL **: file mail-display.c: line 991 (load_http): assertion `ba != NULL' failed. handle: 0x82d4708 orig: 4 actual: 4 url: http://us.i1.yimg.com/us.yimg.com/i/cal/bell4.gif data: 0x82d3d28 len: 120 writing ... handle: 0x81fbd38 orig: 4 actual: 4 url: http://us.i1.yimg.com/us.yimg.com/i/greet/icon.gif data: 0x82d3e7c len: 547writing ... handle: 0x82da720 orig: 4 actual: 4 url: http://us.i1.yimg.com/us.yimg.com/i/icon/inv.gif data: 0x82d3e90 len: 375 writing ... handle: 0x82d37e0 orig: 4 actual: 4 url: http://us.a1.yimg.com/us.yimg.com/a/he/headhunter/lrec1_01.jpg data: 0x82d3f08 len: 13089 writing ... handle: 0x82db290 orig: 4 actual: 4 url: http://us.a1.yimg.com/us.yimg.com/a/he/headhunter/lrec1_02.jpg data: 0x82d3f1c len: 1622 writing ... handle: 0x82d43c0 orig: 4 actual: 4 url: http://us.adserver.yahoo.com/l?M=203703.1574537.3128247.1383170/D=cal/S=152200099:LREC/A=721813/rand=dv8TBZYr3H14GT1005200707 data: 0x82d3f94 len: 43 writing ... handle: 0x83953f8 orig: 6 actual: 6 url: http://us.i1.yimg.com/us.yimg.com/i/cal/bell4.gif data: 0x80edd90 len: 120 writing ... handle: 0x8262470 orig: 6 actual: 6 url: http://us.i1.yimg.com/us.yimg.com/i/greet/icon.gif data: 0x82d4048 len: 547writing ... handle: 0x82daa98 orig: 6 actual: 6 url: http://us.i1.yimg.com/us.yimg.com/i/icon/inv.gif data: 0x82d405c len: 375 writing ...
On further testing, it appears that the only debug output usually emitted in the failure case is: Waiting for component to die -- OAFIID:GNOME_Evolution_Mail_ShellComponent (1) Waiting for component to die -- OAFIID:GNOME_Evolution_Calendar_ShellComponent (1) I get this when I have triggered the error case, exit evolution, then restart and exit. All subsequent start/exit cycles emit the "Waiting for component..." messages. On the other hand, the initial failure seems to always include: url: http://us.i1.yimg.com/us.yimg.com/i/cal/bell4.gif data: 0x82d3d28 len: 120 writing ... handle: 0x81fbd38 orig: 4 actual: 4 -------------- As far as the success case goes, I have seen another debug output pattern in at least one instance. In this instance, I had switched to the Task List before exiting. This time, messages were expunged, but I didn't see the "Vfolder 'Trash' subfolder changed 'home/miles/evolution/local/Inbox'" line ever get emitted. Instead, I got: Waiting for component to die -- OAFIID:GNOME_Evolution_Mail_ShellComponent (1) Waiting for component to die -- OAFIID:GNOME_Evolution_Mail_ShellComponent (2) Waiting for component to die -- OAFIID:GNOME_Evolution_Calendar_ShellComponent (1) ed 0 removed 3 removing uid '7410' removing uid '7411' removing uid '7412'
So you are never getting ANY folder finalised? Its not even TRYING to expunge the trash _at_ all? I'm at a loss.
Created attachment 40592 [details] [review] change trash behaviour
Miles can you test the attached patch please? I'm not sure its the best method for solving this problem, but its the easiest at the moment. It also improves some other aspects of the 'trash' behaviour, it could just lead to excessive memory usage for people with many folders. I think the best would be to have the camel_store_sync() function include an expunge parameter as camel_folder_sync() does, and empty trash should iterate over the stores doing camel_folder_sync instead.
Created attachment 40593 [details] [review] another try
Just to follow up. I tested the patch and it worked. However, NotZed has mentioned possible complications with the patch and is exploring other fix implementations.
Created attachment 40631 [details] [review] another go, works through store_sync
So this patch doesn't fix it either, same problem, some folders being unreffed before sync gets to run. But both patches should probably go in because they clean up other parts of the code, but after 1.0. To fix the actual problem is going to be a little tricker. I dont want to add a msg_wait to the expunge code. Perhaps camel should just run the expunge in another thread itself, since it can ref the folders before it starts the expunge (perhaps an option to expunge?). I'm marking as 1.0.x: at worst the behaviour is annoying, and anything to fix it is likely to be risky since it deals with exit behaviour.
*** bug 215119 has been marked as a duplicate of this bug. ***
notzed: have these patches been committed? I assume the bug is still not fixed
*** bug 217105 has been marked as a duplicate of this bug. ***
No not fixed. Still same reason.
*** bug 218274 has been marked as a duplicate of this bug. ***
This should depend on the vfolder rewrite bug, or be implemented some other way.
Creating dependency as per last comment.
*** bug 247977 has been marked as a duplicate of this bug. ***
Hi all, i dont see this bug happen anymore. Things seem to be working fine for me.
yeah, seems to be fixed. please reopen if this still happens in a current evo version