Improve JS library error reporting #25089

sbc100 · 2025-08-28T18:30:20Z

If there are errors in JS library code we now have an option to save the preprocessed output to a temp location. From there lookup the error message and corresponding line number.

For example:

$ emcc ~/test//hello.c
error: /usr/local/google/home/sbc/dev/wasm/emscripten/src/lib/libcore.js: failure to execute js library "/usr/local/google/home/sbc/dev/wasm/emscripten/src/lib/libcore.js":
error: /usr/local/google/home/sbc/dev/wasm/emscripten/src/lib/libcore.js: use -sVERBOSE to see more details
Internal compiler error JS compiler
Please create a bug report at https://github.com/emscripten-core/emscripten/issues/
with a log of the build and the input files used to run. Exception message: "/usr/local/google/home/sbc/dev/wasm/emscripten/src/lib/libcore.preprocessed.js:1087
    ds = fd
    ^^^^^^^

SyntaxError: Invalid shorthand property initializer
    at new Script (node:vm:117:7)
    at createScript (node:vm:269:10)
    at Module.runInContext (node:vm:300:10)
    at runInMacroContext (file:///usr/local/google/home/sbc/dev/wasm/emscripten/src/utility.mjs:324:13)
    at Object.load (file:///usr/local/google/home/sbc/dev/wasm/emscripten/src/modules.mjs:291:9)
    at Module.runJSify (file:///usr/local/google/home/sbc/dev/wasm/emscripten/src/jsifier.mjs:354:18)
    at file:///usr/local/google/home/sbc/dev/wasm/emscripten/tools/compiler.mjs:97:17

Building with -sVERBOSE then generates:

$ emcc ~/test//hello.c -sVERBOSE
processing system library: /usr/local/google/home/sbc/dev/wasm/emscripten/src/lib/libint53.js
processing system library: /usr/local/google/home/sbc/dev/wasm/emscripten/src/lib/libcore.js
error: /usr/local/google/home/sbc/dev/wasm/emscripten/src/lib/libcore.js: failure to execute js library "/usr/local/google/home/sbc/dev/wasm/emscripten/src/lib/libcore.js":
error: /usr/local/google/home/sbc/dev/wasm/emscripten/src/lib/libcore.js: See preprocessed source in /tmp/emcc-jscompiler-3XmDDr/libcore.js
Internal compiler error JS compiler
Please create a bug report at https://github.com/emscripten-core/emscripten/issues/
with a log of the build and the input files used to run. Exception message: "/tmp/emcc-jscompiler-3XmDDr/libcore.js:1087
    ds = fd
    ^^^^^^^

SyntaxError: Invalid shorthand property initializer
    at new Script (node:vm:117:7)
    at createScript (node:vm:269:10)
    at Module.runInContext (node:vm:300:10)
    at runInMacroContext (file:///usr/local/google/home/sbc/dev/wasm/emscripten/src/utility.mjs:324:13)
    at Object.load (file:///usr/local/google/home/sbc/dev/wasm/emscripten/src/modules.mjs:291:9)
    at Module.runJSify (file:///usr/local/google/home/sbc/dev/wasm/emscripten/src/jsifier.mjs:354:18)
    at file:///usr/local/google/home/sbc/dev/wasm/emscripten/tools/compiler.mjs:97:17

No you can open the file mentioned in the error message (/tmp/emcc-jscompiler-3XmDDr/libcore.js) and go to line 1087.

Without this change the file referenced in the error message will always be non-existant, and we would instead dump the whole file (which could be huge) to stderr.

sbc100 · 2025-08-28T18:31:57Z

Ideally we could hook this up to EMCC_DEBUG and/or -save-temps.

kripken

Can we use EMCC_DEBUG here as you suggest? I think node can just read the env to get it?

kripken · 2025-08-28T19:23:40Z

src/modules.mjs

@@ -269,22 +282,22 @@ export const LibraryManager = {
        this.library = userLibraryProxy;
      }
      pushCurrentFile(filename);
+      let preprocessed_name = filename.replace(/\.\w+$/, '.preprocessed$&')


Suggested change

let preprocessed_name = filename.replace(/\.\w+$/, '.preprocessed$&')

let preprocessedName = filename.replace(/\.\w+$/, '.preprocessed$&')

juj · 2025-08-28T20:03:31Z

src/modules.mjs

+        if (processed) {
+          if (VERBOSE) {
+            fs.writeFileSync(preprocessed_name, processed);
+            error(`See preprocessed source in ${preprocessed_name}`)


Hmmh, looking at the example error messages in default and verbose, they look quite the same.

After this PR, in order to examine the failing JS code, one has to first build with -sVERBOSE, and then locate the .js file to examine in the output, and then open it in an editor. That is adding more steps to get to examining the source?

I wonder if it might make sense to always save the preprocessed output file in nonverbose mode, and in verbose mode, the output would be printed to stdout? Although hmm, then there would be a problem with leaving behind littering files in default output.

It is of course quite different from regular C/C++ errors/warnings to dump the whole file to stdout, though at least in the context of Closure warnings/errors, getting the full Closure input file dumped to stdout, along with line numbers is a great time saver. I typically re-run the failing build with a emcc ... > log.txt 2>&1 to get the full line-numberized Closure output into a file. That workflow feels faster than needing to locate the file manually, and then selecting that with mouse and copy-pasting to open in editor?

Yes, I thought of saving the file by default too, but I didn't want to litter the tmp directory whenever a failure happened.

Regarding closure, I almost always use EMCC_DEBUG=1 which leaves the temp files around. Then the error message from closure directly correspond to the file and you can just open it and jump to the offending line. I find this way nicer than stderr redirection, especially since the line numbers are always correct.

(I wasn't aware of a mode where I closure dumps full file to stdout/stderr, but if its anything like this -sVERBOSE option I think I would still prefer the separate file with matching line numbers).

That workflow feels faster than needing to locate the file manually, and then selecting that with mouse and copy-pasting to open in editor?

You don't need to "locate the file" per since the error message itself simply points direclty to it, just like a normal compiler error. e.g You can see /tmp/emcc-jscompiler-3XmDDr/libcore.js:1087 reported in the error above. The same goes for closure errors when you build with EMCC_DEBUG=1.

If you personal prefer the stdout approach I can look into keeping that option around if you like.

I find this way nicer than stderr redirection, especially since the line numbers are always correct.

The line numbers are also correct with Closure errors. E.g.

a.c

#include <emscripten.h> int main() { EM_ASM({nonExisting();}); }

EMCC_DEBUG=2 emcc a.c -o a.js --closure 1

prints

building:ERROR: Closure compiler run failed: 1: // include: shell.js 2: /** 3: * @license 4: * Copyright 2010 The Emscripten Authors 5: * SPDX-License-Identifier: MIT 6: */ 7: // The Module object: Our interface to the outside world. We import 8: // and export values on it. There are various ways Module can be used: 9: // 1. Not defined. We create it here 10: // 2. A function parameter, function(moduleArg) => Promise<Module> 11: // 3. pre-run appended it, var Module = {}; ..generated code.. ... 1492: var ASM_CONSTS = { 1493: 65536: () => { nonExisting(); } 1494: }; ... 1662: preInit(); 1663: run(); 1664: 1665: // end include: postamble.js 1666: building:ERROR: C:/Users/clb/AppData/Local/Temp/emscripten_temp/a.js:1493:17: ERROR - [JSC_UNDEFINED_VARIABLE] variable nonExisting is undeclared 1493| 65536: () => { nonExisting(); } ^^^^^^^^^^^

Now I notice here a discrepancy between Closure JS errors using EMCC_DEBUG=2 env. var. and JS errors using -sVERBOSE (I wonder if EMCC_DEBUG=2 env.var. implies -sVERBOSE?)

Closure errors don't offer this hint currently to use EMCC_DEBUG=2 it looks like:

C:\emsdk\emscripten\main>emcc a.c -o a.js --closure 1 building:ERROR: Closure compiler run failed: building:ERROR: C:/Users/clb/AppData/Local/Temp/emscripten_temp_fp4_y3jx/a.js:1493:17: ERROR - [JSC_UNDEFINED_VARIABLE] variable nonExisting is undeclared 1493| 65536: () => { nonExisting(); } ^^^^^^^^^^^ 1 error(s), 0 warning(s) emcc: error: closure compiler failed (rc: 1)

and filename C:/Users/clb/AppData/Local/Temp/emscripten_temp_fp4_y3jx/a.js above points to a file that doesn't exist after compilation.. a lot of room to improve the UX here for sure.

Thinking more about it, I don't think it is necessarily a big deal if the output goes to file or stdout. I do find that getting line-numberized output directly to stdout feels one less step (and would also be easier to capture on a CI run as well, e.g. if needed to get a debug output from a remote command?), but don't mind strongly either way here.

and filename C:/Users/clb/AppData/Local/Temp/emscripten_temp_fp4_y3jx/a.js above points to a file that doesn't exist after compilation.. a lot of room to improve the UX here for sure.

That is kind of the main thing this change fixes. It makes the errors point to a real file, at least when -sVEBOSE is specified.

sbc100 · 2025-08-28T20:30:09Z

Can we use EMCC_DEBUG here as you suggest? I think node can just read the env to get it?

But we already have the -sVERBOSE mechanism in place here... are you suggesting we replace that? That seems like wider change, although I would not be against it.

sbc100 · 2025-08-28T21:03:36Z

In terms of the best UI for surfacing I think we should probably (eventually) move to being consistent and choose one of these three options to use in call cases.

Recommend re-running with -sVERBOSE on the command line
Recommend re-running with EMCC_DEBUG=1 in environment
Recommend re-running with -save-temps

Currently (1) is used for JS compiler and (2) is used for closure compiler, but (3) is the standard gcc/clang name.

I will open a separate bug for this.

sbc100 · 2025-08-28T21:05:35Z

#25092

kripken · 2025-08-28T22:11:09Z

But we already have the -sVERBOSE mechanism in place here... are you suggesting we replace that?

Interesting idea, but no, I wasn't thinking that. My position is

VERBOSE is great for verbose logging.
EMCC_DEBUG does some debug logging, but the key thing it does is save temp files after each step.

This feels more like EMCC_DEBUG than VERBOSE.

But, I don't feel strongly. As long as it's documented, which you have done, sgtm either way.

sbc100 · 2025-08-28T22:55:50Z

I've opened #25092 to consolidate the different options.

This change is focused on making the filename int he -sVERBOSE logging correct for JS library files.

If there are errors in JS library code we now have an options to save the preprocessed output to a temp location. From there lookup the error message and corresponding line number. For example: ``` $ emcc ~/test//hello.c error: /usr/local/google/home/sbc/dev/wasm/emscripten/src/lib/libcore.js: failure to execute js library "/usr/local/google/home/sbc/dev/wasm/emscripten/src/lib/libcore.js": error: /usr/local/google/home/sbc/dev/wasm/emscripten/src/lib/libcore.js: use -sVERBOSE to see more details Internal compiler error JS compiler Please create a bug report at https://github.com/emscripten-core/emscripten/issues/ with a log of the build and the input files used to run. Exception message: "/usr/local/google/home/sbc/dev/wasm/emscripten/src/lib/libcore.preprocessed.js:1087 ds = fd ^^^^^^^ SyntaxError: Invalid shorthand property initializer at new Script (node:vm:117:7) at createScript (node:vm:269:10) at Module.runInContext (node:vm:300:10) at runInMacroContext (file:///usr/local/google/home/sbc/dev/wasm/emscripten/src/utility.mjs:324:13) at Object.load (file:///usr/local/google/home/sbc/dev/wasm/emscripten/src/modules.mjs:291:9) at Module.runJSify (file:///usr/local/google/home/sbc/dev/wasm/emscripten/src/jsifier.mjs:354:18) at file:///usr/local/google/home/sbc/dev/wasm/emscripten/tools/compiler.mjs:97:17 ``` Building with -sVERBOSE then generates: ``` $ emcc ~/test//hello.c -sVERBOSE processing system library: /usr/local/google/home/sbc/dev/wasm/emscripten/src/lib/libint53.js processing system library: /usr/local/google/home/sbc/dev/wasm/emscripten/src/lib/libcore.js error: /usr/local/google/home/sbc/dev/wasm/emscripten/src/lib/libcore.js: failure to execute js library "/usr/local/google/home/sbc/dev/wasm/emscripten/src/lib/libcore.js": error: /usr/local/google/home/sbc/dev/wasm/emscripten/src/lib/libcore.js: See preprocessed source in /tmp/emcc-jscompiler-3XmDDr/libcore.js Internal compiler error JS compiler Please create a bug report at https://github.com/emscripten-core/emscripten/issues/ with a log of the build and the input files used to run. Exception message: "/tmp/emcc-jscompiler-3XmDDr/libcore.js:1087 ds = fd ^^^^^^^ SyntaxError: Invalid shorthand property initializer at new Script (node:vm:117:7) at createScript (node:vm:269:10) at Module.runInContext (node:vm:300:10) at runInMacroContext (file:///usr/local/google/home/sbc/dev/wasm/emscripten/src/utility.mjs:324:13) at Object.load (file:///usr/local/google/home/sbc/dev/wasm/emscripten/src/modules.mjs:291:9) at Module.runJSify (file:///usr/local/google/home/sbc/dev/wasm/emscripten/src/jsifier.mjs:354:18) at file:///usr/local/google/home/sbc/dev/wasm/emscripten/tools/compiler.mjs:97:17 ``` No you can open the file mentioned in the error message (/tmp/emcc-jscompiler-3XmDDr/libcore.js) and go to line 1087

sbc100 requested review from dschuff, kripken and juj August 28, 2025 18:30

kripken reviewed Aug 28, 2025

View reviewed changes

juj reviewed Aug 28, 2025

View reviewed changes

sbc100 force-pushed the js_lib_errors branch from 7202bc3 to 6265514 Compare August 28, 2025 23:00

sbc100 force-pushed the js_lib_errors branch from 6265514 to db5d395 Compare August 28, 2025 23:15

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Improve JS library error reporting #25089

Improve JS library error reporting #25089

Uh oh!

sbc100 commented Aug 28, 2025 •

edited

Loading

Uh oh!

sbc100 commented Aug 28, 2025

Uh oh!

kripken left a comment

Uh oh!

kripken Aug 28, 2025

Uh oh!

juj Aug 28, 2025

Uh oh!

sbc100 Aug 28, 2025 •

edited

Loading

Uh oh!

juj Aug 28, 2025 •

edited

Loading

Uh oh!

sbc100 Aug 28, 2025

Uh oh!

sbc100 commented Aug 28, 2025

Uh oh!

sbc100 commented Aug 28, 2025

Uh oh!

sbc100 commented Aug 28, 2025

Uh oh!

kripken commented Aug 28, 2025

Uh oh!

sbc100 commented Aug 28, 2025

Uh oh!

Uh oh!

	let preprocessed_name = filename.replace(/\.\w+$/, '.preprocessed$&')
	let preprocessedName = filename.replace(/\.\w+$/, '.preprocessed$&')

Improve JS library error reporting #25089

Are you sure you want to change the base?

Improve JS library error reporting #25089

Uh oh!

Conversation

sbc100 commented Aug 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sbc100 commented Aug 28, 2025

Uh oh!

kripken left a comment

Choose a reason for hiding this comment

Uh oh!

kripken Aug 28, 2025

Choose a reason for hiding this comment

Uh oh!

juj Aug 28, 2025

Choose a reason for hiding this comment

Uh oh!

sbc100 Aug 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

juj Aug 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sbc100 Aug 28, 2025

Choose a reason for hiding this comment

Uh oh!

sbc100 commented Aug 28, 2025

Uh oh!

sbc100 commented Aug 28, 2025

Uh oh!

sbc100 commented Aug 28, 2025

Uh oh!

kripken commented Aug 28, 2025

Uh oh!

sbc100 commented Aug 28, 2025

Uh oh!

Uh oh!

sbc100 commented Aug 28, 2025 •

edited

Loading

sbc100 Aug 28, 2025 •

edited

Loading

juj Aug 28, 2025 •

edited

Loading