| Summary: | REGRESSION (r105942): Nightly build's jsc doesn't work without DYLD_FRAMEWORK_PATH | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Julian Gonggrijp <j.gonggrijp> | ||||||||
| Component: | JavaScriptCore | Assignee: | Mark Rowe (bdash) <mrowe> | ||||||||
| Status: | REOPENED --- | ||||||||||
| Severity: | Normal | CC: | ap, barraclough, commit-queue, mhahnenberg, mrowe, rniwa, stevengriffin117, wingo | ||||||||
| Priority: | P2 | ||||||||||
| Version: | 528+ (Nightly build) | ||||||||||
| Hardware: | Mac (Intel) | ||||||||||
| OS: | OS X 10.6 | ||||||||||
| Bug Depends on: | 116186 | ||||||||||
| Bug Blocks: | |||||||||||
| Attachments: |
|
||||||||||
Created attachment 127893 [details] minimal script that can be used to produce a jsc crash on r108257 It really doesn't matter what's in the file, this is just meant to save the dev a little effort. This is expected - you are running nightly jsc with shipping JavaScriptCore framework. You should either use jsc from /System/Library/Frameworks, or use DYLD_FRAMEWORK_PATH environment variable to use frameworks from nightlies (man dyld for more info). I understand that I was running the jsc from the nightly JavaScriptCore, that was exactly my intention. Does this mean that I've been unknowingly running nightly jsc with components from /System/Library/Frameworks all the time, and it worked because the dependencies of the nightly happened to match the frameworks in the System folder? Anyway, I've got it to work with the DYLD_FRAMEWORK_PATH variable as you pointed out and it works again. Thank you. Actually, no, something changed in the build process - jsc used to pick up nightly build's version of JavaScriptCore automatically, and it no longer does. I don't know if it's intentional. CC'ing some people whom might know. Old nightly: $ otool -L /Volumes/WebKit/WebKit.app/Contents/Frameworks/10.6/JavaScriptCore.framework/Versions/A/Resources/jsc /Volumes/WebKit/WebKit.app/Contents/Frameworks/10.6/JavaScriptCore.framework/Versions/A/Resources/jsc: @loader_path/../JavaScriptCore (compatibility version 1.0.0, current version 535.15.0) /usr/lib/libedit.2.dylib (compatibility version 2.0.0, current version 2.11.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11) New nightly: $ otool -L /Volumes/WebKit/WebKit.app/Contents/Frameworks/10.6/JavaScriptCore.framework/Versions/A/Resources/jsc /Volumes/WebKit/WebKit.app/Contents/Frameworks/10.6/JavaScriptCore.framework/Versions/A/Resources/jsc: /System/Library/Frameworks/JavaScriptCore.framework/Versions/A/JavaScriptCore (compatibility version 1.0.0, current version 535.22.0) /usr/lib/libedit.2.dylib (compatibility version 2.0.0, current version 2.11.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11) (In reply to comment #4) > > $ otool -L /Volumes/WebKit/WebKit.app/Contents/Frameworks/10.6/JavaScriptCore.framework/Versions/A/Resources/jsc You need an OS X build expert here; I'm afraid I'm ignorant on this one. If you can figure out when this behavior started, it should be easy to identify the change. Mark would know if this is an intentional consequence of r105942 or not. Yeah, this is my fault. Created attachment 148660 [details]
Patch: Fixes the "Copy Into Framework" target
Find attached a patch to fix up this bug.
The patch changes when the dependencies of the jsc binary are modified. Instead of tweaking the jsc binary after it's been copied to the destination directory, it's modified before. Thus, both copies work as expected.
The rest of the process remains being the same.
As described in <http://www.webkit.org/coding/contributing.html>, please set r? flag if this is ready for review, not just cq?. Comment on attachment 148660 [details] Patch: Fixes the "Copy Into Framework" target Clearing flags on attachment: 148660 Committed r150051: <http://trac.webkit.org/changeset/150051> All reviewed patches have been landed. Closing bug. This patch made all JSC tests to fail on Mac: http://build.webkit.org/builders/Apple%20MountainLion%20Release%20WK1%20%28Tests%29/builds/9944 http://build.webkit.org/builders/Apple%20MountainLion%20Release%20WK1%20%28Tests%29/builds/994 5 Expected exit code 0, got 133 Testcase terminated with signal 0 Complete testcase output was: dyld: Library not loaded: @loader_path/../JavaScriptCore Referenced from: /Volumes/Data/slave/mountainlion-release-tests-wk1/build/WebKitBuild/Release/jsc Reason: image not found Re-opened since this is blocked by bug 116186 |
Created attachment 127892 [details] Crash log from attempt to run a script with jsc I've been running plain ECMAScript files from the terminal with the jsc executable inside the Frameworks folder from the WebKit application bundle. This worked at least up to revision 105028. However in revision 108257 and the nightly build directly before that, jsc will crash before any ECMAScript code is executed. This is how I run a script: /Applications/WebKit.app/Contents/Frameworks/10.6/JavaScriptCore.framework/Versions/Current/Resources/jsc pass.js (see the attached pass.js for a minimal script that is ready to use). The following message is printed to stderr on crash. dyld: Symbol not found: __ZN3JSC14JSGlobalObject13visitChildrenEPNS_6JSCellERNS_11SlotVisitorE Referenced from: /Applications/WebKit.app/Contents/Frameworks/10.6/JavaScriptCore.framework/Versions/Current/Resources/jsc Expected in: /System/Library/Frameworks/JavaScriptCore.framework/Versions/A/JavaScriptCore in /Applications/WebKit.app/Contents/Frameworks/10.6/JavaScriptCore.framework/Versions/Current/Resources/jsc Trace/BPT trap The full crash report is attached.