1628242 - Thunderbird Crash in [@ NS_QuickSort]

Status: RESOLVED DUPLICATE of bug 1498313

(Thunderbird :: General, defect)

Description

[Wayne Mery (:wsmwk)]

Frequency has increased in version 68.

This bug is for crash report bp-95775a7a-d048-4001-9cf8-4b0870200408.

Top 10 frames of crashing thread:

0 xul.dll NS_QuickSort xpcom/ds/nsQuickSort.cpp:116
1 xul.dll NS_QuickSort xpcom/ds/nsQuickSort.cpp:160
2 xul.dll NS_QuickSort xpcom/ds/nsQuickSort.cpp:160
3 xul.dll NS_QuickSort xpcom/ds/nsQuickSort.cpp:160
4 xul.dll NS_QuickSort xpcom/ds/nsQuickSort.cpp:160
5 xul.dll NS_QuickSort xpcom/ds/nsQuickSort.cpp:160
6 xul.dll NS_QuickSort xpcom/ds/nsQuickSort.cpp:160
7 xul.dll NS_QuickSort xpcom/ds/nsQuickSort.cpp:160
8 xul.dll NS_QuickSort xpcom/ds/nsQuickSort.cpp:160
9 xul.dll NS_QuickSort xpcom/ds/nsQuickSort.cpp:160

Comment 1

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Comment 2

[Wayne Mery (:wsmwk)]

Looks like the crash rate for 78.x is at least equal to 68.x. Too early to say if it is higher.

bp-6317e90e-9414-4165-b21d-fe7410200806 78.1.0

Comment 3

[Ben Campbell]

Wow - looks like some serious recursion going on there - the stack trace leaves out the middle 10000 or so frames!

Unfortunately all the useful bits are somewhere within those 10000 frames. I know the crash occurs somewhere within XREMain::XRE_mainRun()... but that doesn't really narrow anything down :-(

I won't do anything on this just yet, but here are my notes for future me if we decide to bump up the priority:

• QuickSort is recursing waaaaaay more times than it should (quicksort subdivides, so 10000 calls implies something like 10e10000 elements in the dataset!).
• Maybe it's an empty set being passed in and QuickSort can't handle it (unlikely - QuickSort is pretty battle-hardened).
• My money would be on a bad comparator being used somewhere. eg a greater-that-or-equal test being a bit unstable on the 'equals' case.
• search for all uses of NS_QuickSort in C-C and sanity-check.
• nsMsgDBView is the only direct caller of NS_QuickSort but I'm pretty certain there are indirect uses too (eg nsTArray<>.Sort())

Comment 4

[Ben Campbell]

Also it looks like the crash happens early on (maybe even during startup). Which has bearing on which bits of code might be responsible.

Comment 5

[Wayne Mery (:wsmwk)]

(In reply to Ben Campbell from comment #4)

Also it looks like the crash happens early on (maybe even during startup). Which has bearing on which bits of code might be responsible.

True to come extent. Specifically, half of crashes are 15 seconds or less (about 30% are 9 seconds or less)

(In reply to Wayne Mery (:wsmwk) from comment #2)

Looks like the crash rate for 78.x is at least equal to 68.x. Too early to say if it is higher.

Now that 78 updates are complete we can say the rate has stayed steady, roughly the same for 78.

Comment 6

[d.hodgkinson]

I seem to be having this crash on 91.7.0 on every startup.
Crash ID: bp-97be5c5b-8de3-4e5d-b37a-5e7671220331

Comment 7

[Magnus Melin [:mkmelin]]

https://crash-stats.thunderbird.net/report/bp-97be5c5b-8de3-4e5d-b37a-5e7671220331

Comment 8

[Wayne Mery (:wsmwk)]

91.2.1 crash rate was roughly 30/day, 2 crashes per installation

Comment 9

[d.hodgkinson]

I (In reply to Wayne Mery (:wsmwk) from comment #8)

91.2.1 crash rate was roughly 30/day, 2 crashes per installation

I no longer encounter this crash after creating a new profile.

Comment 10

[Sean Burke [:leftmostcat]]

C++ std::sort should be more resistant to stack overflow (commonly uses introsort, which will fall back to a heap sort if the input is too large), so replacing NS_QuickSort() should address these crashes.