v8::Isolate::New works on 7.2, fails on 7.3+

[Christopher Nelson]

I have the following code, which works fine on v8 7.2:

isolate::isolate() {
  create_params.array_buffer_allocator =                                                                                                     v8::ArrayBuffer::Allocator::NewDefaultAllocator();                                                                                     i = v8::Isolate::New(create_params);                                                                                                     i->SetData(0, this);                                                                                                                   }                                

However, when run on 7.3+ it yields this:

#0  __memmove_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:321
#1  0x00007ffff7dc66d9 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::append(char const*, unsigned long) () from /lib/x86_64-linux-gnu/libc++.so.1
#2  0x00000000044bbd79 in operator+<char, std::__1::char_traits<char>, std::__1::allocator<char> > () at ../../buildtools/third_party/libc++/trunk/include/string:4147
#3  operator() () at ../../src/interpreter/interpreter.cc:277
#4  __invoke<(lambda at ../../src/interpreter/interpreter.cc:270:19) &, v8::internal::interpreter::Bytecode, v8::internal::interpreter::OperandScale> () at ../../buildtools/third_party/libc++/trunk/include/type_traits:4353
#5  __call<(lambda at ../../src/interpreter/interpreter.cc:270:19) &, v8::internal::interpreter::Bytecode, v8::internal::interpreter::OperandScale> () at ../../buildtools/third_party/libc++/trunk/include/__functional_base:349
#6  operator() () at ../../buildtools/third_party/libc++/trunk/include/functional:1527
#7  __call_impl<std::__1::__function::__alloc_func<(lambda at ../../src/interpreter/interpreter.cc:270:19), std::__1::allocator<(lambda at ../../src/interpreter/interpreter.cc:270:19)>, void (v8::internal::interpreter::Bytecode, v8::internal::interpreter::OperandScale)> > () at ../../buildtools/third_party/libc++/trunk/include/functional:2010
#8  0x00000000044ba5f4 in operator() () at ../../buildtools/third_party/libc++/trunk/include/functional:2123
#9  operator() () at ../../buildtools/third_party/libc++/trunk/include/functional:2347
#10 ForEachBytecode () at ../../src/interpreter/interpreter.cc:251
#11 0x00000000044ba834 in Initialize () at ../../src/interpreter/interpreter.cc:270
#12 0x000000000452aa8b in Init () at ../../src/isolate.cc:3336
#13 0x00000000048f72da in Initialize () at ../../src/snapshot/snapshot-common.cc:50
#14 0x0000000003e2c492 in Initialize () at ../../src/api.cc:8174
#15 0x0000000003e2ca2f in New () at ../../src/api.cc:8196
#16 0x0000000003d986bc in hiram::js::isolate::isolate (this=0x7fffffffcf38) at ../../../../../engine/src/js/isolate.cpp:20
#17 0x0000000003c93997 in ____C_A_T_C_H____T_E_S_T____6 () at ../../../../../engine/test/test_element_node.cpp:62
#18 0x0000000003be6b33 in Catch::TestInvokerAsFunction::invoke (this=0x7326650) at ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:11841
#19 0x0000000003be16d6 in Catch::TestCase::invoke (this=0x738eb00) at ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:11742
#20 0x0000000003be160a in Catch::RunContext::invokeActiveTestCase (this=0x7fffffffd7c8) at ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:10601
#21 0x0000000003be0164 in Catch::RunContext::runCurrentTest (this=0x7fffffffd7c8, redirectedCout=..., redirectedCerr=...) at ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:10574
#22 0x0000000003bdf4fc in Catch::RunContext::runTest (this=0x7fffffffd7c8, testCase=...) at ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:10344
#23 0x0000000003be39fd in Catch::(anonymous namespace)::runTests (config=...) at ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:10903
#24 0x0000000003be34b2 in Catch::Session::runInternal (this=0x7fffffffdb50) at ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:11098
#25 0x0000000003be322b in Catch::Session::run (this=0x7fffffffdb50) at ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:11055
#26 0x0000000003c1257a in Catch::Session::run<char> (this=0x7fffffffdb50, argc=1, argv=0x7fffffffdda8) at ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:10801
#27 0x0000000003bf4c58 in main (argc=1, argv=0x7fffffffdda8) at ../../../../../engine/test/main.cpp:25

I am building on Linux using clang 8, with the following parameters:

