More aggressive symbol stripping for releases



16 years ago
16 years ago


(Reporter: bryner, Assigned: bryner)





16 years ago
Ok, so we're only using 'strip -S' during Camino packaging to remove debugging
symbols.  We can get a substantial size win if we're more aggressive:

-rwxr-xr-x  1 cltbld  admin  14164960 Mar  8 10:58 Camino
-rwxr-xr-x  1 cltbld  admin  10391492 Mar  9 03:16 Camino.stripped

We can strip the executable with just 'strip'; we can strip the shared libraries
with 'strip -x' to remove all non-global symbols.  This shouldn't affect
Talkback data.

The tradeoff is that Crash Reporter logs for release builds will no longer be
particularly useful.  Just for comparison, here's what that translates to for
download size:

-rw-r--r--  1 cltbld  admin  7947604 Mar  8 10:59 Camino.dmg.gz
-rw-r--r--  1 cltbld  admin  6972127 Mar  9 03:25 Camino-stripped.dmg.gz

Is this something we want to do?

Comment 1

16 years ago
JJ: This is also relevant for SeaMonkey builds.  On platforms where installers
and xpi's are created, the packaging script strips everything.  So, right now,
Mac is the only platform _not_ doing stripping for SeaMonkey builds.

Comment 2

16 years ago
Just to confirm that there's no impact on talkback reports, I generated a test
build using these stripping options, which is at:

I crashed it using the testcase on bug 196012, and generated the talkback report
which has a complete stack trace.  The Crash Reporter log has only hexadecimal
addresses (no function names), as I'd expect.

Comment 3

16 years ago
I think we'd only wan to do this for 1.0. I want Crash Reporter logs to remain
useful in all builds until then.

Comment 4

16 years ago
Simon: how about seamonkey? can we strip everything in nightly trunk mozilla /
buffy builds or do you think it should be done for release candidate builds only
(just like we were doing with the traceback option in IDE_Options.h for cfm) ?

Comment 5

16 years ago
I'm inclined to say the same thing for SeaMonkey. Only do the aggressive
stripping for milestones.
1) if we have talkback, i see no need for crashreport logs to work. this was a
huge deal before, but not now.
2) a 1MB decrease in d/l size helps out the people that pull nightlies and give
us feedback
3) we've already got a huge list of things to do when we push a milestone, let's
not add one more thing to forget and force a respin.

I'd say we should do this on nightlies.

Comment 7

16 years ago
Personally, I'm going to be unhappy if I'm running a release build, and it
crashes, but I can't see a stack trace without logging onto sera, and waiting
several minutes for the talkback server to respond.

I think we also have a good proportion of users who are savvy enough to be able
to eyeball a crash log and go "Yeah, that's this crash, I don't need to go and
file a bug on it." Take away the stack, and we're going to get far more "it
crashes" bugs without any stack data.

Comment 8

16 years ago
Ok, if you really think the crash reporter logs are that useful to testers, we
can do this only for releases.  I'll add a flag to the Camino build script on
the build machine.
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 9

16 years ago
... and I'll do the same for seamonkey.

However, we need to make sure to flip the switch early on branch builds (rather
than on final candidates) so that we all have a chance (QA in particular) to
pound on these bits that will be somewhat different than nightlies where only
"strip -S" was applied, in case they introduce new issues.
We should also have a "reminder" bug to make sure this is done for every release

Comment 10

16 years ago
no way.  we are not doing nightly seamonkey builds that are different from what
we ship for milestones.  not gonna happen.  I don't care about space savings or
stack traces, it's not worth the risk, even if it's minimal risk, to change what
we're shipping on a branch and then have the branch fall apart because something
breaks because we haven't been testing it the last 3 months.  This is especially
true with the way the branch always gets abandoned (happened for 1.2, happened
again for 1.3, probably happen again for 1.4, exactly what we cannot have happen).

You can make an option so engineers can have symbols if they want or not, but
the official builds coming out of Netscape, be then mozilla builds or Netscape
builds, are going to be the same builds we ship for milestones.  I don't care if
that's with strong stripping or weak stripping, but they're going to be the same
stripping whatever it is.

Comment 11

16 years ago
So why did we turn off symbols for CFM builds before each milestone?
You need to log in before you can comment on or make changes to this bug.