381513 - want program-database files ('.pdb's) for xulrunner builds

Status: RESOLVED INCOMPLETE

(Firefox Build System :: General, enhancement)

Description

[James Schneider]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: XULRunner 1.9a5pre nightly cerca 13 May 07

XULRunner application developers might choose to use a nightly (as there are no releases) of 1.9 or a stock 1.8.0.x/1.8.x xulrunner distribution.  If such developers are also using internal installations of breakpad/socorro, they would benefit from having the program-database files for the xulrunner (and its dlls) that they have chosen.

This does not mean that mozilla developers necessarily have to deal with random stack traces produced by various third-party xulrunner applications.  PDBs could be made available primarily to benefit third-party xulrunner application developers.

Naturally, xulrunner application developers should be comfortable building their own xulrunner.  But (because only fairly shallow automation is required to create and zip-up the symbol files) making symbols available for 'stock' builds is beneficial for a variety of related reason.

Primarily, xulrunner application developers don't _need_ to build their own xulrunner if satisfactory distributions are available on the ftp (preventing replication of work).  Also, if xulrunner application developers uncover a problem with xulrunner (having already ruled-out application-specific code), mozilla developers could categorize their error/bug reports against specific builds.  Along those lines, mozilla developers could setup tooling to interpret minidumps from crashes from external apps.

Anyway, this rationale convinced Ted, who told me to create this bug....

We sort of agreed that a zip that could be extracted over-top of the UUID-classifed pdb/map file directory for an existing socorro installation (that may already have symbols installed for other xulrunners and 3rd-party c++ xpc components) would require a minimum amount of work to add to the build process and to add to third-party socorro installations.

Reproducible: Always

Steps to Reproduce:
not applicable
Actual Results:  
not applicable

Expected Results:  
not applicable

not applicable

Comment 1

[(not currently active) Ted Mielczarek]

We can get most of this using the $crashreporter_buildsymbols setting in Tinderbox, since that will give us a zip of the symbols dir.  What we might want to do is add yet-another-tinderbox-setting that would let us publish the symbols zip to FTP instead of uploading it to the symbol server.

Comment 2

[Benjamin Smedberg]

s/instead of/in addition to/ ;-)

Comment 3

[(not currently active) Ted Mielczarek]

I've got some related cleanup I want to do anyway.

Comment 4

[timeless]

what's wrong with just (publishing and) using the symbol server?

Comment 5

[(not currently active) Ted Mielczarek]

(In reply to comment #4)
> what's wrong with just (publishing and) using the symbol server?

That makes it more difficult to get the symbols for running a Socorro server.  For XULRunner app authors, an archive of the symbols would be preferable.  We do intend to make the symbol server accessible via HTTP for Windows debugging, at least for Firefox, see bug 376322.

Comment 6

[(not currently active) Ted Mielczarek]

bug 478221 made it so if you run "make buildsymbols", the symbol package will get uploaded when you run "make upload". However, the post_upload.py script that puts files into the right places doesn't copy the symbols for nightly/release builds (to save disk space). We could probably tweak it so for xulrunner nightly/release builds it copies them, and you could just download them.

Comment 7

[Chris Cooper [:coop] (he/him)]

Mass bug cleanup for Core:Build Config.

If you feel this bug has been closed in error, please re-open with new details.