Closed Bug 723301 Opened 12 years ago Closed 12 years ago

Figure out shark builds for building on 10.7

Categories

(Release Engineering :: General, defect, P3)

Product:
Release Engineering
Component:
General
Platform:
x86
macOS
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: jhford, Unassigned)

References

Details

(Whiteboard: [shark][lion][bear][crocodile]) 

We produce Shark builds currently on 10.6.  Once we move to 10.7 builders, I am unsure what will happen.  My understanding is that CHUD is a requirement for shark builds and that CHUD is not compatible with 10.7.  This is supported by the failure I get during packaging[1].

My Questions are:

1) Do we need to continue producing shark builds?

2) Can we install the latest version of CHUD on lion without breaking lion


[1]
/builds/slave/m-cen-osxlion-shark/build/obj-firefox/i386/config/nsinstall -D ../../dist/
Compressing...
cd ../../dist && (cd universal/firefox/Nightly.app/Contents/MacOS && rm -f omni.ja components/binary.manifest && grep -h '^binary-component' components/*.manifest > binary.manifest ; for m in components/*.manifest; do sed -e 's/^binary-component/#binary-component/' $m > tmp.manifest && mv tmp.manifest $m; done; /usr/bin/zip -r9m omni.ja chrome chrome.manifest components/*.js components/*.xpt components/*.manifest modules res defaults greprefs.js jsloader hyphenation update.locale  -x chrome/icons/\* defaults/pref/channel-prefs.js res/cursors/\* res/MainMenu.nib/\*  && /builds/slave/m-cen-osxlion-shark/build/obj-firefox/i386/dist/bin/run-mozilla.sh /builds/slave/m-cen-osxlion-shark/build/obj-firefox/i386/dist/bin/xpcshell -g "$PWD" -a "$PWD" -f /builds/slave/m-cen-osxlion-shark/build/toolkit/mozapps/installer/precompile_cache.js -e "populate_startupcache('GreD', 'omni.ja', 'startupCache.zip');" && rm -rf jsloader && /usr/bin/unzip startupCache.zip && rm startupCache.zip && /usr/bin/zip -r9m omni.ja jsloader/resource/gre && /tools/buildbot/bin/python2.7 /builds/slave/m-cen-osxlion-shark/build/config/optimizejars.py --optimize /builds/slave/m-cen-osxlion-shark/build/obj-firefox/i386/browser/installer/../../jarlog//en-US ./ ./ && mv binary.manifest components && printf "manifest components/binary.manifest\n" > chrome.manifest) && (cd universal/firefox/Nightly.app/Contents/MacOS && /tools/buildbot/bin/python2.7 /builds/slave/m-cen-osxlion-shark/build/config/createprecomplete.py) && /builds/slave/m-cen-osxlion-shark/build/build/package/mac_osx/pkg-dmg --source "universal/firefox" --target "firefox-13.0a1.en-US.mac-shark.dmg" --volname "Nightly"  --copy "branding/dsstore:/.DS_Store" --mkdir /.background --copy "branding/background.png:/.background" --icon "branding/disk.icns" --symlink "/Applications:/ "
	zip warning: name not matched: jsloader
  adding: chrome/ (stored 0%)
  adding: chrome/browser/ (stored 0%)
  adding: chrome/browser/content/ (stored 0%)
  adding: chrome/browser/content/branding/ (stored 0%)
<snip>
  adding: hyphenation/hyph_sv.dic (deflated 51%)
  adding: hyphenation/hyph_tr.dic (deflated 64%)
  adding: hyphenation/hyph_uk.dic (deflated 70%)
  adding: update.locale (stored 0%)
dyld: Library not loaded: /System/Library/PrivateFrameworks/CHUD.framework/Versions/A/CHUD
  Referenced from: /builds/slave/m-cen-osxlion-shark/build/obj-firefox/i386/dist/bin/xpcshell
  Reason: image not found
/bin/sh: line 1: 42542 Trace/BPT trap: 5       /builds/slave/m-cen-osxlion-shark/build/obj-firefox/i386/dist/bin/run-mozilla.sh /builds/slave/m-cen-osxlion-shark/build/obj-firefox/i386/dist/bin/xpcshell -g "$PWD" -a "$PWD" -f /builds/slave/m-cen-osxlion-shark/build/toolkit/mozapps/installer/precompile_cache.js -e "populate_startupcache('GreD', 'omni.ja', 'startupCache.zip');"
make[2]: *** [make-package] Error 133
make[1]: *** [default] Error 2
make: *** [package] Error 2
Blocks: 720027
Pretty sure this should be re-assigned to a dev, unless we actually decide to stop making shark builds. 

jhford: can you track down who would be on the hook for making that decision, please?
Priority: -- → P3
Whiteboard: [shark][lion][bear][crocodile]
I think it is probably fine to stop producing Shark builds for some period of time, but we should follow up soon and attempt to get them going again.

CC'd some people who might disagree with my assessment.
We can switch from --enable-shark to --enable-profiling for a bit, though that would make profiling with those builds a lot more of a pain....
I have everything I need from the profiling branch, thus don't need any special m-c builds.
I assume that this bug is in fact about the profiling branch, since m-c doesn't build shark builds at all.
m-c (and some other branches) does build shark, eg
 http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/firefox-12.0a1.en-US.mac-shark.dmg
but there has been talk of deprecating them in favour of the mac builds from the new profiling branch.
I have no need for them, I've only heard of Boris using them but there may be others. I believe they are for only for Js Profiling since c++ profiling can be done with profiling builds: https://developer.mozilla.org/en/Profiling_JavaScript_with_Shark. If we keep them we should probably restrict them to building for fewer well defined check-ins since shark builds are for a very specific use case (JS Profiling). 

I think that if bug 698580 works well it may even make shark builds obsolete.
I use them primarily for C++ profiling; the main thing the shark builds give me is programmatic control for when the profiler starts and stops.

> I think that if bug 698580 works well it may even make shark builds obsolete.

I don't see how.  Again, the main goal is to have a way of starting a profiler, then doing some work, then stopping the profiler, all programmatically.  This is completely orthogonal to profiler features.
(In reply to Boris Zbarsky (:bz) from comment #9)
> I use them primarily for C++ profiling; the main thing the shark builds give
> me is programmatic control for when the profiler starts and stops.
> 
> > I think that if bug 698580 works well it may even make shark builds obsolete.
> 
> I don't see how.  Again, the main goal is to have a way of starting a
> profiler, then doing some work, then stopping the profiler, all
> programmatically.  This is completely orthogonal to profiler features.

Cool, you should be able to achieve this with tools/profiler/nsIProfiler.h StartProfiler/StopProfiler with profiling builds but we're still missing features before we can effectively replace shark. Once that happens it should give us more options for non mac platforms.
Blocks: 744481
> Once that happens it should give us more options for non mac platforms.

I have bug 741652 for making programmatic start/stop work on Linux with perf.  We're basically there, modulo some annoying bugs in perf.
According to this forum post: http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=301024, CHUD/Shark has been replaced by Instruments, which is included with part of the default XCode install. Shouldn't be switching to that, instead? It doesn't sound like Shark support is possible in Lion.
Except Instruments does not have an API for programatically starting / stopping the profiler.  That's a killer feature.
(In reply to Nick Thomas [:nthomas] from comment #7)
> m-c (and some other branches) does build shark, eg
>  http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-
> central/firefox-12.0a1.en-US.mac-shark.dmg
> but there has been talk of deprecating them in favour of the mac builds from
> the new profiling branch.

I think there are zero reasons to build mozilla-central with --enable-shark, since the lack of the frame pointer would make profiling harder than necessary.  People who want Shark builds should use the profiling branch (no matter what the solution for building --enable-shark on 10.7 turns out to be.)
Is it an option to dynamically load those shark APIs for starting/stopping the profiler using dlsym or something?  That way we can remove the compile time dependency on the CHUD headers/libs.
Peter has been working on programmatic start/stop for Instruments on 10.7.
(In reply to Boris Zbarsky (:bz) from comment #16)
> Peter has been working on programmatic start/stop for Instruments on 10.7.

cool!  am I correct that this would obviate the need for shark?
The stuff Peter is working on _requires_ 10.7, as I understand.  It doesn't work on 10.6.

So if we want to support sane profiling on 10.6, we need the shark code in the tree.

Whether it needs to be built on _tinderbox_ is a separate question.  We could simply require that people who want to profile seriously on 10.6 compile on 10.6 (with the shark stuff) themselves....
(In reply to Boris Zbarsky (:bz) from comment #18)
> Whether it needs to be built on _tinderbox_ is a separate question.  We
> could simply require that people who want to profile seriously on 10.6
> compile on 10.6 (with the shark stuff) themselves....

Yeah, I think it's fine if we do that for 10.6.

It would be awesome to get a bug number for Peter's work as well.
I'm not sure there's a bug number for it yet.
(In reply to Ehsan Akhgari [:ehsan] from comment #19)
> It would be awesome to get a bug number for Peter's work as well.

Bug 748669.

I'm pretty sure we can continue to do shark builds, afaict we don't rely on the CHUD library but there are some obsolete references to it remaining in makefiles. I removed them in my patch in bug 748669, and I build with --enable-shark and --enable-instruments on OS X 10.7. I haven't been able to try the builds on 10.6 yet, but I don't see why they wouldn't work.
Resolving in favor of Bug 748669.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.