v8_build_args = [
        'target_cpu="x64"',
        'is_component_build = false',
        'v8_enable_i18n_support = false',
        'v8_enable_backtrace = true',
        'v8_enable_disassembler = true',
        'v8_enable_object_print = true',
        'v8_enable_verify_heap = true',
        'v8_use_snapshot = true',
        'v8_use_external_startup_data = false',
        'v8_monolithic = true',
]

Any help would be much appreciated.

[Christopher Nelson]

I have found that actually, the problem is that DEBUG builds now throw this error on Linux, whereas release builds are fine. I have tried to determine if there are any flags my app needs to have or to omit when linking against the monolithic V8 lib on linux for debug. Any help would be appreciated!

[Jakob Gruber]

Looks like allocation of the new string here is failing. That code has been there since 71 though.

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/d33b8070-2762-448e-b256-9df272d02224%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dan Elphick]

Does the problem go away if you change the build flags to just target_cpu="x64" and maybe just is_component_build = false? If so can you try adding them back in one at a time to see which one triggers it (I'd probably start with v8_monolithic since the v8_enable_* flags there seem unlikely to be the cause?

To unsubscribe from this group and stop receiving emails from it, send an email to v8-u...@googlegroups.com.

[Jakob Gruber]

On Tue, Jul 16, 2019 at 11:13 AM Dan Elphick <delp...@chromium.org> wrote:

Does the problem go away if you change the build flags to just target_cpu="x64" and maybe just is_component_build = false? If so can you try adding them back in one at a time to see which one triggers it (I'd probably start with v8_monolithic since the v8_enable_* flags there seem unlikely to be the cause?

That reminds me, it could be related to use_custom_libcxx (a mismatch in libcxx used for V8 and the embedding project). Have you tried 'use_custom_libcxx = false'?

 

To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/fad078d3-d8d3-4dab-b451-51145ad1ff62%40googlegroups.com.

[Christopher Nelson]

I didn't. Let me try these suggestions and get back to you all. Thank you!

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/CAH3p7oOKYCWiBaGBH8jbs0rM1Sweie5-%3DJnPPSPZ9MGkaU3whQ%40mail.gmail.com.

[Christopher Nelson]

Thank you so much for the help that has been provided so far. Sadly, I tried both of these suggestions without success.

First, I removed all of the build arguments except:

is_debug = true

target_cpu = "x64"

v8_monolithic = true

v8_enable_i18n_support = false

I built this with much the same results. I also duplicated this problem on macOS with debug. (Release works fine on both platforms.)

I also tried setting "use_custom_libcxx = false", but we use libc++ (the one shipped with clang) on Linux and macOS. I couldn't find a way to tell v8 to set -stdlib libc++ without it also wanting that to be the custom one v8 compiles. If I set this value to false then the flag is omitted and it picks up libstdc++ by default, which results in a lot of link errors.

My colleague and I have managed to duplicate this in the most trivial hello-world program, which just initializes the engine and creates an isolate.

The interesting thing is that the d8 app created by the v8 build is fine. It is only applications that link against the v8 monolith outside the v8 build that experience the problem. We also accidentally noted that if we initialize the engine twice, the problem goes away.

As I say, this wasn't a problem in 7.2, but in 7.3+ it's happening with perfect reproducibility. For the record, here is the backtrace:

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7b5a535 in __GI_abort () at abort.c:79
#2  0x00007ffff7bc1726 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7ce7952 "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007ffff7bc859a in malloc_printerr (str=str@entry=0x7ffff7ce5a9b "free(): invalid pointer") at malloc.c:5352
#4  0x00007ffff7bca3cc in _int_free (av=<optimized out>, p=<optimized out>, have_lock=<optimized out>) at malloc.c:4181
#5  0x0000000004da70e5 in __do_call () at ../../buildtools/third_party/libc++/trunk/include/new:319
#6  __do_deallocate_handle_size () at ../../buildtools/third_party/libc++/trunk/include/new:277
#7  __do_deallocate_handle_size_align () at ../../buildtools/third_party/libc++/trunk/include/new:247
#8  __libcpp_deallocate () at ../../buildtools/third_party/libc++/trunk/include/new:325
#9  deallocate () at ../../buildtools/third_party/libc++/trunk/include/memory:1816
#10 deallocate () at ../../buildtools/third_party/libc++/trunk/include/memory:1554
#11 ~basic_string () at ../../buildtools/third_party/libc++/trunk/include/string:2138
#12 Print () at ../../src/code-stub-assembler.cc:13702
#13 0x00000000051e254d in LoadKeyValuePairNoSideEffects () at gen/torque-generated/builtins-collections-from-dsl-gen.cc:533
#14 0x0000000004cfc7e1 in AddConstructorEntry () at ../../src/builtins/builtins-collections-gen.cc:163
#15 0x0000000004d10fb6 in operator() () at ../../src/builtins/builtins-collections-gen.cc:270
#16 __invoke<(lambda at ../../src/builtins/builtins-collections-gen.cc:267:22) &, v8::internal::compiler::Node *> () at ../../buildtools/third_party/libc++/trunk/include/type_traits:4399
#17 __call<(lambda at ../../src/builtins/builtins-collections-gen.cc:267:22) &, v8::internal::compiler::Node *> () at ../../buildtools/third_party/libc++/trunk/include/__functional_base:348
#18 operator() () at ../../buildtools/third_party/libc++/trunk/include/functional:1531
#19 __call_impl<std::__1::__function::__alloc_func<(lambda at ../../src/builtins/builtins-collections-gen.cc:267:22), std::__1::allocator<(lambda at ../../src/builtins/builtins-collections-gen.cc:267:22)>, void (v8::internal::compiler::Node *)> > () at ../../buildtools/third_party/libc++/trunk/include/functional:2014
#20 0x0000000004d76fb1 in operator() () at ../../buildtools/third_party/libc++/trunk/include/functional:2127
#21 operator() () at ../../buildtools/third_party/libc++/trunk/include/functional:2351
#22 BuildFastLoop () at ../../src/code-stub-assembler.cc:10997
#23 0x0000000004cfd8e0 in BuildFastLoop () at ../../src/code-stub-assembler.h:3062
#24 AddConstructorEntriesFromFastJSArray () at ../../src/builtins/builtins-collections-gen.cc:278
#25 0x0000000004cfcd55 in AddConstructorEntries () at ../../src/builtins/builtins-collections-gen.cc:207
#26 0x0000000004cfeebf in GenerateConstructor () at ../../src/builtins/builtins-collections-gen.cc:416
#27 0x0000000004cff596 in GenerateMapConstructorImpl () at ../../src/builtins/builtins-collections-gen.cc:740
#28 0x0000000004cff3ea in Generate_MapConstructor () at ../../src/builtins/builtins-collections-gen.cc:734
#29 0x0000000004c6b147 in BuildWithCodeStubAssemblerJS () at ../../src/builtins/setup-builtins-internal.cc:179
#30 SetupBuiltinsInternal () at ../../src/builtins/setup-builtins-internal.cc:353
#31 0x0000000004c62687 in SetupBuiltins () at ../../src/setup-isolate-full.cc:18
#32 0x0000000004395524 in Init () at ../../src/isolate.cc:3394
#33 0x0000000004394c4d in v8::internal::Isolate::InitWithoutSnapshot() () at ../../src/isolate.cc:3284
#34 0x0000000003f50007 in Initialize () at ../../src/api.cc:8211
#35 0x0000000003f5055f in New () at ../../src/api.cc:8223
#36 0x0000000003eb369c in hiram::js::isolate::isolate (this=0x7fffffffcf88) at ../../../../../engine/src/js/isolate.cpp:20
#37 0x0000000003dae967 in ____C_A_T_C_H____T_E_S_T____6 () at ../../../../../engine/test/test_element_node.cpp:62
#38 0x0000000003d01b33 in Catch::TestInvokerAsFunction::invoke (this=0x7677650) at ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:11841
#39 0x0000000003cfc6d6 in Catch::TestCase::invoke (this=0x76dfe60) at ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:11742
#40 0x0000000003cfc60a in Catch::RunContext::invokeActiveTestCase (this=0x7fffffffd818) at ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:10601
#41 0x0000000003cfb164 in Catch::RunContext::runCurrentTest (this=0x7fffffffd818, redirectedCout=..., redirectedCerr=...) at ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:10574
#42 0x0000000003cfa4fc in Catch::RunContext::runTest (this=0x7fffffffd818, testCase=...) at ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:10344
#43 0x0000000003cfe9fd in Catch::(anonymous namespace)::runTests (config=...) at ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:10903
#44 0x0000000003cfe4b2 in Catch::Session::runInternal (this=0x7fffffffdb90) at ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:11098
#45 0x0000000003cfe22b in Catch::Session::run (this=0x7fffffffdb90) at ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:11055
#46 0x0000000003d2d54a in Catch::Session::run<char> (this=0x7fffffffdb90, argc=1, argv=0x7fffffffdde8) at ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:10801
#47 0x0000000003d0fc24 in main (argc=1, argv=0x7fffffffdde8) at ../../../../../engine/test/main.cpp:25

This is the content of the main.cpp:

  std::unique_ptr<v8::Platform> platform = v8::platform::NewDefaultPlatform();
  v8::V8::InitializePlatform(platform.get());
  v8::V8::Initialize();

    int result = Catch::Session().run(argc, argv);

    v8::V8::Dispose();
    v8::V8::ShutdownPlatform();

And the code that is failing:

create_params.array_buffer_allocator =
      v8::ArrayBuffer::Allocator::NewDefaultAllocator();
  i = v8::Isolate::New(create_params);

I'm trying more variations, but if there's something else I can do to help anyone help me, I will happily do so.

Thanks again!

[Jakob Gruber]

On Wed, Jul 17, 2019 at 5:48 PM Christopher Nelson <nadias...@gmail.com> wrote:

Thank you so much for the help that has been provided so far. Sadly, I tried both of these suggestions without success.

First, I removed all of the build arguments except:

is_debug = true

target_cpu = "x64"

v8_monolithic = true

v8_enable_i18n_support = false

I built this with much the same results. I also duplicated this problem on macOS with debug. (Release works fine on both platforms.)

I also tried setting "use_custom_libcxx = false", but we use libc++ (the one shipped with clang) on Linux and macOS. I couldn't find a way to tell v8 to set -stdlib libc++ without it also wanting that to be the custom one v8 compiles. If I set this value to false then the flag is omitted and it picks up libstdc++ by default, which results in a lot of link errors.

Just to confirm: are you linking your project against the same custom libcxx that V8 uses? If yes, then we need to start looking elsewhere (than use_custom_libcxx) for the problem. If no, that would still be my suspicion.

Note also how the backtrace below is in a completely different spot in V8 than the one you posted before. And this time in deallocate (before it was in an allocation).

--

--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/f81d746d-0ced-4841-8736-ed5d8ef90bc0%40googlegroups.com.

[Christopher Nelson]

I'm not using the same exact libc++, no. I don't have a problem doing that, but I'd like to link v8 against MY libc++ instead of linking my app against v8's libc++. The reason is:  I am compiling against a number of libraries, all of which are compiled against my libc++. Trying to change them all to compile against V8's libc++ is probably not possible.

I'm also a little suspicious that libc++ is the problem here because it works fine in release; which I would expect to be _more_ sensitive. In any case, if you can tell me how or point me to instructions on how to tell V8 which libc++ to use I will very happily implement that.

To unsubscribe from this group and stop receiving emails from it, send an email to v8-u...@googlegroups.com.

[Jakob Gruber]

On Thu, Jul 18, 2019 at 2:32 PM Christopher Nelson <nadias...@gmail.com> wrote:

I'm not using the same exact libc++, no. I don't have a problem doing that, but I'd like to link v8 against MY libc++ instead of linking my app against v8's libc++. The reason is:  I am compiling against a number of libraries, all of which are compiled against my libc++. Trying to change them all to compile against V8's libc++ is probably not possible.

I'm also a little suspicious that libc++ is the problem here because it works fine in release; which I would expect to be _more_ sensitive. In any case, if you can tell me how or point me to instructions on how to tell V8 which libc++ to use I will very happily implement that.

I assume building with a libcxx that is neither the system libcxx nor V8's custom libcxx will need manual work. I'm not an expert on this either, I've just seen folks run into this fairly frequently in recent times. 

Here's where all of my infos come from: https://crbug.com/v8/9150#c2. Maybe this will help clarify.

 

To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/945801a6-ddce-42c2-9dc4-44334cb794f5%40googlegroups.com.

[Christopher Nelson]

I appreciate that info, and I have read it. However, that is very unlikely to be the problem here. In this case I am not passing any C++ ABI objects between libraries, I'm just creating a new isolate. The reproduction is so minimal and so simple that is seems very unlikely that libc++ is at fault here. It happens deep inside the isolate initialization.

[Jakob Gruber]

On Thu, Jul 18, 2019 at 3:10 PM Christopher Nelson <nadias...@gmail.com> wrote:

I appreciate that info, and I have read it. However, that is very unlikely to be the problem here. In this case I am not passing any C++ ABI objects between libraries, I'm just creating a new isolate. The reproduction is so minimal and so simple that is seems very unlikely that libc++ is at fault here. It happens deep inside the isolate initialization.

I see. It sounds like you have a full repro to share; could you perhaps open a bug at crbug.com/v8/new, include the repro, and I will try to have a look next week. 

 

To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/30e33f59-8f7d-4022-9d31-c3d5eb025fba%40googlegroups.com.

[Christopher Nelson]

I will do that. However, I think I now have to repent is dust and ashes. I tried a use_custom_libcxx = false on macOS where it is easier to do, and code that was failing is now passing on that system. That makes me very sad because, as I said, the repro is very, very small. This makes me a little nervous about the wisdom of V8 embedding it's own libc++. I am literally initializing the platform, engine, and creating an isolate. There is no reason for my libc++ to interact with V8's at all... :-(

This is also a problem because we use libc++ on Linux and I can't see anyway to get that to work on v8 without hacking the v8 build system.

I will perform some more tests on macOS to be sure this fixes the problem, but so far it looks good...

[Christopher Nelson]

Since this does seem to have fixed the problem on macOS, I wondered why it might be a problem. It looks to me like the libc++ being built is built in Release+Asserts mode even when I ask for v8 to be built in debug mode. I wonder if this ends up being the problem when debug code is expecting one thing, but instead it is getting a release version.

In any case, I think that I am going to look into modifying the GN build for v8 to allow using the default or "system" libc++ instead of just being able to use the "default" c++ standard library or the custom libc++ library. If you or anyone else can give me some guidance on that, I'd be happy to contribute it back. I'm sure I can't be the only person this has bitten and frustrated.

Thanks again for all the help!

[Jakob Gruber]

Glad it helped!

On Fri, Jul 19, 2019 at 3:13 PM Christopher Nelson <nadias...@gmail.com> wrote:

Since this does seem to have fixed the problem on macOS, I wondered why it might be a problem. It looks to me like the libc++ being built is built in Release+Asserts mode even when I ask for v8 to be built in debug mode. I wonder if this ends up being the problem when debug code is expecting one thing, but instead it is getting a release version.

In any case, I think that I am going to look into modifying the GN build for v8 to allow using the default or "system" libc++ instead of just being able to use the "default" c++ standard library or the custom libc++ library. If you or anyone else can give me some guidance on that, I'd be happy to contribute it back. I'm sure I can't be the only person this has bitten and frustrated.

 Nico fyi.

 

Thanks again for all the help!

On Thursday, July 18, 2019 at 9:52:49 AM UTC-4, Jakob Gruber wrote:

On Thu, Jul 18, 2019 at 3:10 PM Christopher Nelson <nadias...@gmail.com> wrote:

I appreciate that info, and I have read it. However, that is very unlikely to be the problem here. In this case I am not passing any C++ ABI objects between libraries, I'm just creating a new isolate. The reproduction is so minimal and so simple that is seems very unlikely that libc++ is at fault here. It happens deep inside the isolate initialization.

I see. It sounds like you have a full repro to share; could you perhaps open a bug at crbug.com/v8/new, include the repro, and I will try to have a look next week. 

 

On Thursday, July 18, 2019 at 8:43:42 AM UTC-4, Jakob Gruber wrote:

On Thu, Jul 18, 2019 at 2:32 PM Christopher Nelson <nadias...@gmail.com> wrote:

I'm not using the same exact libc++, no. I don't have a problem doing that, but I'd like to link v8 against MY libc++ instead of linking my app against v8's libc++. The reason is:  I am compiling against a number of libraries, all of which are compiled against my libc++. Trying to change them all to compile against V8's libc++ is probably not possible.

I'm also a little suspicious that libc++ is the problem here because it works fine in release; which I would expect to be _more_ sensitive. In any case, if you can tell me how or point me to instructions on how to tell V8 which libc++ to use I will very happily implement that.

I assume building with a libcxx that is neither the system libcxx nor V8's custom libcxx will need manual work. I'm not an expert on this either, I've just seen folks run into this fairly frequently in recent times. 

Here's where all of my infos come from: https://crbug.com/v8/9150#c2. Maybe this will help clarify.

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/b77de9a9-2b84-4726-a411-5eb3a4eb5894%40googlegroups.com.