hangs after compact. using 20101008. I have compact set to a) compact at saving 50k or something and b) prompt me to confirm. in one of these cases, I clicked compact prompt a second time because I wasn't sure the first click took.
does stack suggest a next step?
Summary: hangs after compact → hangs after responding to compact prompt
the stacks are rather different. the second is painting a tree view. the first is performing a biff
(In reply to comment #3) > the stacks are rather different. the second is painting a tree view. the > first is performing a biff hopefully this happens only with mail.purge.ask enabled, which I do. perhaps a duplicate is Bug 599489 - hang after canceling prompt for auto compact - which happened after I clicked _cancel_ instead of _continue_ (which is this bug) I did a quick query of bugs from the past 3 years  and there don't seem to be any that match this description, i.e. involving prompts. A more thorough examine is needed to see if any do NOT involve prompts. Speculatively, I'll mention that I've sometimes experienced hangs when deleting messages in the message list obtained from a facet search results - the symptoms of which are very similar to this bug (but without the compact prompt), the symptoms being either an outright hang, or a long pause of 30-60 seconds or more. N.B. asuth's comment bug 605487 comment 5  https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=anywordssubstr&list_id=408739&short_desc=compact&field0-0-0=short_desc&bug_severity=critical&bug_severity=major&bug_severity=normal&type0-0-1=anywordssubstr&field0-0-1=keywords&value2-0-0=crash&field2-0-0=keywords&chfieldto=Now&type2-0-0=notsubstring&query_format=advanced&chfieldfrom=2009-01-23&value1-0-0=ask%20prompt%20cancel%20continue&short_desc_type=allwordssubstr&value0-0-1=hang%20perf&type0-0-0=anywordssubstr&value0-0-0=slow%20long%20spin%20freez%20froz&product=MailNews%20Core&product=Thunderbird
Summary: hangs after responding to compact prompt → hang painting tree or biff after responding confirm to compact prompt with mail.purge.ask enabled
bienvenu, standard8, this is being heavily reported in getsatisfaction - http://getsatisfaction.com/mozilla_messaging/tags/compacthang I haven't fully triaged all the topics, but it seems clear that we need to ship a fix. I forgot I had already filed Bug 599489 - hang after canceling prompt for auto compact. Andrew comments "The stack shows a biff happening when the "autocompact?" dialog is on the screen which apparently triggered at the tail end of a move or something. Presumably having all the move logic on the stack with an event loop spun inside of it for the modal dialog is dangerous. The autocompact prompt should likely be deferred so that it executes in the top-level of the event loop instead of with a bunch of stuff on the stack."
Deferring the prompt until the next time through the event loop is fine and easy. I can't say that the hang stack makes much sense since there are no loops or semaphores involved. The hang painting the tree might have to do with trying to get the indentation level of a header that has been deleted. That has has been known to make xul hang.
I can add, that the hang was very reproducible for me using those 3.3 builds, eg 20101008 and 20100923.
(In reply to comment #8) > I can add, that the hang was very reproducible for me using those 3.3 > builds, eg 20101008 and 20100923. What about TB 5? I left that prompt up for 40 minutes and didn't have a problem.
> this is being heavily reported in getsatisfaction - http://getsatisfaction.com/mozilla_messaging/tags/compacthang reporting rate in gfsn for hangs is about 1 per day. xref bug 673856 (In reply to comment #9) > (In reply to comment #8) > > I can add, that the hang was very reproducible for me using those 3.3 > > builds, eg 20101008 and 20100923. > > What about TB 5? I left that prompt up for 40 minutes and didn't have a > problem. Leaving the prompt up is not one of the steps. And, it doesn't hang until "Compact Now" is clicked. I haven't seen it myself for a long time, so something changed in my environment since I reported it, either in the code side or in my profile.
Whiteboard: [has stacktrace] → [has stacktrace][gs]
this just delays a little bit and allows the stack to unwind before doing an autocompact. I don't know what it will help with, other than leaving the view with a partially deleted message when it tries to paint, in the case of deleting a local msg and the prompt getting put up in the middle of finishing the delete.
Assignee: nobody → dbienvenu
Attachment #550833 - Flags: review?(mbanner)
from a support perspective, if this patch helps (and as you say, your not sure) it would be great if this made the v6 train. But I don't claim to understand the risks of the patch. Can you make a try build, and we could put it in the hands of a few of the recent gsfn reporters who have not yet been given the workaround of disabling the "ask"? Related points - it's disappointing that none of our beta and other testers encountered or reported this issue. Either a result of not enough testers, or low failure rate. - do we have any tests of any type for compact? I didn't find any in litmus
we have xpcshell tests for compact; don't know if we have mozmill tests. But since no one can reproduce the issue, I'm not sure litmus tests would have helped. I'll generate a try server build with the patch, off of comm-beta.
try server builds should show up here in a couple hours - http://email@example.com I did it off a comm-beta repo, so it *should* be very similar to TB 6.
Given how late we are in the 6 cycle, I don't really want to risk this. Whilst it should be low risk, there could be extra issues, and I'd rather we have a bit more time to confirm it.
workaround - tweak the ask preference ... If unchecking "Always ask ..." in the compact dialog fails, then: - go to the Config Editor. In Thunderbird do Tools → Options (or Preferences) → Advanced → General tab → Config Editor - paste mail.purge.ask into the filter - double click that entry, to change the value to false Now, the dialog prompt should not occur.
Whiteboard: [has stacktrace][gs] → [has stacktrace][gs][workaround: comment 18
Thank you, that fixed the issue.
could not get a beta try server build to work, but I did get a trunk try server build with the patch - http://firstname.lastname@example.org/try-win32/thunderbird-8.0a1.en-US.win32.zip
(In reply to David :Bienvenu from comment #20) > could not get a beta try server build to work, but I did get a trunk try > server build with the patch - > http://ftp.mozilla.org/pub/mozilla.org/thunderbird/try-builds/ > email@example.com/try-win32/thunderbird-8.0a1.en-US.win32. > zip posted the tryserver links in couple topics - crossed fingers for good response. I'm running it now for a few hours with no ill effects. However, I can't confirm it fixes the hang - because I haven't been seeing the hang.
Comment on attachment 550833 [details] [diff] [review] run autocompact from an event This does seem a better way of doing it.
Attachment #550833 - Flags: review?(mbanner) → review+
http://hg.mozilla.org/comm-central/rev/e15d27718d81 optimistically marking fixed - would be great to get some feedback from a user who is seeing this issue.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 8.0
Checked into aurora: http://hg.mozilla.org/releases/comm-aurora/rev/15e5ee238a76
(In reply to David :Bienvenu from comment #23) > http://hg.mozilla.org/comm-central/rev/e15d27718d81 > > optimistically marking fixed - would be great to get some feedback from a > user who is seeing this issue. http://getsatisfaction.com/mozilla_messaging/topics/compact_folders_not_responding#reply_6383809 reports good results with the tryserver build. good to see this got into v7 alpha. THanks!
You need to log in before you can comment on or make changes to this bug.