Intermittent PROCESS-CRASH | damp | application crashed [@ CrashReporter::CreateMinidumpsAndPair(void *,unsigned long,nsTSubstring<char> const &,nsIFile *,nsIFile * *)]

REOPENED
Unassigned

Status

()

defect
--
critical
REOPENED
a month ago
2 hours ago

People

(Reporter: whimboo, Unassigned)

Tracking

({crash, regression})

68 Branch
mozilla68
ARM64
Windows
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox68 fix-optional)

Details

Attachments

(1 obsolete attachment)

(In reply to Gabriele Svelto [:gsvelto] from bug 1531876 comment #12)

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+1] from comment #11)

(In reply to Stephen Donner [:stephend] from comment #7)

Looks like it caught a crasher, here: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=239180509&repo=try&lineNumber=3126

This crash is:

23:23:12 INFO - Thread 0 (crashed)
23:23:12 INFO - 0 xul.dll!CrashReporter::CreateMinidumpsAndPair(void *,unsigned long,nsTSubstring<char> const &,nsIFile *,nsIFile * *) [nsExceptionHandler.cpp:03593782f9c13b4f635cdf5a138b23d8901c40a1 : 3529 + 0xc8]
23:23:12 INFO - Found by: given as instruction pointer in context

Gabriele, is that a stack you have seen yet? At least I cannot find a bug logged about that.

No, and the crash reason is very odd: EXCEPTION_NONCONTINUABLE_EXCEPTION. I've never encountered it before, Windows documentation suggests that it might happens in case of code mismatches (like an x86-64 program trying to load an x86 DLL) but the stack doesn't suggest that here.

Comment 2

29 days ago
Pushed by sdonner@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/176055665c32
run talos-damp only on try, due to crashes.  r=jmaher

Comment 3

29 days ago
bugherder
Status: NEW → RESOLVED
Last Resolved: 29 days ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Assignee: nobody → stephen.donner

Sorry, I didn't intend to imply that I was working on the crasher, nor that my patch would 'fix' this bug. https://hg.mozilla.org/mozilla-central/rev/176055665c32 merely makes it run by default only on try.

As my patch only ameliorates this for the given platform, but doesn't fix or address it at all otherwise, I'm reopening and unassigning (apologies for the mishap).

Happy to take pointers on how best to straighten this up (I was worried a bit about it in https://phabricator.services.mozilla.com/D28437 but didn't ask explicitly enough/vet).

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: stephen.donner → nobody

Stephen, you may have mixed up the bug numbers in the commit message when pushing the patch to phabricator. You could have updated the bug number there before pushing. But it's too late now for a correction.

Maybe file a follow-up bug to revert the change once this bug got fixed.

Side note: crash reporting on Windows/AArch64 is badly broken right now because of bug 1542827. The issue here might or might not be affected by that so I'm not putting that bug as a blocker. I will investigate this one after fixing that issue to be sure it's not in the way.

See Also: → 1542827
Attachment #9059991 - Attachment is obsolete: true

Comment 7

21 days ago

Hi Anthony, is this going to be fixed for 68?

Flags: needinfo?(ajones)

(In reply to Patricia Lawless from comment #7)

Hi Anthony, is this going to be fixed for 68?

Eric?

Flags: needinfo?(ajones) → needinfo?(erahm)

Bug 1542827 is fixed but I haven't had time to look into this yet. xpcshell & mochitests dealing with crashes aren't working yet and I've been focusing on those so I won't be able to look into this until I'm done with them.

Flags: needinfo?(erahm)
Comment hidden (Intermittent Failures Robot)

Hi Gabriele, will you be working on this? Also, what's the priority on this one? Thanks!

Flags: needinfo?(gsvelto)

Not working on this currently but I'm refactoring the code affected by this so it might have an impact here.

Flags: needinfo?(gsvelto)

Just another note: while this code should not crash it's odd CrashReporter::CreateMinidumpsAndPair() is getting called here. It should happen only in the case of a content process hang and I don't think we should have hang detection enabled in tests. I haven't checked though so it might just be enabled.

You need to log in before you can comment on or make changes to this bug.