Closed Bug 1743389 Opened 2 years ago Closed 2 years ago

Crash in [@ mozilla::BackgroundHangAnnotators::GatherAnnotations]

Categories

(Toolkit :: General, defect, P4)

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: gsvelto, Unassigned)

Details

(Keywords: crash)

Crash Data

Crash report: https://crash-stats.mozilla.org/report/index/79a315eb-3370-4487-b070-37e8d0211029

Reason: SIGSEGV / SEGV_MAPERR

Top 5 frames of crashing thread:

0 libxul.so mozilla::BackgroundHangAnnotators::GatherAnnotations toolkit/components/backgroundhangmonitor/HangAnnotations.cpp:83
1 libxul.so mozilla::BackgroundHangManager::MonitorThread toolkit/components/backgroundhangmonitor/BackgroundHangMonitor.cpp:79
2 libnspr4.so _pt_root nsprpub/pr/src/pthreads/ptthread.c:201
3 libpthread.so.0 start_thread /usr/src/debug/glibc-2.33-20.fc34.x86_64/nptl/pthread_create.c:481
4 libc.so.6 __GI___clone 

This appears to be a NULL pointer access. It's very low volume, but this code is only enabled on nightly AFAIK so that would explain why.

Florian, do you know who owns BHR at this point, and if they could take a look? Is there a better bmo component than Toolkit::General?

Flags: needinfo?(florian)
Flags: needinfo?(florian) → needinfo?(dothayer)

Gabriele, is there a convenient way to see the disassembly of the code around the crash site? It looks like the only thing that could produce that stack is i wrapping a NULL pointer, but I can't see any way for that to happen short of mAnnotators being corrupted from outside.

Flags: needinfo?(dothayer)

(adding needinfo re: comment 2)

Flags: needinfo?(gsvelto)

(In reply to Doug Thayer [:dthayer] (he/him) from comment #2)

Gabriele, is there a convenient way to see the disassembly of the code around the crash site? It looks like the only thing that could produce that stack is i wrapping a NULL pointer, but I can't see any way for that to happen short of mAnnotators being corrupted from outside.

IIRC we include the memory are containing the code surrounding the crashed IP in the minidump precisely for this purpose... but we don't have a tool to inspect it (yet).

Flags: needinfo?(gsvelto)

Should this still be considered an S2, and if so should we try harder to find an owner for this?

Flags: needinfo?(gsvelto)

No, not with this volume.

Severity: S2 → S3
Flags: needinfo?(gsvelto)
Priority: -- → P4

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.