Closed Bug 423825 Opened 17 years ago Closed 16 years ago

Crash [@ random address @ nsMsgSearchOfflineMail::~nsMsgSearchOfflineMail()]

Categories

(MailNews Core :: Search, defect)

x86
Linux
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: bc, Unassigned)

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

Note: I'm not offline when this crash happens.
Attached patch proposed fixSplinter Review
For instance OnStopRunningUrl also null checks m_scope so I assume it could be needed here too.
Assignee: nobody → mkmelin+mozilla
Status: NEW → ASSIGNED
Attachment #310533 - Flags: superreview?(bienvenu)
Attachment #310533 - Flags: review?(bienvenu)
Comment on attachment 310533 [details] [diff] [review] proposed fix sure, thx, Magnus.
Attachment #310533 - Flags: superreview?(bienvenu)
Attachment #310533 - Flags: superreview+
Attachment #310533 - Flags: review?(bienvenu)
Attachment #310533 - Flags: review+
Modifying summary, I think the other ones the same issue... Checking in mailnews/base/search/src/nsMsgLocalSearch.cpp; /cvsroot/mozilla/mailnews/base/search/src/nsMsgLocalSearch.cpp,v <-- nsMsgLocalSearch.cpp new revision: 1.82; previous revision: 1.81 done ->FIXED. Try tomorrows build.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Summary: Crash [@ random address @ nsMsgSearchOfflineMail::~nsMsgSearchOfflineMail()] → Crash [@nsMsgSearchOfflineMail::CleanUpScope()]
Target Milestone: --- → Thunderbird 3
I can crash the 32bit nightlies and the 64bit builds I am doing on CentOS 5 64bit. All I have to do to reproduce is simply click on local and search folders until I crash. #5 0x00002aaaafba020e in nsMsgSearchOfflineMail::CleanUpScope (this=0xbe39700) at /work/mozilla/builds/1.9.0/mozilla/mailnews/base/search/src/nsMsgLocalSearch.cpp:721 #6 0x00002aaaafba202a in ~nsMsgSearchOfflineMail (this=0xbe39700) at /work/mozilla/builds/1.9.0/mozilla/mailnews/base/search/src/nsMsgLocalSearch.cpp:270 #7 0x00002aaaafba624d in nsMsgSearchAdapter::Release (this=0xbe39700) at /work/mozilla/builds/1.9.0/mozilla/mailnews/base/search/src/nsMsgSearchAdapter.cpp:109 #8 0x00002aaaafba2437 in nsMsgSearchOfflineMail::Release (this=0xbe39700) at /work/mozilla/builds/1.9.0/mozilla/mailnews/base/search/src/nsMsgLocalSearch.cpp:261 #9 0x00002aaab8c0a081 in nsCOMPtr<nsIUrlListener>::assign_assuming_AddRef ( this=0xb60d838, newPtr=0xbc19ba8) at ../../../dist/include/xpcom/nsCOMPtr.h:568 #10 0x00002aaab8c0a0bc in nsCOMPtr<nsIUrlListener>::assign_with_AddRef ( this=0xb60d838, rawPtr=0xbc19ba8) (gdb) frame 5 #5 0x00002aaaafba020e in nsMsgSearchOfflineMail::CleanUpScope (this=0xbe39700) at /work/mozilla/builds/1.9.0/mozilla/mailnews/base/search/src/nsMsgLocalSearch.cpp:721 721 m_scope->SetInputStream(nsnull); (gdb) p m_scope $1 = (class nsIMsgSearchScopeTerm *) 0xbe38c80 I only know the most basic gdb stuff, but it appears to me that m_scope is not null when m_scope->SetInputStream(nsnull) crashes. if (m_scope) m_scope->SetInputStream(nsnull);
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
bc: http://www.mozilla.org/unix/debugging-faq.html use x/wa to find the type of m_scope, something like: x/wa m_scope p ((nsMsgSearchScopeTerm *) m_scope)->mRefCnt
(gdb) p ((nsMsgSearchScopeTerm *) m_scope)->mRefCnt $6 = {mValue = 452353536}
Assignee: mkmelin+mozilla → nobody
Status: REOPENED → NEW
Need more info, fresh crash ids perhaps, to make progress on this.
Flags: blocking-thunderbird3.0a1? → blocking-thunderbird3.0a1-
Target Milestone: Thunderbird 3 → ---
reverting to original summary as it more accurately describes this crash.
Summary: Crash [@nsMsgSearchOfflineMail::CleanUpScope()] → Crash [@ random address @ nsMsgSearchOfflineMail::~nsMsgSearchOfflineMail()]
Almost all exactly the same. Crashing there doesn't make sense to me...
I can help debug it if you want to provide me hands on instruction on irc. Just look for bc.
PS. This is a newer Xeon with DEP if that helps.
bc: how about using refcount logging for nsMsgSearchOfflineMail ? :) http://developer.mozilla.org/en/docs/Debugging_memory_leaks if you're lucky, the object is known dead...
Severity: major → critical
Component: General → Search
Product: Thunderbird → MailNews Core
QA Contact: general → search
Bob, can you still reproduce this? nsMsgSearchOfflineMail doesn't appear in any current crashes on crash-stats
No, I haven't been crashing recently at all on Shredder but I'm using Mac now. I think we can mark this wfm.
Status: NEW → RESOLVED
Closed: 17 years ago16 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ random address @ nsMsgSearchOfflineMail::~nsMsgSearchOfflineMail()]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: