Closed
Bug 573631
Opened 14 years ago
Closed 13 years ago
trace malloc for x86_64 Mac OS X builds is too slow
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: jaas, Unassigned)
References
Details
Attachments
(3 files)
I believe the cause for bug 558496 is that trace malloc runs incredibly slowly on x86_64 Mac OS X builds. The slowdown appears to be worse than 10x, possibly 20x or so, leading to the 3600 second timeout. I can reproduce this behavior locally on a Mac Pro, and the problem goes away on my machine and the Mac Mini build slave if I run tests without trace malloc.
This sample was taken during app startup and as expected, 'findClosestSymbol' dominates.
This sample was taken during the first network load, after: localhost - - [21/Jun/2010 20:01:08] "GET /bloatcycle.html HTTP/1.1" 200 -
Is findClosestSymbol called from within dladdr?
So one possibility here is that the calltree locking is much too fine-grained; I think I've been concerned about that in the past.
(In reply to comment #4) > Is findClosestSymbol called from within dladdr? Yes: dyld ImageLoaderMachOCompressed::findClosestSymbol(void const*, void const**) const dyld dladdr XUL NS_DescribeCodeAddress
Comment 7•13 years ago
|
||
Anyone that can be working on this? We are trying to move the 10.5 leak builds to be run on 10.6 minis in bug 674647 and we are hitting this problem.
Blocks: 674647
I think this was fixed with bug 696281. Can someone check?
Comment 9•13 years ago
|
||
We seemed to have fixed the slowness (few good runs showed only 1 minute on running alive_tests2) but we have resuscitated bug 558496.
This was fixed in https://hg.mozilla.org/mozilla-central/rev/c9a74f4ee1f7
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•