Closed Bug 254199 Opened 21 years ago Closed 21 years ago

mail crashes after changing criteria when searching

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: worcester12345, Assigned: Bienvenu)

References

Details

(Keywords: crash, fixed-aviary1.0)

Attachments

(1 file)

proposed fix
531 bytes, patch
mscott
: superreview+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.1+ (bangbang023) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.1+ (bangbang023) Try searching on more than one criteria. Then, in the middle of the search, hit "stop" and change criteria, then hit search again. It will crash. version 0.6+ (20040521)Thunderbird (originally). version 0.7+ (20040803)Thunderbird (most recently). If this should go to Thunderbird, please feel free to do so. I am assuming it does it in mail/news since Thunderbird people haven't touched it lately. Reproducible: Always Steps to Reproduce: 1. Do a search on your inbox. 2. Hit "Stop", then change search criteria. 3. Hit "Search" again. 4. Crash. Actual Results: Crashes out. Expected Results: Search on new criteria.
Sasquatch Bigfoot: Could you provide TalkBack incident ID of your crash?
Severity: major → critical
Keywords: crash
(In reply to comment #1) > Sasquatch Bigfoot: Could you provide TalkBack incident ID of your crash? No, Talkback didn't install with this build. Actually, yes, but it was an older one. How do I find the Talkback info again? By the way, I am now wondering if this should go under Thunderbird instead of "MailNews". I think I saw that and hit it before even thinking of Thunderbird. Thanks
i can confirm the bug - not running talkback, so can't help here though...
Component: Search → Mail Window Front End
Product: MailNews → Thunderbird
Version: Trunk → unspecified
Flags: blocking-aviary1.0?
Requesting blocking since it IS a confirmed crasher.
Still getting it with this build: version 0.7+ (20040803) ("official")
Flags: blocking-aviary1.0PR?
Are you using advanced search, i.e., edit | find | search messages, or <cntrl> <shift> F ? or quick search? If advanced search, is this an imap inbox or a pop3 inbox?
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #6) > Are you using advanced search, i.e., edit | find | search messages, or <cntrl> > <shift> F ? or quick search? If advanced search, is this an imap inbox or a pop3 > inbox? I am using advanced search, i.e., edit | find | search messages. This is for pop3 mail.
are you searching on message bodies, or a "custom" header? I was able to eventually reproduce a crash with this stack trace when stopping a search enough times. But this code is only used for searching message bodies, I believe... nsMsgSearchScopeTerm::SetInputStream(nsMsgSearchScopeTerm * const 0x041b77d8, nsIInputStream * 0x00000000) line 1491 + 23 bytes nsMsgSearchOfflineMail::CleanUpScope() line 718 nsMsgSearchOfflineMail::~nsMsgSearchOfflineMail() line 279 nsMsgSearchOfflineMail::`scalar deleting destructor'(unsigned int 0x00000001) + 15 bytes nsMsgSearchAdapter::Release(nsMsgSearchAdapter * const 0x04f09cb8) line 99 + 209 bytes nsMsgSearchOfflineMail::Release(nsMsgSearchOfflineMail * const 0x04f09cb8) line 269 + 12 bytes nsCOMPtr<nsIMsgSearchAdapter>::~nsCOMPtr<nsIMsgSearchAdapter>() line 510 nsMsgSearchScopeTerm::~nsMsgSearchScopeTerm() line 1434 + 33 bytes nsMsgSearchScopeTerm::`scalar deleting destructor'(unsigned int 0x00000001) + 15 bytes nsMsgSearchSession::DestroyScopeList() line 632 + 31 bytes nsMsgSearchSession::ClearScopes(nsMsgSearchSession * const 0x044439d0) line 222
Attached patch proposed fix — — Splinter Review
nulling out the comptr prevents the crash when the released search adaptor tries to clean up the scope which is in the process of being deleted. This is kind of a work-around fix, but unravelling the ownership issues here might be dangerous.
Assignee: sspitzer → bienvenu
Status: NEW → ASSIGNED
Attachment #155332 - Flags: superreview?(mscott)
Attachment #155332 - Flags: superreview?(mscott) → superreview+
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
(In reply to comment #8) > are you searching on message bodies, or a "custom" header? I was able to > eventually reproduce a crash with this stack trace when stopping a search enough > times. But this code is only used for searching message bodies, I believe... > Yes, I was searching message bodies. I can get you the talkback info if you tell me how. Thanks for looking at this.
(In reply to comment #8) > are you searching on message bodies, or a "custom" header? I was able to > eventually reproduce a crash with this stack trace when stopping a search enough > times. But this code is only used for searching message bodies, I believe... > Yes, I was searching message bodies. I can get you the talkback info if you tell me how. Thanks for looking at this.
Flags: blocking-aviary1.0PR?
Flags: blocking-aviary1.0?
(In reply to comment #9) > Created an attachment (id=155332) > proposed fix > > nulling out the comptr prevents the crash when the released search adaptor > tries to clean up the scope which is in the process of being deleted. This is > kind of a work-around fix, but unravelling the ownership issues here might be > dangerous. What do you mean by "work-around fix"? Should this remain open then, maybe?
no, the bug is fixed. I can imagine a much more involved and dangerous fix entailing reworking the search code, but I think we'll go with the simple safe fix of nulling out the comptr.
It is not fixed, cause it appeares again in 0.7.3 And it does not happen with only bodies, but with subject search too.
oleg: i believe this is fixed. please test with the latest nightly 0.8 builds and see if you can reproduce. i was able to reproduce with 0.7.3, but it has since been fixed on the 0.8 branch...and the crash will be gone in the next major release/milestone. marking verified.
Status: RESOLVED → VERIFIED
*** Bug 249560 has been marked as a duplicate of this bug. ***
Is this one also fixed on trunk? Shouldn't it remain open until the trunk is updated with this fix? That is how it works over on Firefox.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
we only close bugs as fixed that have been fixed on the trunk. That's why I marked it fixed.
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
I searched this entire bug page, and didn't see it mention trunk anywhere, same with "View Bug Activity" page. Thanks anyhow, though.
marking it fixed means it's fixed on the trunk. So when the bug resolution is "fixed", that means fixed on the trunk.
cannot seem to repro this using today's aviary tbird bits, so verifying.
Status: RESOLVED → VERIFIED
(In reply to comment #22) > cannot seem to repro this using today's aviary tbird bits, so verifying. I KNOW it was fixed on Aviary. That is where it was broken, and it was also patched and I tested it out and saw it is indeed fixed on Aviary. My question was whether anyone saw if this was ever broken on trunk since I haven't used trunk builds of Thunderbird since maybe .4 or .5 or so. Thanks.
this was fixed on the trunk a long time ago.
Bug 301180 seems to be a report that this fix never landed on the MOZILLA_1_7_BRANCH (for the suite 1.7.x releases).
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: