Shark build failing on new OSX Snow Leopard build slaves due to CHUD issues

RESOLVED INCOMPLETE

Status

()

RESOLVED INCOMPLETE
9 years ago
6 years ago

People

(Reporter: bear, Unassigned)

Tracking

Trunk
x86_64
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
In a bug 557715 comment https://bugzilla.mozilla.org/show_bug.cgi?id=557715#c8 Ted shows that the issue is due to missing the CHUD framework.

But according to http://lists.apple.com/archives/perfoptimization-dev/2009/Sep/msg00071.html the CHUD framework doesn't exists like it did previously and it outlines changes needed for Snow Leopard.

We have disabled Shark testing for the moment
(Reporter)

Comment 1

9 years ago
Created attachment 437870 [details]
log section showing shark failure
(Reporter)

Updated

9 years ago
Blocks: 557715
(Reporter)

Updated

9 years ago
Blocks: 519060
No longer blocks: 557715
I feel like I've seen this discussion before, but I don't remember if there's already a bug filed.
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general

Comment 3

8 years ago
According to the linked thread, there is no way to use the CHUD functions on snow leopard, which basically seems to imply that there is no effective way to implement the .connectShark/.startShark/.stopShark APIs when building on that platform.
You can try to find the shark PID and send it signals...

Comment 5

8 years ago
CHUD works for me on snow leopard, but only for 32-bit apps. Apple doesn't seem to be moving towards porting it, and sending signals to shark doesn't offer the same functionality, sadly.
I think the short-term fix here is just to disable Shark builds for 10.6. We're shipping nightly builds with symbols unstripped currently, so you can use Shark on them for profiling, you just don't get access to the startShark() / stopShark() JS APIs.
For my future reference, when I end up on 10.6, this works:

  sharkPid = popen("ps cx | grep shark | cut -f 1 -d ' '", "r");
  fscanf(sharkPid, "%d", &pid);
  pclose(sharkPid);
  kill(pid, SIGUSR1);
  // profile here
  kill(pid, SIGUSR2);

at least if shark is launched with -a firefox_pid.

Will need some workflow changes, but that's ok.

Ted, not having access to the start/stop APIs makes profiling tasks that taje on the order of tens of milliseconds (pretty common for me recently) impossible.  It makes profiling tasks that take on the order of a second (e.g. the dromaeo tests) pretty damn hard.
To be clear, I'll likely make the start/stop stuff on 10.6 do something like comment 7 sometime late this summer, if I end up with a new computer that has 10.6 on it by that point.  If someone wants to do that before that, please do!
(Reporter)

Comment 9

8 years ago
Shark builds have been disabled and enable-shark set to false for recent builds.

I would like to close this bug as resolved with the understanding that a new bug will be created when Shark builds need to be turned back on.

cool?
I filed bug 595748 on making this compile option work on 10.6.
(Reporter)

Comment 11

6 years ago
resolving as INCOMPLETE because these bugs are most likely not even being worked on or known about anymore
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.