Fix early crash on abort if the argument is circular #8657

i404788 · 2019-05-23T08:07:27Z

Previously passing an circular object to abort would cause an early crash without showing any relevant information.

This patch uses a modified version of the MDN Circular Replacer Example

Example:

TypeError: Converting circular structure to JSON
    at JSON.stringify (<anonymous>)
    at process.abort (zstd-codec/js/lib/zstd-codec-binding-wasm.js:8:1237371)
    at process.emit (events.js:198:15)
    at processPromiseRejections (internal/process/promises.js:139:20)
    at processTicksAndRejections (internal/process/task_queues.js:87:32)

sbc100 · 2019-05-23T11:19:40Z

src/postamble.js

+    }
+    return value;
+  };
+};


maybe declare this inside of abort since its only used in there?

What kind of situation would trigger this exactly? can we create a test for it somehow?

Putting it inside abort would be good.

It's triggered by process["on"]("unhandledRejection",abort) in nodejs (browser seems to work fine as it doesn't have the event). You can probably test it by calling process.emit("unhandledRejection", [CircularObject]) manually, after which abort will throw an exception as shown in the original example.

As for writing a test, maybe we can call abort([CircularObject]) catch the exception in abort and make sure that it's either caused by https://github.com/emscripten-core/emscripten/blob/incoming/src/postamble.js#L422 or by https://github.com/emscripten-core/emscripten/blob/incoming/src/postamble.js#L431

I suggest maybe we change that line to process["on"]("unhandledRejection",onUnhandledRejection) which can do whatever it wants and then call abort with a string value.

Also we can/should probably just simplify abort to call ".toString()" on its argument. I'm not sure it makes sense for abort to accept complex objects that need JSON formatting.

Also we can/should probably just simplify abort to call ".toString()" on its argument.

That might also make the cause less obvious, often when calling toString() javascript will return [object Object].

If I remember correctly process["on"]("unhandledRejection",onUnhandledRejection) will stop nodejs from showing that there was an unhandledRejection, which means that the only feedback you get (by default) would be from the module.

People shouldn't be calling abort with arbitrary JS objects. I think its reasonable to expect it to take a string or an integer. Anyway, I guess I'm ok with this change as is now.

I'm not sure, but I think we caught unhandledRejection because otherwise node didn't show a proper error during async wasm compilation. It's possible it's no longer necessary.

That's interesting, well to resolve the issue I see a few options:
1.put the unhandledRejection catcher itself behind a flag
2. fix abort to be compatible with an external unhandledRejection (this PR)
3. remove the unhandledRejection (might break something if it is actually used somewhere)

The last one would be the best option in my opinion, but only if we can confirm that it is safe to remove

@kripken I found an old issue referring to the reason of catching unhandledRejection,
#7855

It seems that there is/was a test case for it, so I might check if it's still valid

Thanks, yes, let's see if we still need to have unhandledRejection code. If not, then it would be nice to not have to add code to support circularity etc. as discussed earlier.

I've looked at the test and it still fails if you comment unhandledRejection. I've changed abort to use exit (and console.error) instead of throw, and now it does work without unhandledRejection. I'll be running the full test suite to make sure it doesn't break something else. If everything seems reasonable I'll create another PR.

i404788 · 2019-05-23T12:03:20Z

This language feature is only supported for ECMASCRIPT6 mode or better: block-scoped function declaration.

Moving the function inside abort seems to break the closure compiler build, ~~will probably revert back~~
Looks like I need to move it to the outermost scope function

kripken · 2019-05-28T20:07:44Z

Thanks @i404788 , I think this idea is good! I'd prefer not to increase code size by default, though - how about only doing this when ASSERTIONS are on?

i404788 · 2019-05-28T23:36:16Z

@kripken That sounds like a good idea, I think it would be good to replace the JSON.stringify altogether in non-ASSERTIONS builds with just toString() (as per @sbc100 suggestion).
That should resolve early crashing if an unhandledRejection is thrown, while still giving sufficient feedback to developers.

kripken · 2019-05-30T16:07:16Z

Thanks, I think this looks good, but need to merge in latest incoming to fix the CI errors.

kripken · 2019-06-07T23:37:08Z

Where do we stand on this PR? Separate from the unhandled rejection issue, I think it's best to not handle the circular case, that is, not do JSON.stringify. That seems simplest.

i404788 · 2019-06-08T00:49:29Z

