Bug 79065 – REGRESSION (r105942): Nightly build's jsc doesn't work without DYLD_FRAMEWORK_PATH

• Component: JavaScriptCore
• Status: REOPENED

[Julian Gonggrijp]

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.

[Julian Gonggrijp]

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.

[Alexey Proskuryakov]

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).

[Julian Gonggrijp]

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.

[Alexey Proskuryakov]

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)

[Andy Wingo]

(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.

[Alexey Proskuryakov]

Mark would know if this is an intentional consequence of r105942 or not.

[Mark Rowe (bdash)]

Yeah, this is my fault.

[Alvaro Lopez Ortega]

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.

[Alexey Proskuryakov]

As described in <http://www.webkit.org/coding/contributing.html>, please set r? flag if this is ready for review, not just cq?.

[WebKit Commit Bot]

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>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Ryosuke Niwa]

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

[Ryosuke Niwa]

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

[WebKit Commit Bot]

Re-opened since this is blocked by bug 116186