Closed Bug 558094 Opened 12 years ago Closed 9 years ago

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

Categories

(Core :: JavaScript Engine, defect)

x86_64
macOS
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: bear, Unassigned)

References

Details

Attachments

(1 file)

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
Blocks: 557715
Blocks: support-10.6_x64
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
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...
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!
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.
resolving as INCOMPLETE because these bugs are most likely not even being worked on or known about anymore
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.