Closed JanMarvin closed 4 years ago
Pfff incredible how they manage to change the API every time.
https://github.com/jeroen/V8/commit/6e6f59369c14dbef978d60882d026431676ed1c3 is causing the error. The change in bindings.cpp lines 148
Thanks! IsUndefined()
again 🤔 Can you see which of these tests causes the segfault?
ctx <- V8::v8()
expect_equal(ctx$eval('function I(x){return x}'), 'undefined')
expect_null(ctx$eval("undefined", TRUE))
expect_null(ctx$eval("null", TRUE))
expect_equal(ctx$eval("[]", TRUE), "[]")
expect_equal(ctx$eval('I({})', TRUE), "{}")
expect_equal(ctx$eval("1", TRUE), "1")
expect_equal(ctx$eval(1, TRUE), "1")
expect_equal(ctx$eval('new Uint8Array( [1,2] )', TRUE), as.raw(1:2))
expect_equal(ctx$eval('new Uint8Array( [1,2] ).buffer', TRUE), as.raw(1:2))
expect_error(ctx$eval('doesnotexist', TRUE), 'doesnotexist', class = "std::runtime_error")
commented the crashing ones
ctx <- V8::v8()
expect_equal(ctx$eval('function I(x){return x}'), 'undefined')
# expect_null(ctx$eval("undefined", TRUE))
# expect_null(ctx$eval("null", TRUE))
# expect_equal(ctx$eval("[]", TRUE), "[]")
# expect_equal(ctx$eval('I({})', TRUE), "{}")
expect_equal(ctx$eval("1", TRUE), "1")
expect_equal(ctx$eval(1, TRUE), "1")
# expect_equal(ctx$eval('new Uint8Array( [1,2] )', TRUE), as.raw(1:2))
# expect_equal(ctx$eval('new Uint8Array( [1,2] ).buffer', TRUE), as.raw(1:2))
expect_error(ctx$eval('doesnotexist', TRUE), 'doesnotexist', class = "std::runtime_error")
edit: but other tests fail as well :man_shrugging:
edit2: if I keep either IsNull()
or IsUndefined()
R crashes, if I remove the if-clause all but 2 tests succeed.
I'm trying to build V8 8.1 on homebrew but the build fails. Do you happen to know which of the external resources that need an update to build the latest V8? https://github.com/homebrew/homebrew-core/blob/master/Formula/v8.rb
No sorry, I assume if it builds any V8 7.x release it should be fine.
Can you test if the latest commit solves anything?
No, it does not. The call ->IsNull()
or ->IsUndefined()
cause the crash.
Yeah I was hoping we would not get to that call in case of value.IsEmpty()
Looks like I'm going to first have to figure out how to fix the libv8 build 8.1 on macos to debug this... the problem is a new requirement on zlib which you have addressed here: https://github.com/JanMarvin/v8-R/commit/526cf82f09633911b4fb999721763f31fde9aeec
Ah yes, completely forgot about that. Somehow I assumed that it's Arch Linux specific
I have committed a workaround. But still haven't figured out the real problem. Looks like a bug in v8...
Thanks will test it tomorrow. Wish you a nice Christmas! :gift:
Posted the issue in the v8-dev forum: https://groups.google.com/forum/#!topic/v8-dev/N9BpiGxPaQs
Happy xmas to you as well 🎄
Were you able to confirm if compiling with V8_ENABLE_CHECKS resolves the crash for you?
Also could you maybe test if the test program that I attached to this email in the v8 forums also crashes on arch? https://groups.google.com/forum/#!topic/v8-dev/N9BpiGxPaQs
Sorry for the late reply: V8_ENABLE_CHECKS
resolves the issue for me and the hello-crash program crashes for me too (had to change v8 includes). I assume the issue is somehow related to this bug: https://bugs.chromium.org/p/v8/issues/detail?id=10041&q=&colspec=ID%20Type%20Status%20Priority%20Owner%20Summary%20HW%20OS%20Component%20Stars
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./a.out...
(gdb) run
Starting program: /tmp/a.out
/usr/lib/../share/gcc-9.2.0/python/libstdcxx/v6/xmethods.py:731: SyntaxWarning: list indices must be integers or slices, not str; perhaps you missed a comma?
refcounts = ['_M_refcount']['_M_pi']
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff4b23700 (LWP 2241)]
[New Thread 0x7ffff4322700 (LWP 2242)]
[New Thread 0x7ffff3b21700 (LWP 2243)]
[New Thread 0x7ffff3320700 (LWP 2244)]
[New Thread 0x7ffff2b1f700 (LWP 2245)]
[New Thread 0x7ffff231e700 (LWP 2246)]
[New Thread 0x7ffff1b1d700 (LWP 2247)]
[New Thread 0x7ffff131c700 (LWP 2248)]
Thread 1 "a.out" received signal SIGSEGV, Segmentation fault.
v8::internal::Internals::GetInstanceType (obj=15221498847309) at /usr/include/v8-internal.h:233
233 return ReadRawField<uint16_t>(map, kMapInstanceTypeOffset);
(gdb) backtrace
#0 v8::internal::Internals::GetInstanceType (obj=15221498847309) at /usr/include/v8-internal.h:233
#1 v8::Value::QuickIsUndefined (this=0x5555555f5db0) at /usr/include/v8.h:11310
#2 v8::Value::IsUndefined (this=0x5555555f5db0) at /usr/include/v8.h:11301
#3 main (argc=1, argv=0x7fffffffe8a8) at hello-crash.cc:53
Edit: If I compile hello-crash with -DV8_ENABLE_CHECKS that works as well. Checked on V8 8.1.80
I'm considering reverting https://github.com/jeroen/V8/pull/76 because the real problem is probably fixed by V8_ENABLE_CHECKS...
No worries, I'm waiting with updates to the aur package until the issue is resolved. Happy new year!
Some upstream progress: https://bugs.chromium.org/p/v8/issues/detail?id=10041
FYI, I have pushed out a new CRAN release to make sure users don't get hit by this issue.
AUR package is updated, thanks!
Upstream has made further progress, this breaks building with -DV8_ENABLE_CHECKS
and requires -DV8_COMPRESS_POINTERS
or it will fail with the pointer compression mismatch error.
For clarification: v8 defaults to pointer compression which caused crashes. to avoid this pointer compression was disabled on the R side (#78). This does not work anymore with v8 after https://github.com/v8/v8/commit/2db93c0233790b2cfb9e80fa1fa89dee18c7109f. Now v8 compares it's internal handling of pointer compression to the embedders pointer compression. If they don't match the embedding program crashes.
Just to inform you, recent changes cause a crash in v8.