5.8mb contents of obfuscated wasm module printed when exception thrown elsewhere in program

[dvtate]

Version

v18.3.0

Platform

Linux archbook 5.18.3-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 09 Jun 2022 16:14:10 +0000 x86_64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

Please see this issue thread: emscripten-core/emscripten#17228

A realistic example is done as follows:

$ echo "{}" > package.json
$ npm install binaryen
$ cat > test.mjs
// Appears to be imported in a new thread?
import binaryen from 'binaryen';

// Never seen
console.warn('important debugging message!!');

throw new Error('fatal');

$ node test.mjs
important debugging message!!
[... 5.8 mb contents of node_modules/binaryen/index.js output to stderr ...]
[ 6 new lines ]
Error: fatal
    at file:///home/tate/Desktop/emscr-bug/test.mjs:7:7

Node.js v18.3.0
$ 

How often does it reproduce? Is there a required condition?

Consistently reproducable. I even remember experienceing this exact bug as far back as 2020 (nodejs v14+)

What is the expected behavior?

I'm assuming that it's importing the module concurrently with the main thread if that's the case than on error only the thread that errored should have it's code highlighted, or at least the code highlighted code should be truncated to where it doesn't take several seconds to print

What do you see instead?

5.8mb of obfuscated javascript which burries the debugging message I had written

Additional information

Relevant thread: emscripten-core/emscripten#17228

[lastmjs]

Hi I am running into what seems like the exact same problem. I added some context including a very simple reproducible example in the emscripten thread here: emscripten-core/emscripten#17228 (comment)

@dvtate did you ever find a workaround for this?

[dvtate]

@lastmjs IIRC the problem occurs when there's an uncaught exception. So maybe if you catch all the exceptions (and maybe print them differently?)

[lastmjs]

Unfortunately that does not help, I've tried to do this for example like this:

process.on('uncaughtException', () => {
    console.log('uncaughtException')
});

process.on('unhandledRejection', () => {
    console.log('unhandledRejection')
});

import "binaryen";

throw new Error("Should not see all of the code above");

The wall of text still comes.

The best I have found so far is to use --abort-on-uncaught-exception which gets rid of the wall of text, but has an unfortunate scary-looking stack trace below the error.

[lastmjs]

BTW @redyetidev I'm not sure how much this issue has to do with Wasm. The binaryen.js library is a very large file of minified JS, and that is what is printed to the terminal.

[avivkeller]

Can a member transfer this to nodejs/help, unless someone from the team thinks this belongs here?

[lastmjs]

Based on the information in the other issues and what I've found, the root of the problem seems to be with Node.js (for example: AssemblyScript/binaryen.js#94 (comment)).

[dvtate]

@redyetidev the problem is that nodejs always prints out the entire line that the error originates from. For minified code this single line could be very, very big (and unreadable). Node.js should truncate code snippets printed out in error messages.

[avivkeller]

That seems to be working as intended, but I'd love a second opinion.

[romdotdog]

Why is dumping an entire minified file into the stack trace considered as Node.js "working as intended"? "Working as intended" should be truncating the line because nobody needs the entire source code to be print out every stack trace.