536070 - tb3 crashes on searching in news [@ malloc | operator new(unsigned int) | orkinHeap::Alloc(nsIMdbEnv*, unsigned int, void**)] | [@ arena_malloc_small ] | [@ RtlEnterCriticalSection]

Status: VERIFIED DUPLICATE of bug 530044

(Thunderbird :: Folder and Message Lists, defect)

Description

[Zoltán Halassy]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; hu; rv:1.9.2b5) Gecko/20091204 Firefox/3.6b5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; hu; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1 Thunderbird/3.0

I just freshly added news.mozilla.org to tb3, subscribed to mozilla.dev.apps.thunderbird . I downloaded all headers (9101), then i ordered the messages my date, descending. Selected "subject" clicking the magnifying glass near the search textinput. When i type the word "config" into the search box, (without "" marks, not hitting enter), after 1 sec it starts filtering out news, but after the next second thunderbird crashes.


Reproducible: Always

Steps to Reproduce:
add a new newsbox, news.mozilla.org, subscribe mozilla.dev.apps.thunderbird, dwonload headers, select "subject" for search, type "config".
Actual Results:  
Crash.

Expected Results:  
Shouldn't crash.


Don't know it matters, but:
My system: Hungarian version of Windows Vista Ultimate 64bit, Hungarian version of TB, lightning beta installed. Using NOD32 as virus scanner.

When added the newsgroup, it asked twice for downloading headers (and it seemed it did it twice actually, and after it crashed for the first time, it showed 18k headers, then after 3 secs it showed 9k properly). Browsing and reading the messages are working properly.

Comment 1

[Wayne Mery (:wsmwk)]

maybe bug 517662  Crash through nsMsgDBView::RemoveRows when opening newsgroup 

we can tell when you post the crash report id and signature per http://kb.mozillazine.org/Breakpad#Location_of_crash_reports

Comment 2

[Zoltán Halassy]

All from the same problem:

bp-28106d06-dd39-451c-8b23-8c7d82091220
bp-2ec33719-e709-4b66-a728-107072091220
bp-943e4863-ba4e-4e9a-82c3-a05df2091220
bp-c7f60099-759b-4872-adeb-997702091220
bp-eed009f4-f717-4e60-8c57-309462091220

Comment 3

[Phil Ringnalda (:philor)]

Should be fixed on the trunk already, in 3.0 nightlies soon, and in 3.0.1 when it comes out.

Comment 4

[Wayne Mery (:wsmwk)]

(In reply to comment #2)
> All from the same problem:
> 
> bp-28106d06-dd39-451c-8b23-8c7d82091220 [@ arena_malloc_small]
> bp-2ec33719-e709-4b66-a728-107072091220 [@ malloc | operator new(unsigned int) | orkinHeap::Alloc(nsIMdbEnv*, unsigned int, void**)]
> bp-943e4863-ba4e-4e9a-82c3-a05df2091220  [@ RtlEnterCriticalSection]
> bp-c7f60099-759b-4872-adeb-997702091220 [@ RtlEnterCriticalSection] FF bug 524921 
> bp-eed009f4-f717-4e60-8c57-309462091220 [@ arena_malloc_small] bug 530044

agree, likely duplicate of bug 530044.  which also means bug 530044 manifests as a great number of crash signatures, which may well elevate the desire to take bug 530044 on 3.0.x branch after short baking period.

[@ RtlEnterCriticalSection] is #48 crash
arena_malloc_small is #34
malloc | operator new(unsigned int) | orkinHeap::Alloc(nsIMdbEnv*, unsigned int, void**) is #240

in 3.0.1pre I see only variations of sig operator new.  But I suspect a high % of long time 3.0x testers have abandoned ship and now on "stable" 3.0.0.  We should try to ascertain via statistics if that is indeed the case, as it hurts our testing/QA strength.

Comment 5

[Wayne Mery (:wsmwk)]

Zoltán, can you test 3.0.1pre ASAP and indicate whether your crash is gone?
ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-1.9.1/
If it is gone, then we can *reverify* that bug 530044 fixed your crash.

Comment 6

[Ben Bucksch (:BenB)]

I saw this bug (exactly as the initial description says) on a 2009-12 build, but it's gone on a 2010-02 build.

VERIFIED

Comment 7

[Ben Bucksch (:BenB)]

(Note: I didn't bother to get a stack, my assertion is based on the symptoms.)