Closed Bug 448003 Opened 14 years ago Closed 14 years ago

Z/mZ values are off by 100 on OS X

Categories

(MailNews Core :: Build Config, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: davida, Assigned: gozer)

Details

Attachments

(2 files)

According to the tinderbox page as of right now, Z for OS X is Z:1.56GB, which is a tad high, and about 100x what it is on Linux.
Hrm, just stole verbatim the stuff from SeaMonkey, does it also look 100x what it should be, sure looks like it to me:

From SeaMonkey's tinderbox tree:

"Linux comm-central build" Z:17.2MB
"MacOSX 10.4 comm-central build" Z:2.27GB
I've a feeling its calculating it off the wrong directory/data, i.e. including all object files or something. I just haven't worked out where its doing that, or where we need to poke it.
I think I've found what the source of the excessive bloat is. Looking at codesize-base.log, I noticed a symbol that is reported as taking *lots* of space:
$> grep -E 'trampoline_size' codesize-base.log
21ffffd8        DATA    STATIC  libplc4.dylib   A       UNDEF:libplc4.dylib:A   trampoline_size
20ffffd8        DATA    STATIC  libplds4.dylib  A       UNDEF:libplds4.dylib:A  trampoline_size
1fffffd8        DATA    STATIC  libnspr4.dylib  A       UNDEF:libnspr4.dylib:A  trampoline_size

$> perl -le'print 0x21ffffd8 + 0x20ffffd8 + 0x1fffffd8'
1660944264

That's a whopping 1.66Gb!

On top of that, trampoline_size is the only symbol marked as A (absolute address) and isn't coming from mozilla code, but is something introduced by OSX/gcc, apparently on 10.4 and not 10.5

A possible solution is to teach nm_wrap_osx.pl how to skip over such symbols, since we can't figure out their sizes anyways. Plus, looks like trampoline_size is the only one at this time, and it only appears in 3 different libraries.
Attachment #332894 - Flags: review?(ted.mielczarek)
Comment on attachment 332894 [details] [diff] [review]
Teach nm_wrap_osx.pl to skip over absolutely addressed symbols

Seems reasonable.
Attachment #332894 - Flags: review?(ted.mielczarek) → review+
Checked in Changeset id 16554:4312421f534b
Symbol types are upper or lower case depending on their visibility. Upper-case is public, lower-case is private. In our case, we should match on either, so match case-insensitively.
Attachment #333230 - Flags: review?(ted.mielczarek)
Attachment #333230 - Flags: review?(ted.mielczarek) → review+
(In reply to comment #6)
> Created an attachment (id=333230) [details]
> Symbol types should be matched case-insensitive

Checked in changeset id 16576:0178bad8d3fe
As it seems to have solved SeaMonkey's problem too, I think this is now the correect fix.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Product: Thunderbird → MailNews Core
QA Contact: build-config → build-config
You need to log in before you can comment on or make changes to this bug.