Closed Bug 551392 Opened 11 years ago Closed 11 years ago

Spurious subprocess crashes can be detected

Categories

(Core :: IPC, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
status1.9.2 --- .4-fixed

People

(Reporter: cjones, Assigned: cjones)

References

Details

(Whiteboard: [fixed-lorentz])

Attachments

(2 files, 2 obsolete files)

nsExceptionHandler keeps a map of minidumps gathered from subprocesses, but we never remove entries from the map.  That means that if the browser is unlucky and a later subprocess is assigned the same PID/HANDLE as an earlier one that crashed, we might report that later one crashed as well.

I think a better API than CrashReporter::GetMinidumpForChild() is something like CrashReporter::TakeMinidumpForChild() that removes the child's dump from the map if it exists.

Ted, does that suit you?
Sounds good, yes. (Will review later.)
Lower priority, doesn't block beta.
Blocks: OOPP
No longer blocks: LorentzBeta1
Sort of off-topic for this bug, but I'd like to get this in anyway.
Attachment #432078 - Flags: review?(ted.mielczarek)
Missed a spot
Attachment #432078 - Attachment is obsolete: true
Attachment #432080 - Flags: review?(ted.mielczarek)
Attachment #432078 - Flags: review?(ted.mielczarek)
Needed some fixups on windows because of HANDLE.
Attachment #432080 - Attachment is obsolete: true
Attachment #432284 - Flags: review?(ted.mielczarek)
Attachment #432080 - Flags: review?(ted.mielczarek)
Attachment #431563 - Flags: review?(ted.mielczarek) → review+
Comment on attachment 432284 [details] [diff] [review]
Remove hack made unnecessary by unified build tiers, v3

This is good, but you're going to need to #ifdef MOZ_CRASHREPORTER around the #include and the call in ActorDestroy.

r=me with that fixed.
Attachment #432284 - Flags: review?(ted.mielczarek) → review+
I suspect the second patch may have caused http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1268960226.1268962345.4351.gz .
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
http://hg.mozilla.org/projects/firefox-lorentz/rev/7b4edfb90d75

Not sure what's up with this bug. The first patch stuck, right? Can we mark this FIXED for branch-tracking purposes and file a followup if necessary for whatever remains?
Yeah, the important part stuck.  "Followup" (independent actually) is bug 554682.
Whiteboard: [land-lorentz]
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Whiteboard: [land-lorentz] → [fixed-lorentz]
Blanket approval for Lorentz merge to mozilla-1.9.2
a=beltzner for 1.9.2.4 - please make sure to mark status1.9.2:.4-fixed
You need to log in before you can comment on or make changes to this bug.