Closed
Bug 551392
Opened 14 years ago
Closed 14 years ago
Spurious subprocess crashes can be detected
Categories
(Core :: IPC, defect)
Core
IPC
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)
5.63 KB,
patch
|
ted
:
review+
|
Details | Diff | Splinter Review |
7.25 KB,
patch
|
ted
:
review+
|
Details | Diff | Splinter Review |
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?
Assignee | ||
Comment 1•14 years ago
|
||
Assignee: nobody → jones.chris.g
Attachment #431563 -
Flags: review?(ted.mielczarek)
Comment 2•14 years ago
|
||
Sounds good, yes. (Will review later.)
Assignee | ||
Comment 4•14 years ago
|
||
Sort of off-topic for this bug, but I'd like to get this in anyway.
Attachment #432078 -
Flags: review?(ted.mielczarek)
Assignee | ||
Comment 5•14 years ago
|
||
Missed a spot
Attachment #432078 -
Attachment is obsolete: true
Attachment #432080 -
Flags: review?(ted.mielczarek)
Attachment #432078 -
Flags: review?(ted.mielczarek)
Assignee | ||
Comment 6•14 years ago
|
||
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)
Updated•14 years ago
|
Attachment #431563 -
Flags: review?(ted.mielczarek) → review+
Comment 7•14 years ago
|
||
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+
Assignee | ||
Comment 8•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/dd36815ae7bb http://hg.mozilla.org/mozilla-central/rev/bda8efa53512
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 9•14 years ago
|
||
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 → ---
Comment 10•14 years ago
|
||
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?
Assignee | ||
Comment 11•14 years ago
|
||
Yeah, the important part stuck. "Followup" (independent actually) is bug 554682.
Assignee | ||
Updated•14 years ago
|
Whiteboard: [land-lorentz]
Assignee | ||
Updated•14 years ago
|
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Updated•14 years ago
|
Whiteboard: [land-lorentz] → [fixed-lorentz]
Comment 12•14 years ago
|
||
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
Comment 13•14 years ago
|
||
Merged into 1.9.2 at http://hg.mozilla.org/releases/mozilla-1.9.2/rev/84ba4d805430
status1.9.2:
--- → .4-fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•