I would agree, for this PR/issue removing JSON.stringify would suffice.
I've updated it to just remove that line, PTAL

kripken · 2019-06-10T17:07:04Z

This looks good, but those errors on sanity look weird. I re-rean the test suite and they still happen. Do you see them locally? python tests/runner.py sanity.test_emcc_caching, but note that it will modify your .emscripten file, the sanity tests are weird. Or, maybe just merge in latest incoming to here, which we need to do anyhow for the conflicts, perhaps that will fix it if it was a problem on older incoming.

i404788 · 2019-06-10T17:11:18Z

I saw the test failure and looked into it for a bit. The CI seems to suggests there is inactivity for a long time which is the same when I run it locally, however I have no idea where it comes from.
I'll try running the test at incoming just before my changes

i404788 · 2019-06-10T17:24:14Z

Results (time python tests/runner.py sanity.test_emcc_caching):

real	7m15.562s
user    6m16.250s
sys	3m11.969s

To be fair the tests run a lot faster on my machine compared to the CI so I wouldn't be surprised if there was a 10m timeout on the CI. I'll try merging to latest incoming
EDIT: rebased to latest it's still just as slow, so I'm not sure if that's just 'normal' behavior

kripken · 2019-06-11T00:34:40Z

Thanks! Looks good now on the tests.

…#8657) * Remove JSON.stringify from abort

sbc100 reviewed May 23, 2019

View reviewed changes

i404788 force-pushed the incoming branch from 81d77fa to c31e74f Compare May 23, 2019 12:17

i404788 mentioned this pull request Jun 6, 2019

Remove unhandledRejection #8748

Closed

i404788 force-pushed the incoming branch from 9c824c3 to fb4e3e6 Compare June 8, 2019 00:47

i404788 force-pushed the incoming branch from 0093b82 to fdcae7d Compare June 8, 2019 18:47

i404788 added 2 commits June 10, 2019 18:28

Remove JSON.stringify from abort

3ccd1eb

Keep format compatible with old version

16cea3f

i404788 force-pushed the incoming branch from fdcae7d to 16cea3f Compare June 10, 2019 17:29

kripken merged commit 6569dd8 into emscripten-core:incoming Jun 11, 2019

belraquib pushed a commit to belraquib/emscripten that referenced this pull request Dec 23, 2020

Fix early crash on abort if the argument is circular (emscripten-core…

46c324d

…#8657) * Remove JSON.stringify from abort

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix early crash on abort if the argument is circular #8657

Fix early crash on abort if the argument is circular #8657

i404788 commented May 23, 2019

sbc100 May 23, 2019

i404788 May 23, 2019 •

edited

Loading

sbc100 May 23, 2019

i404788 May 23, 2019

sbc100 May 30, 2019

kripken May 31, 2019

i404788 Jun 1, 2019

i404788 Jun 3, 2019

kripken Jun 5, 2019

i404788 Jun 5, 2019 •

edited

Loading

i404788 commented May 23, 2019 •

edited

Loading

kripken commented May 28, 2019

i404788 commented May 28, 2019

kripken commented May 30, 2019

kripken commented Jun 7, 2019

i404788 commented Jun 8, 2019

kripken commented Jun 10, 2019 •

edited

Loading

i404788 commented Jun 10, 2019 •

edited

Loading

i404788 commented Jun 10, 2019 •

edited

Loading

kripken commented Jun 11, 2019

Fix early crash on abort if the argument is circular #8657

Fix early crash on abort if the argument is circular #8657

Conversation

i404788 commented May 23, 2019

Choose a reason for hiding this comment

i404788 May 23, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

i404788 Jun 5, 2019 • edited Loading

Choose a reason for hiding this comment

i404788 commented May 23, 2019 • edited Loading

kripken commented May 28, 2019

i404788 commented May 28, 2019

kripken commented May 30, 2019

kripken commented Jun 7, 2019

i404788 commented Jun 8, 2019

kripken commented Jun 10, 2019 • edited Loading

i404788 commented Jun 10, 2019 • edited Loading

i404788 commented Jun 10, 2019 • edited Loading

kripken commented Jun 11, 2019

i404788 May 23, 2019 •

edited

Loading

i404788 Jun 5, 2019 •

edited

Loading

i404788 commented May 23, 2019 •

edited

Loading

kripken commented Jun 10, 2019 •

edited

Loading

i404788 commented Jun 10, 2019 •

edited

Loading

i404788 commented Jun 10, 2019 •

edited

Loading