-
Notifications
You must be signed in to change notification settings - Fork 29.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fatal V8 Compiler Error #12308
Comments
/cc @nodejs/v8 |
Looks like one of those bugs that @ripsawridge fixed, where the feedback vector layout differed between parsing and preparsing. |
I just had a chance to investigate this (I'm the module author), and it turns out that this actually has nothing to do with the emscripten compiler options. The problem is triggered by a workaround I'd used to make this module work in both Node and webpack with no additional required configuration: specifically, replacing all instances of Also, here's my stack trace from Node 6.10.2 on Debian Jessie x86-64 if it's helpful (error message is the same as @tristanhoy's):
|
I can confirm the issue but I suspect this will be hard to fix due to the size of the changes between v6.x and v7.x. It looks like @bmeurer was spot on, the |
I'm pretty sure @ripsawridge fixed that. He might be able to point you to the proper fix. He'll be back in the office next week. I'll point him to this issue. |
Hi y'all. Yeah, if you look at my git log in the dates in question, I'll
usually mention "vector" and "parser" in the fix. But indeed, I'll have a
look next week, now I'm on slow-net on a mountainside :p.
--Michael
…On Thu, Apr 13, 2017 at 6:05 AM, Benedikt Meurer ***@***.***> wrote:
I'm pretty sure @ripsawridge <https://github.com/ripsawridge> fixed that.
He might be able to point you to the proper fix. He'll be back in the
office next week. I'll point him to this issue.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#12308 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AF1Fo0ApLh7bciCywh7wPs7cQTkofTlGks5rvZ8FgaJpZM4M5BpH>
.
|
I found a few candidates: https://bugs.chromium.org/p/chromium/issues/detail?id=620119 https://bugs.chromium.org/p/chromium/issues/detail?id=608279 https://bugs.chromium.org/p/chromium/issues/detail?id=600995 |
Okay, the issue is https://bugs.chromium.org/p/chromium/issues/detail?id=608279. |
I'll prepare a PR. |
Original commit message: Don't treat catch scopes as possibly-shadowing for sloppy eval Scope analysis is over-conservative when treating variable resolutions as possibly-shadowed by a sloppy eval. In the attached bug, this comes into play since catch scopes have different behavior with respect to the "calls eval" in eager vs lazy compilation (in the latter, they are never marked as "calls eval" because CatchContexts don't have an associated ScopeInfo). This patch changes the scope-type check to also eliminate a few other cases where shadowing isn't possible, such as non-declaration block scopes. BUG=chromium:608279 LOG=n Committed: https://crrev.com/75f2d65f003ebb22815489e9970913ba37234f1b Cr-Commit-Position: refs/heads/master@{nodejs#36046} Fixes: nodejs#12308
Original commit message: Don't treat catch scopes as possibly-shadowing for sloppy eval Scope analysis is over-conservative when treating variable resolutions as possibly-shadowed by a sloppy eval. In the attached bug, this comes into play since catch scopes have different behavior with respect to the "calls eval" in eager vs lazy compilation (in the latter, they are never marked as "calls eval" because CatchContexts don't have an associated ScopeInfo). This patch changes the scope-type check to also eliminate a few other cases where shadowing isn't possible, such as non-declaration block scopes. BUG=chromium:608279 LOG=n Committed: https://crrev.com/75f2d65f003ebb22815489e9970913ba37234f1b Cr-Commit-Position: refs/heads/master@{#36046} Fixes: #12308 PR-URL: #12535 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Myles Borins <[email protected]>
Original commit message: Don't treat catch scopes as possibly-shadowing for sloppy eval Scope analysis is over-conservative when treating variable resolutions as possibly-shadowed by a sloppy eval. In the attached bug, this comes into play since catch scopes have different behavior with respect to the "calls eval" in eager vs lazy compilation (in the latter, they are never marked as "calls eval" because CatchContexts don't have an associated ScopeInfo). This patch changes the scope-type check to also eliminate a few other cases where shadowing isn't possible, such as non-declaration block scopes. BUG=chromium:608279 LOG=n Committed: https://crrev.com/75f2d65f003ebb22815489e9970913ba37234f1b Cr-Commit-Position: refs/heads/master@{#36046} Fixes: #12308 PR-URL: #12535 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Myles Borins <[email protected]>
Original commit message: Don't treat catch scopes as possibly-shadowing for sloppy eval Scope analysis is over-conservative when treating variable resolutions as possibly-shadowed by a sloppy eval. In the attached bug, this comes into play since catch scopes have different behavior with respect to the "calls eval" in eager vs lazy compilation (in the latter, they are never marked as "calls eval" because CatchContexts don't have an associated ScopeInfo). This patch changes the scope-type check to also eliminate a few other cases where shadowing isn't possible, such as non-declaration block scopes. BUG=chromium:608279 LOG=n Committed: https://crrev.com/75f2d65f003ebb22815489e9970913ba37234f1b Cr-Commit-Position: refs/heads/master@{#36046} Fixes: #12308 PR-URL: #12535 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Myles Borins <[email protected]>
This was fixed in cd78a2bd07 and released with v6.10.3. |
The third line in the following script causes an error in the v8 compiler:
Node 7.8.0 (V8 5.5.372) is not affected.
This module is an emscripten transpile, and the issue specifically affects the optimised emcc -O3 build. The compiled, minified source is 107KB so I've made no attempts to debug any further.
An option suggested to the module author is to create a legacy build with less optimisations - so there's certainly workarounds in this case, but could this be a symptom of a deeper issue?
Are there any plans to upgrade V8 for 6.x?
The text was updated successfully, but these errors were encountered: