You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I can't actually reproduce it on my Ubuntu workstation. I installed ajv 1.3.10 via npm. The test case runs fine on v7.7.5-pre both release and debug mode, and on v7.7.3 debug mode.
I wonder whether Alpine Linux has different settings wrt stack limit. Maybe you can try with running with --no-use-gvn?
I can't actually reproduce it on my Ubuntu workstation. I installed ajv 1.3.10 via npm. The test case runs fine on v7.7.5-pre both release and debug mode, and on v7.7.3 debug mode.
I can only reproduce the crash when running on Alpine Linux.
I wonder whether Alpine Linux has different settings wrt stack limit. Maybe you can try with running with --no-use-gvn?
80kb sounds very limited. The correct fix would be to add stack checks to Crankshaft's GVN, but Crankshaft in upstream V8 is no longer under development.
Does node --stack_size=$kb test_ajv.js, where $kb is a value < 80, work? If yes, I suppose we could detect RLIMIT_STACK and adjust --stack_size accordingly.
Is the limit set my musl or alpine? I don't see anything in musl that suggests it modifies RLIMIT_STACK.
@bnoordhuis that would be a good idea generally, but wouldn't help this case since the recursion in GVN doesn't perform stack checks. It would prevent crashes where we do though.
Good point. I think we could float a patch that adds stack checks in the appropriate places or make it non-recursive. CollectSideEffectsOnPathsToDominatedBlock appears to be the main offender.
Ah, I understand now - I was looking at execve() and friends but it's a per-thread setting. In that case --noconcurrent_recompilation can probably be used as a workaround too, depending on the RLIMIT_STACK of the main thread (which hopefully is bigger.)
Activity
mscdex commentedon Mar 22, 2017
Backtrace:
mscdex commentedon Mar 22, 2017
/cc @nodejs/v8
hashseed commentedon Mar 23, 2017
Looks like Crankshaft is running into stack overflow. Turbofan likely won't have this issue. I'll take a look whether there is an easy fix here.
hashseed commentedon Mar 23, 2017
I can't actually reproduce it on my Ubuntu workstation. I installed ajv 1.3.10 via npm. The test case runs fine on v7.7.5-pre both release and debug mode, and on v7.7.3 debug mode.
I wonder whether Alpine Linux has different settings wrt stack limit. Maybe you can try with running with
--no-use-gvn?daveisfera commentedon Mar 23, 2017
I can only reproduce the crash when running on Alpine Linux.
It does not crash when I run with
--no-use-gvn.daveisfera commentedon Apr 4, 2017
I just tried with node 6.10.2 and it now crashes with a smaller number of columns (70) but the same number of rows is required (394).
johan13 commentedon Apr 17, 2017
Alpine Linux uses musl libc which has a default stack size of just 80 kB. Glibc for example has a default stack size of 8 MB.
hashseed commentedon Apr 17, 2017
80kb sounds very limited. The correct fix would be to add stack checks to Crankshaft's GVN, but Crankshaft in upstream V8 is no longer under development.
johan13 commentedon Apr 17, 2017
It doesn't crash if you use the Turbofan compiler.
node --turbo test_ajv.jsbnoordhuis commentedon Apr 17, 2017
Does
node --stack_size=$kb test_ajv.js, where $kb is a value < 80, work? If yes, I suppose we could detect RLIMIT_STACK and adjust--stack_sizeaccordingly.Is the limit set my musl or alpine? I don't see anything in musl that suggests it modifies RLIMIT_STACK.
hashseed commentedon Apr 17, 2017
@bnoordhuis that would be a good idea generally, but wouldn't help this case since the recursion in GVN doesn't perform stack checks. It would prevent crashes where we do though.
bnoordhuis commentedon Apr 17, 2017
Good point. I think we could float a patch that adds stack checks in the appropriate places or make it non-recursive. CollectSideEffectsOnPathsToDominatedBlock appears to be the main offender.
johan13 commentedon Apr 17, 2017
@bnoordhuis, the limit is in musl: https://anonscm.debian.org/cgit/collab-maint/musl.git/tree/src/internal/pthread_impl.h#n144
bnoordhuis commentedon Apr 17, 2017
@johan13 Can you try #12460?
Ah, I understand now - I was looking at execve() and friends but it's a per-thread setting. In that case
--noconcurrent_recompilationcan probably be used as a workaround too, depending on the RLIMIT_STACK of the main thread (which hopefully is bigger.)121 remaining items
v8: fix stack overflow in recursive method
v8: fix stack overflow in recursive method
v8: fix stack overflow in recursive method
v8: fix stack overflow in recursive method