1981802 - Crash in [@ morkRowObject::GetOid] on Raptor Lake Intel family 6 model 183 stepping 1

Status: NEW

(Thunderbird :: General, defect)

Description

[Gabriele Svelto [:gsvelto]]

Crash report: https://crash-stats.mozilla.org/report/index/f9575008-06e2-481b-a28f-e6e330250807

Reason:

EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames:

0  xul.dll  morkRowObject::GetOid(nsIMdbEnv*, mdbOid*)  mailnews/db/mork/morkRowObject.cpp:143
1  xul.dll  nsMsgHdr::nsMsgHdr(nsMsgDatabase*, nsIMdbRow*)  mailnews/db/msgdb/src/nsMsgHdr.cpp:34
2  xul.dll  nsMsgDatabase::CreateMsgHdr(nsIMdbRow*, unsigned int, nsIMsgDBHdr**)  mailnews/db/msgdb/src/nsMsgDatabase.cpp:776
3  xul.dll  nsMsgThread::GetChildHdrAt(unsigned int, nsIMsgDBHdr**)  mailnews/db/msgdb/src/nsMsgThread.cpp:445
4  xul.dll  nsMsgThread::GetRootHdr(nsIMsgDBHdr**)  mailnews/db/msgdb/src/nsMsgThread.cpp:823
5  xul.dll  nsCOMPtr<nsIMsgDBHdr>::assign_assuming_AddRef(nsIMsgDBHdr*)  xpcom/base/nsCOMPtr.h:318
5  xul.dll  nsCOMPtr<nsIMsgDBHdr>::StartAssignment()  xpcom/base/nsCOMPtr.h:790
5  xul.dll  nsCOMPtr<nsIMsgThread>::operator->() const  xpcom/base/nsCOMPtr.h:967
5  xul.dll  nsMsgThreadedDBView::InitThreadedView(int&)  mailnews/base/src/nsMsgThreadedDBView.cpp:0
6  xul.dll  nsMsgThreadedDBView::Open(nsIMsgFolder*, int, int, int)  mailnews/base/src/nsMsgThreadedDBView.cpp:62

This is the n-th crash only happening to users with Raptor Lake systems and thus most likely caused by a hardware flaw in those CPUs. Interestingly this is the first bug I found that happens in 32-bit code.

Comment 1

[Kai Engert [:KaiE:]]

Sounds tricky.

Do you have any suggestions what we could do?

Comment 2

[Magnus Melin [:mkmelin]]

I do wonder if that 'mRowObject_Row' should be null-checked

Comment 3

[Gabriele Svelto [:gsvelto]]

There isn't much to do unless Intel identifies the issue, deploys a fix via microcode and the fix gets shipped to users. I'm filing these bugs so that developers are aware of them and don't waste time trying to debug impossible scenarios caused by a CPU bug.

Comment 4

[Kai Engert [:KaiE:]]

(In reply to Magnus Melin [:mkmelin] from comment #2)

I do wonder if that 'mRowObject_Row' should be null-checked

I think a null pointer would trigger a different exception name.

We're getting EXCEPTION_ACCESS_VIOLATION_READ, so it's probably that we're trying to access wrong memory.

Comment 5

[Wayne Mery (:wsmwk)]

Notable, significant increase in crashes at 140.1.0esr

98% raptor lake. Furthermore, the most active Thunderbird crash signature for raptor lake

Other high correlations to raptor lake with no bug report:

• ~70% mozilla::StyleOwnedSlice<T>::AsSpan
• 100% mozilla::detail::InvalidArrayIndex_CRASH | XPCWrappedNative::CallMethod

Comment 6

[Gabriele Svelto [:gsvelto]]

In the first of those two crash signatures the remaining crashes often have bit-flips, so they're likely to be mostly bad hardware (either Raptor Lake or something else), but given how generic the signature is some real bugs might be lurking in there. The second one is 100% Raptor Lake on Firefox too and worth filing so people don't waste time on it.

Comment 7

[Gabriele Svelto [:gsvelto]]

Scratch my previous comment, I see that the second signature has already gone away in the last few weeks so no point in opening a new bug.

Comment 8

[Wayne Mery (:wsmwk)]

From https://support.mozilla.org/en-US/questions/1556772#answer-1788784 => https://crash-stats.mozilla.org/report/index/12f8fc2c-c505-40f0-8c67-44b730251224#tab-details @ morkParser::ReadAlias. That user also has [@ PtrInfo::WasTraversed ] https://crash-stats.mozilla.org/report/index/070bf941-4e8b-41a3-8b84-3e3440251224

Comment 9

[Max Emig [:maxe]]

In bug 2052101 I attempted to guard and so far it's working. And in general it's a mostly raptor lake bug where we can't do much.