Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 702165 - crash [@ nsMsgQuickSearchDBView::OnSearchDone ] - .. - [@ nsMsgSearchSession::InterruptSearch] when change folders before search is finished
: crash [@ nsMsgQuickSearchDBView::OnSearchDone ] - .. - [@ nsMsgSearchSession:...
: crash
Product: MailNews Core
Classification: Components
Component: Backend (show other bugs)
: Trunk
: All All
: -- critical with 2 votes (vote)
: Thunderbird 19.0
Assigned To: Kent James (:rkent)
: 793447 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2011-11-13 17:18 PST by NoOp
Modified: 2012-11-03 01:38 PDT (History)
11 users (show)
rkent: in‑testsuite-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

check m_db at the start (1.06 KB, patch)
2012-09-23 23:40 PDT, Kent James (:rkent)
irving: review+
standard8: approval‑comm‑aurora+
standard8: approval‑comm‑beta+
Details | Diff | Splinter Review

Description NoOp 2011-11-13 17:18:47 PST
User Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111110 Firefox/8.0 SeaMonkey/2.5
Build ID: 20111110143639

Steps to reproduce:

I have two folders set up to capture searches from an nntp list via 
The search searches the message body text for LibreOffice versions; 3.3. and 3.4. respectively. The resulting searchs are listed in my email folder as:
  - 3.3.4
  - 3.4.3

Actual results:

clickin on on of the folders (3.3.4 or 3.4.3) causes SeaMonkey to crash. However it is not consistent & doesn't happen every time.

Expected results:

Not crash.
Crash reports are located here:

Advise on the (Neil) is to include reference to:
[(filterbar) quick search filtering outside of full searching (implement filter bar, separate quickfilter and global search)] as he believe the code in that bug report may be a contributing factor.
Comment 1 NoOp 2011-11-13 17:23:44 PST
CC'ing asuth (patch author) and :bienvenu (reviewer) per Neil's recommendation.
Comment 2 H. Hofer 2011-11-17 10:23:16 PST
I've got some of those under Windows, too (rare, but going on for quite a while):


It usually happens, if I change folders while the search hasn't finished yet.
Comment 3 NoOp 2011-11-17 11:43:51 PST
Ah interesting. Thanks for that. If I recall that seems to have been what I had done as well (change folders while the search hasn't finished). I'll give it a try again today when I'm ready to close down SeaMonkey.
Comment 4 NoOp 2011-11-17 12:04:33 PST
That did the trick... changed folders while the search hadn't finished.
Comment 5 Wayne Mery (:wsmwk, NI for questions) 2012-02-25 09:23:30 PST
Comment 6 Tony Mechelynck [:tonymec] 2012-09-22 21:45:32 PDT
SeaMonkey (Linux64) bug 793447 has the same signature. Related?
Comment 7 Kent James (:rkent) 2012-09-23 09:05:11 PDT
A call to nsMsgDBView::Close nulls m_db, yet the code at the crashing address assumes that m_db is valid, and crashes if not.

Seems pretty clear that all methods in the search views need to behave reasonably with null m_db. I think that the correct thing to do here, as I am starting to do in other places, is to acquire a local reference to the db from the folder and use that, else just return.
Comment 8 Tony Mechelynck [:tonymec] 2012-09-23 09:15:19 PDT
*** Bug 793447 has been marked as a duplicate of this bug. ***
Comment 9 Kent James (:rkent) 2012-09-23 23:40:54 PDT
Created attachment 663926 [details] [diff] [review]
check m_db at the start

It seems to me that if the view has been closed so that m_db is null, there is no point in going through the bulk of this method, so we should just quit there.

I'm not sure if a Close() can happen while executing this method, but I don't think so, so I don't need to check m_db later at the crash point.
Comment 10 :Irving Reid (No longer working on Firefox) 2012-10-29 14:03:27 PDT
Comment on attachment 663926 [details] [diff] [review]
check m_db at the start

Review of attachment 663926 [details] [diff] [review]:

nsMsgDBView::Close() and nsMsgQuickSearchDBView::OnSearchDone() are both called on the UI thread, as far as I can tell, so we don't need to worry about synchronization.
Comment 11 Kent James (:rkent) 2012-10-30 06:36:35 PDT
Comment on attachment 663926 [details] [diff] [review]
check m_db at the start

Checked in
Comment 12 Kent James (:rkent) 2012-10-30 06:40:32 PDT
Comment on attachment 663926 [details] [diff] [review]
check m_db at the start

This patch should land in tb-17 after baking in core.

User impact if declined: crash

Testing completed (on c-c, etc.): checked in, still needs baking

Risk to taking this patch (and alternatives if risky): None.
Comment 13 Mark Banner (:standard8) 2012-11-02 10:33:37 PDT
Comment on attachment 663926 [details] [diff] [review]
check m_db at the start

[Triage Comment]
Yep, lets get this onto branches
Comment 14 Mike Conley (:mconley) - (high latency on reviews and needinfos) 2012-11-02 11:18:20 PDT
Comment 15 NoOp 2012-11-02 11:47:02 PDT
Thanks for the fix. Can we please also ensure that this fix is included in SeaMonkey 14? Thanks.
Comment 16 Jens Hatlak (:InvisibleSmiley) 2012-11-03 01:38:05 PDT
(In reply to NoOp from comment #15)
> Thanks for the fix. Can we please also ensure that this fix is included in
> SeaMonkey 14? Thanks.

The fix landed on comm-beta after SM 2.14b3 was tagged, so it'll automatically be included in SM 2.14b4 (unless it's backed out before then).

Note You need to log in before you can comment on or make changes to this bug.