1226220 - Interpreter-only debug build fails due to an undefined verifyHeapAccessDisassembly

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[bryanpkc]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20151027170520

Steps to reproduce:

js can be built successfully on Linux s390x and works as an interpreter. But trying to build it in debug mode fails:

cd js/src
./configure  --enable-debug --disable-ion


Actual results:

c++ -o Unified_cpp_js_src3.o -c  -I../../dist/system_wrappers -include /sandbox/bryanpkc/js/mozilla-release/config/gcc_hidden.h -DIMPL_MFBT -DEXPORT_JS_API -DAB_CD= -DNO_NSPR_10_SUPPORT -I/sandbox/bryanpkc/js/mozilla-release/js/src -I. -I/sandbox/bryanpkc/js/mozilla-release/intl/icu/source/common -I/sandbox/bryanpkc/js/mozilla-release/intl/icu/source/i18n -I../../dist/include           -fPIC   -DMOZILLA_CLIENT -include ../../js/src/js-confdefs.h -MD -MP -MF .deps/Unified_cpp_js_src3.o.pp  -Wall -Wsign-compare -Wtype-limits -Wno-invalid-offsetof -Wcast-align -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe  -DDEBUG -DTRACING -g -freorder-blocks -O3 -fno-omit-frame-pointer       /sandbox/bryanpkc/js/mozilla-release/js/src/js/src/Unified_cpp_js_src3.cpp
In file included from /sandbox/bryanpkc/js/mozilla-release/js/src/jit/CodeGenerator.cpp:41:0,
                 from /sandbox/bryanpkc/js/mozilla-release/js/src/js/src/Unified_cpp_js_src3.cpp:92:
/sandbox/bryanpkc/js/mozilla-release/js/src/jit/shared/CodeGenerator-shared-inl.h: In member function ‘void js::jit::CodeGeneratorShared::verifyHeapAccessDisassembly(uint32_t, uint32_t, bool, js::Scalar::Type, const js::jit::Operand&, js::jit::LAllocation)’:
/sandbox/bryanpkc/js/mozilla-release/js/src/jit/shared/CodeGenerator-shared-inl.h:232:10: error: ‘class js::jit::MacroAssembler’ has no member named ‘verifyHeapAccessDisassembly’
     masm.verifyHeapAccessDisassembly(begin, end,
          ^
make[3]: *** [Unified_cpp_js_src3.o] Error 1
make[3]: Leaving directory `/sandbox/bryanpkc/js/mozilla-release/js/src/js/src'



Expected results:

I would expect the build to complete successfully just as it would if I I didn't use --enable-debug. I believe the fix is to simply add a no-op implementation of verifyHeapAccessDisassembly to the js::jit::MacroAssembler class.

Comment 1

[Benjamin Bouvier [:bbouvier] (inactive)]

Thank you for the report. However, basing my build off on mozilla-central, I don't have any error when I build with the same flags. Moreover, there is a dummy implementation of verifyHeapAccessDisassembly there https://dxr.mozilla.org/mozilla-central/source/js/src/jit/none/MacroAssembler-none.h#135

Your build log shows that you are based on mozilla-release. Even there, there seems to be a dummy implementation of this function: http://mxr.mozilla.org/mozilla-release/source/js/src/jit/none/MacroAssembler-none.h#135

How did you retrieve the source? Did you recently pull the repository?

Comment 2

[bryanpkc]

Thanks for looking, Benjamin. I used the source from this tar ball:

https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/38.3.0esr/source/firefox-38.3.0esr.source.tar.bz2

I have downloaded 38.4.0esr, timestamped November 2, 2015, and MacroAssembler-none.h in that version still hasn't defined the verifyHeapAccessDisassembly function. I guess it must have been a recent change?

Comment 3

[Benjamin Bouvier [:bbouvier] (inactive)]

Sean, is this the most recent tar ball package for Spidermonkey, or is there another one with more up to date sources?

Comment 4

[bryanpkc]

Looks like this is a dup of bug 1144692.

Comment 5

[bryanpkc]

I was able to build Spidermonkey in moz38 with JS_CODEGEN_NONE and DEBUG, after patching two of the three files in this commit:

https://hg.mozilla.org/mozilla-central/rev/ec8f020d47ae

Will this fix be back-ported to 38?

Comment 6

[Benjamin Bouvier [:bbouvier] (inactive)]

Sean told me on IRC that Steve had a plan for a new release, so needinfo-ing him instead.

Comment 7

[Steve Fink [:sfink] [:s:]]

I only intend to make sure we release a mozjs-45 reasonably promptly, but that's current Nightly so it's two release cycles away.

How important is it to have a 38 with this fix? I could make one, but I'm not eager to do the backport approval requests.

I'd be happier to do a prerelease of a mozjs-nightly or something, though I'm not sure how to do the versioning. I don't really want to pollute the final release version numbers with various nightly releases. How would people feel about mozjs-nightly-45.0.0.tar.bz2? (As in, give the Nightly/Aurora versions distinct names.)

Comment 8

[Steve Fink [:sfink] [:s:]]

If you need something to test with, you can try the even-more-unofficial-than-usual http://people.mozilla.org/~sfink/data/mozjs-nightly-45.0a1.0.tar.bz2

Comment 9

[bryanpkc]

For my purpose I can patch the js code when I build and link it, but I think it would be nice to include this fix in the next mozjs-38 release. It will help developers who still need to work with mozjs-38, which is still an ESR.