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.
Created attachment 452906 [details] sample 1, app startup This sample was taken during app startup and as expected, 'findClosestSymbol' dominates.
Created attachment 452908 [details] sample 2, network load This sample was taken during the first network load, after: localhost - - [21/Jun/2010 20:01:08] "GET /bloatcycle.html HTTP/1.1" 200 -
Created attachment 452913 [details] sample 2, network load, expanded Same as sample 2 but with the stack expanded.
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
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.
I think this was fixed with bug 696281. Can someone check?
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