New crash-reporting implementation for win32 (tracking)

RESOLVED DUPLICATE of bug 354980

Status

RESOLVED DUPLICATE of bug 354980
13 years ago
9 years ago

People

(Reporter: mark, Assigned: jay)

Tracking

Trunk
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
Forking from bug 216827, where there's some additional info.  This is not Talkback, but Core.Talkback is the closest component in this Bugzilla.

I'm working on a new crash-reporting system.  Task One is doing win32 dumps and then turning them into useful stacks on non-win32 systems.
(Reporter)

Comment 1

13 years ago
I'm using the minidump format for win32.  A major benefit of this is that it enables developers to use the dumps in a traditional debugging environment, as long as they are allowed access to the pdb files (comment 29).  Where MiniDumpWriteDump is not available (pre-XP), I'll write the stack dump in minidump format myself.  (dbghelp.dll is redistributable, but it's 600k/200k compressed, so I won't be going that way.)

Comment 2

13 years ago
Do you have a specification of the minidump files?
(Reporter)

Comment 3

13 years ago
Yes, it's well-specified in dbghelp.h and much of it is documented on MSDN.  Some additional structures it uses are specified in other platform SDK headers, like winnt.h.

Comment 5

13 years ago
comment 29 mentioned before is Bug 216827 Comment 29
Nice ideas making "talkback" work independently of build ID, i.e. even working when some DLLs are from other builds, and plugin vendors could debug their plug-ins. But it seems to me the BuildID still is important for finding when a regression started.

Comment 6

13 years ago
the server would record/know what build introduced a given pdb file. that's a server detail, not a client detail. ideally it'd even be able to try to give bonsai hints about build dates so that bonsai could pick the right cvs rev (note: i'm volunteering to work on the bonsai part of that).

the server ui could of course warn if it sees components from mixed builds, and should probably list the build id for the exe and any components that don't match it, but again, this is very much a server detail and shouldn't be something the client really bothers encoding.

Comment 7

12 years ago
oh, one very important reminder:
though shalt not call the minidumpwritedump function from within the crashed process, it's a very big no no.

Comment 8

12 years ago
Since actual work is now happening in the airbag project ( http://code.google.com/p/airbag/ ), and there is already bug 216827, shouldn't we close this bug as WONFIX (will use the solution in airbag, not develop one in mozilla) ?
(Reporter)

Comment 9

12 years ago
Comment 8: it's the same solution.  Sort of.

Mozilla will still need client-side and server-side work wrapping airbag.  (See the messages on airbag-discuss.)  I'm leaving this bug open so it can morph to track that work if desired, but reassigning away from myself as I'll be primarily focused on the airbag library, whose work is being tracked at the URL you posted.
Assignee: mark → jay
Mark's working on airbag and I have a patch for our side of things.


*** This bug has been marked as a duplicate of 354980 ***
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE

Updated

9 years ago
Component: Talkback Client → Talkback Client
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.