Bug 79065 - REGRESSION (r105942): Nightly build's jsc doesn't work without DYLD_FRAMEWORK_PATH
Summary: REGRESSION (r105942): Nightly build's jsc doesn't work without DYLD_FRAMEWORK...
Status: REOPENED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac (Intel) OS X 10.6
: P2 Normal
Assignee: Mark Rowe (bdash)
URL:
Keywords:
Depends on: 116186
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-20 18:30 PST by Julian Gonggrijp
Modified: 2019-05-02 16:25 PDT (History)
8 users (show)

See Also:


Attachments
Crash log from attempt to run a script with jsc (6.88 KB, application/octet-stream)
2012-02-20 18:30 PST, Julian Gonggrijp
no flags Details
minimal script that can be used to produce a jsc crash on r108257 (24 bytes, application/x-javascript)
2012-02-20 18:32 PST, Julian Gonggrijp
no flags Details
Patch: Fixes the "Copy Into Framework" target (2.42 KB, patch)
2012-06-20 15:02 PDT, Alvaro Lopez Ortega
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Julian Gonggrijp 2012-02-20 18:30:15 PST
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.
Comment 1 Julian Gonggrijp 2012-02-20 18:32:50 PST
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.
Comment 2 Alexey Proskuryakov 2012-02-20 20:23:59 PST
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).
Comment 3 Julian Gonggrijp 2012-02-21 03:42:26 PST
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.
Comment 4 Alexey Proskuryakov 2012-02-21 08:50:37 PST
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)
Comment 5 Andy Wingo 2012-02-21 09:16:27 PST
(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.
Comment 6 Alexey Proskuryakov 2012-02-21 09:47:42 PST
Mark would know if this is an intentional consequence of r105942 or not.
Comment 7 Mark Rowe (bdash) 2012-02-23 09:53:27 PST
Yeah, this is my fault.
Comment 8 Alvaro Lopez Ortega 2012-06-20 15:02:04 PDT
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.
Comment 9 Alexey Proskuryakov 2012-06-23 09:37:14 PDT
As described in <http://www.webkit.org/coding/contributing.html>, please set r? flag if this is ready for review, not just cq?.
Comment 10 WebKit Commit Bot 2013-05-13 20:20:20 PDT
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>
Comment 11 WebKit Commit Bot 2013-05-13 20:20:22 PDT
All reviewed patches have been landed.  Closing bug.
Comment 13 Ryosuke Niwa 2013-05-14 22:18:59 PDT
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
Comment 14 WebKit Commit Bot 2013-05-15 14:20:00 PDT
Re-opened since this is blocked by bug 116186