I suppose this is because pointer compression was recently enabled by default. So either you disable pointer compression when compiling V8 (v8_enable_pointer_compression = false in your args.gn) or you need to compile your example program with -DV8_COMPRESS_POINTERS. This fixed the issue for me at least. Hope that helps!
On Sunday, December 29, 2019 at 12:29:17 PM UTC+1, Jeroen Ooms wrote: > > On Sun, Dec 29, 2019 at 12:00 PM Ben Noordhuis <[email protected] > <javascript:>> wrote: > > > > On Thu, Dec 26, 2019 at 2:53 PM Jeroen Ooms <[email protected] > <javascript:>> wrote: > > > > > > On Thu, Dec 26, 2019 at 10:36 AM Ben Noordhuis <[email protected] > <javascript:>> wrote: > > > > > > > > On Mon, Dec 23, 2019 at 11:42 PM Jeroen Ooms <[email protected] > <javascript:>> wrote: > > > > > > > > > > Hi! > > > > > > > > > > I maintain v8 bindings for the R programming language. As of > recently (I think 7.9) we started getting segfaults at calls to > IsUndefined() and IsNull(). The problem has gotten more prevalent in 8.1. > We're encountered this both on MacOS and Arch Linux. > > > > > > > > > > To produce a minimal example, simply take the official > hello-world.cc and add something like: > > > > > > > > > > if(result->IsUndefined()){ > > > > > printf("value is undefined!"); > > > > > } > > > > > > > > > > Attached a full sample program. Same problem happens for IsNull() > and IsNullOrUndefined(). It does not crash when we compile with > -DV8_ENABLE_CHECKS which enables an alternative implementation of > IsUndefined. > > > > > > > > Your test case looks okay to me. With what specific version(s) are > you > > > > seeing this, does it also reproduce with a debug build of V8 and > what > > > > does `result` contain when you inspect it in gdb or lldb? What does > > > > the backtrace look like in the debug build? > > > > > > Thanks. I'm working from the master branch now (but I think the bug > was introduced around 7.9). It crashes here: > > > > > > Process 25330 stopped > > > * thread #1, queue = 'com.apple.main-thread', stop reason = > EXC_BAD_ACCESS (code=1, address=0x708040ef8) > > > frame #0: 0x0000000100001145 a.out`main [inlined] > v8::internal::Internals::GetInstanceType(obj=47996394545225) at > v8-internal.h:233:12 > > > 230 V8_INLINE static int GetInstanceType(const internal::Address > obj) { > > > 231 typedef internal::Address A; > > > 232 A map = ReadTaggedPointerField(obj, kHeapObjectMapOffset); > > > -> 233 return ReadRawField<uint16_t>(map, kMapInstanceTypeOffset); > > > 234 } > > > 235 > > > 236 V8_INLINE static int GetOddballKind(const internal::Address > obj) { > > > Target 0: (a.out) stopped. > > > > > > (lldb) bt > > > * thread #1, queue = 'com.apple.main-thread', stop reason = > EXC_BAD_ACCESS (code=1, address=0x708040ef8) > > > * frame #0: 0x0000000100001145 a.out`main [inlined] > v8::internal::Internals::GetInstanceType(obj=47996394545225) at > v8-internal.h:233:12 > > > frame #1: 0x00000001000010e4 a.out`main [inlined] > v8::Value::QuickIsUndefined(this=0x0000000104857860) const at v8.h:11310 > > > frame #2: 0x00000001000010a0 a.out`main [inlined] > v8::Value::IsUndefined(this=0x0000000104857860) const at v8.h:11301 > > > frame #3: 0x00000001000010a0 a.out`main(argc=1, > argv=0x00007ffeefbff988) at hello-crash.cc:53 > > > frame #4: 0x00007fff667df7fd libdyld.dylib`start + 1 > > > frame #5: 0x00007fff667df7fd libdyld.dylib`start + 1 > > > > obj=47996394545225 in frame #0 is 0x2ba7080c2049, which looks like a > > valid heap object (heap objects have bit 0 set; if it's clear, it's a > > tagged integer.) > > > > It crashes when trying to read the heap object's map (a.k.a. hidden > > class), the meta-object that describes its "shape." Is it possible > > that you're compiling your test program with a different v8.h than the > > one V8 itself was built with? My first hunch is that the offsets into > > the object header somehow don't match up. > > > > How are you building V8 and how are you compiling and linking the test > program? > > So you cannot reproduce this crash on the v8 master branch? I'm > surprised because one of the arch linux users has reported exactly the > same crash that I see on MacOS, so it really seemed like a bug in v8. > We both use the system clang/libcxx, not the custom ones. > > I use this homebrew recipe to build v8 on MacOS: > https://github.com/jeroen/homebrew-dev/blob/master/Formula/v8.rb . If > you have homebrew you can install it like this: > > brew tap jeroen/dev > brew install jeroen/dev/v8 > > And then compile the example program: > > clang++ -std=c++11 hello-crash.cc -I/usr/local/opt/v8/libexec > -I/usr/local/opt/v8/libexec/include -L/usr/local/opt/v8/libexec -lv8 > -lv8_libplatform > > On Arch we use this to build v8: > https://github.com/JanMarvin/v8-R/blob/master/PKGBUILD > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/b7ee368c-8bca-440d-a8f1-4818a1639b96%40googlegroups.com.
