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?
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.
Just to confirm that there's no impact on talkback reports, I generated a test build using these stripping options, which is at: ftp://ftp.mozilla.org/pub/camino/nightly/2003-03-09-19/Camino.dmg.gz I crashed it using the testcase on bug 196012, and generated the talkback report at http://heatwave.mcom.com/reports/singleincidentinfo.cfm?dynamicBBID=192077 which has a complete stack trace. The Crash Reporter log has only hexadecimal addresses (no function names), as I'd expect.
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.
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) ?
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.
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.
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.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
... 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
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.
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.