Re: [v8-users] Re: Memory Leak in `v8::Isolate::New(v8::Isolate::CreateParams const&)`

[Dan Elphick]

I've attempted to reproduce with your sample code and I can't get it to
work. I modified samples/hello-world.cc and changed main to this:

int main(int argc, char* argv[]) {
  std::unique_ptr platform =
v8::platform::NewDefaultPlatform();
  v8::V8::InitializePlatform(platform.get());
  v8::V8::Initialize();
  v8::Isolate::CreateParams create_params;
  auto* allocator_ = create_params.array_buffer_allocator =
  v8::ArrayBuffer::Allocator::NewDefaultAllocator();
  v8::Isolate* isolate_ = v8::Isolate::New(create_params);

  isolate_->Dispose();
  delete allocator_;
  printf("%p\n", malloc(123));
  return 0;
}

built it with "ninja -C out/asan v8_hello_world" and ran it with
ASAN_OPTIONS=detect_leaks=1 out/asan/v8_hello_world

This shows the memory leak for my spurious malloc but no others. My gn args
are the same as the ones you listed except I added is_asan=true. That's
probably not quite the same as what you have since this results in a
statically linked binary but I'm not sure that would make a difference.

Is there any more detail you could give me? Exact repro code/build steps?

Thanks,
Dan

-- 
-- 
v8-users mailing list
v8-users@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CALH_77tsuAanJjNsNPmyUGqmiOSjtCxM0iYqNUp7xFONt7jPdw%40mail.gmail.com.

Re: [v8-users] Re: Memory Leak in `v8::Isolate::New(v8::Isolate::CreateParams const&)`

[Dan Elphick]

Thanks for the report. This may be a bogus report (in that the memory isn't
actually leaked) because we use mmap to allocate our memory for
MemoryChunks, which means LeakSanitiser doesn't see that there is a
connection to the memory pointed to by the MemoryChunk. Alternatively I've
created a real leak and this needs addressing.

I'm actively working on this code right now and will take a look at it. It
looks like it's related to read-only space sharing which is disabled by
pointer compression (which you in turn have disabled), which is probably
why our bots missed it.

Thanks,
Dan

On Wed, 17 Jun 2020 at 13:46, Immanuel Haffner 
wrote:

> I create an instance with
>
> v8::Isolate::CreateParams create_params;
> create_params.array_buffer_allocator = allocator_ =
> v8::ArrayBuffer::Allocator::NewDefaultAllocator();
> isolate_ = v8::Isolate::New(create_params);
>
> and dispose of it with
>
> isolate_->Dispose();
> delete allocator_;
>
>
> Immanuel Haffner schrieb am Mittwoch, 17. Juni 2020 um 14:44:33 UTC+2:
>
>> Build args are
>>
>> is_clang=true is_component_build=false v8_monolithic=true
>> v8_enable_pointer_compression=false treat_warnings_as_errors=false
>> v8_use_external_startup_data=false use_sysroot=false
>> use_custom_libcxx=false clang_use_chrome_plugins=false
>> target_cpu="x64" is_debug=true use_debug_fission=true
>>
>> Immanuel Haffner schrieb am Mittwoch, 17. Juni 2020 um 14:43:51 UTC+2:
>>
>>> Hi all,
>>>
>>> after upgrading to v8.5.183 the LeakSanitizer of clang detects a memory
>>> leak in embedded V8:
>>>
>>> ==145652==ERROR: LeakSanitizer: detected memory leaks
>>>
>>> Direct leak of 12300 byte(s) in 3 object(s) allocated from:
>>> #0 0x562b902d2ff1 in calloc
>>> (/home/immanuel/Documents/Work/PhD/mutable/mutable/build/debug/bin/shell+0x11b2ff1)
>>> #1 0x562b91eb83fe in
>>> v8::internal::BasicMemoryChunk::Initialize(v8::internal::Heap*, unsigned
>>> long, unsigned long, unsigned long, unsigned long, v8::internal::Space*,
>>> v8::internal::VirtualMemory)
>>> ../../../../../third-party/v8/v8/src/heap/basic-memory-chunk.cc:31:42
>>> #2 0x562b90fe3740 in
>>> v8::internal::MemoryChunk::Initialize(v8::internal::Heap*, unsigned long,
>>> unsigned long, unsigned long, unsigned long, v8::internal::Executability,
>>> v8::internal::Space*, v8::internal::VirtualMemory)
>>> ../../../../../third-party/v8/v8/src/heap/memory-chunk.cc:176:3
>>> #3 0x562b90fddaa6 in
>>> v8::internal::MemoryAllocator::AllocateChunk(unsigned long, unsigned long,
>>> v8::internal::Executability, v8::internal::Space*)
>>> ../../../../../third-party/v8/v8/src/heap/memory-allocator.cc:491:7
>>> #4 0x562b90fdd5a3 in v8::internal::Page*
>>> v8::internal::MemoryAllocator::AllocatePage<(v8::internal::MemoryAllocator::AllocationMode)0,
>>> v8::internal::PagedSpace>(unsigned long, v8::internal::PagedSpace*,
>>> v8::internal::Executability)
>>> ../../../../../third-party/v8/v8/src/heap/memory-allocator.cc:617:13
>>> #5 0x562b91002712 in v8::internal::PagedSpace::Expand()
>>> ../../../../../third-party/v8/v8/src/heap/paged-spaces.cc:336:38
>>> #6 0x562b91005bcf in
>>> v8::internal::PagedSpace::RawSlowRefillLinearAllocationArea(int,
>>> v8::internal::AllocationOrigin)
>>> ../../../../../third-party/v8/v8/src/heap/paged-spaces.cc:974:18
>>> #7 0x562b910058ba in
>>> v8::internal::PagedSpace::SlowRefillLinearAllocationArea(int,
>>> v8::internal::AllocationOrigin)
>>> ../../../../../third-party/v8/v8/src/heap/paged-spaces.cc:902:10
>>> #8 0x562b90f2ffea in
>>> v8::internal::PagedSpace::AllocateRawUnaligned(int,
>>> v8::internal::AllocationOrigin)
>>> ../../../../../third-party/v8/v8/src/heap/paged-spaces-inl.h:98:10
>>> #9 0x562b90f4e53d in
>>> v8::internal::Heap::ReserveSpace(std::vector>> std::allocator >*, std::vector>> std::allocator >*)
>>> ../../../../../third-party/v8/v8/src/heap/heap.cc:1982:46
>>> #10 0x562b9204daa6 in
>>> v8::internal::DeserializerAllocator::ReserveSpace()
>>> ../../../../../third-party/v8/v8/src/snapshot/deserializer-allocator.cc:179:31
>>> #11 0x562b913d5e31 in
>>> v8::internal::ReadOnlyDeserializer::DeserializeInto(v8::internal::Isolate*)
>>> ../../../../../third-party/v8/v8/src/snapshot/read-only-deserializer.cc:20:21
>>> #12 0x562b91007f9e in
>>> v8::internal::ReadOnlyHeap::SetUp(v8::internal::Isolate*,
>>> v8::internal::ReadOnlyDeserializer*)
>>> ../../../../../third-party/v8/v8/src/heap/read-only-heap.cc:119:8
>>> #13 0x562b90ec89ee in
>>> v8::internal::Isolate::Init(v8::internal::ReadOnlyDeserializer*,
>>> v8::internal::StartupDeserializer*)
>>> ../../../../../third-party/v8/v8/src/execution/isolate.cc:3378:3
>>> #14 0x562b90ec98ca in
>>> v8::internal::Isolate::InitWithSnapshot(v8::internal::ReadOnlyDeserializer*,
>>> v8::internal::StartupDeserializer*)
>>> ../../../../../third-party/v8/v8/src/execution/isolate.cc:3277:10
>>> #15 0x562b913f4765 in
>>> v8::internal::Snapshot::Initialize(v8::internal::Isolate*)
>>> 

Re: [v8-users] Stacktrace performance

[Dan Elphick]

When I ran the test in d8 (unfortunately I didn't keep the old binaries
around so can't quickly verify) I saw at most a 10% difference between 7.1
vs 7.9.

Is this manifesting somewhere other than in your micro benchmark? Because
this looks to be pretty much the worst case scenario, the function doesn't
do anything except construct an Error object which requires constructing a
stack trace and it needs to build 9 frames each time, but unless this is
causing a problem in real code, I'm not sure how much attention it warrants.

On Wed, 12 Feb 2020 at 14:42, Wilfried Gösgens  wrote:

> This 600x slowdown was inside of arangosh due to pasting - its not there
> anymore in the numbers of my previous post - sorry I didn't mention it
> explicitely.
>
> However, if you compare the numbers of my previous post, there still is an
> offset of ~40% which I'd still call significant?
>
> --
> --
> v8-users mailing list
> v8-users@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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/cdeb797d-c2e3-4a8d-924f-cd484159e18f%40googlegroups.com
> 
> .
>

-- 
-- 
v8-users mailing list
v8-users@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CALH_77uxkpFEZrNVa01oYO1hEAd96-nu-Y05w6udnFOrh%3D3YUQ%40mail.gmail.com.

Re: [v8-users] Stacktrace performance

[Dan Elphick]

I've built v8's d8 at 7.1, 7.9 and HEAD and 7.1 is a little faster for the
test you posted in your first email, but there's not much in it. Certainly
nothing near the 600x slowdown you had. I wonder if you're setting any
other flags either at runtime or build time?

On Wed, 12 Feb 2020 at 12:28, Wilfried Gösgens  wrote:

> Hi,
> for the json tests the results are looking really promising (its this ~2MB
> sized file:
> https://github.com/arangodb/arangodb/tree/devel/js/apps/system/_admin/aardvark/APP
> )
>
> However, all the throw tests don't look as good.
> `--no-enable-lazy-source-positions` doesn't bring me in the range of the
> older V8; am I missing something about my tiny test program?
>
> Arangodb 3.6.1:  (V8 7.1)
> docker -v /tmp/:/tmp/ run -it arangodb:3.6.1 /bin/sh
>
> cd /usr/share/arangodb3; /usr/bin/arangosh --javascript.execute /tmp/test.js
> JSON parse: 11.244979858398438
> stack frames A: 0.0011951923370361328
> stack frames B: 0.009842529296875
> stack frames c: 0.0015842914581298828
> stack frames c: 0.0014750957489013672
> stack frames d: 0.0006735324859619141
>
> stack frames d: 0.0005927085876464844
>
>
> devel: (V8 7.9)
> docker run -v /tmp/:/tmp/ -it arangodb/arangodb-preview:devel-nightly /bin
> /sh
>
> cd /usr/share/arangodb3; /usr/bin/arangosh
> '--javascript.v8-options=--enable-lazy-source-positions' --javascript.execute
> /tmp/test.js
>
>
>
> JSON parse: 4.552847385406494
> stack frames A: 0.001809835433959961
> stack frames B: 0.0014481544494628906
> stack frames c: 0.0021665096282958984
> stack frames c: 0.002079486846923828
> stack frames d: 0.0009906291961669922
> stack frames d: 0.001043081283569336
>
>
>
> cd /usr/share/arangodb3; /usr/bin/arangosh
> '--javascript.v8-options=--no-enable-lazy-source-positions' 
> --javascript.execute
> /tmp/test.js
>
>
> JSON parse: 4.576668739318848
> stack frames A: 0.0018227100372314453
> stack frames B: 0.0014328956604003906
> stack frames c: 0.0021677017211914062
> stack frames c: 0.002074718475341797
> stack frames d: 0.0009608268737792969
> stack frames d: 0.0008444786071777344
>
>
>
> cheers,
> Willi
>
> On Monday, February 10, 2020 at 5:03:29 PM UTC+1, Dan Elphick wrote:
>>
>> It sounds like you're talking about lazy source positions, but the code
>> you've listed there shouldn't be affected by that since it never symbolizes
>> a stack trace. You could confirm that by disabling it with the flag
>> --no-enable-lazy-source-positions.
>>
>> If you added "var a = x.stack;" to your test8 function then it would
>> trigger symbolization (without printing it), since stack is actually a
>> function masquerading as a variable and so even accessing it will trigger
>> source position collection. I would then expect the first iteration to be
>> slower as it reparses, but then subsequent iterations would be fast.
>>
>> Dan
>>
>> On Mon, 10 Feb 2020 at 15:20, Wilfried Gösgens  wrote:
>>
>>> Hi,
>>> reading the changelog I saw that many things changed about stacktrace
>>> generation in the recent V8 versions, which should change the performance
>>> of generating the error instance?
>>> I've tried this simple test with arangodb's arangosh and its embedded V8
>>> versions 7.1 and 7.9:
>>>
>>> function test1() {
>>>   function test2() {
>>> function test3() {
>>>   function test4() {
>>> function test5() {
>>>   function test6() {
>>> function test7() {
>>>   function test8() {
>>> x= new Error;
>>> return 1;
>>>   }
>>>   return test8();
>>> }
>>> return test7();
>>>   }
>>>   return test6();
>>> }
>>> return test5();
>>>   }
>>>   return test4();
>>> }
>>> return test3();
>>>   }
>>>   return test2();
>>> }
>>>
>>> before = time();
>>> for (let i = 1; i < 50; i ++) {
>>>   test1();
>>> }
>>> print(time() - before);
>>>
>>>
>>> 7.1:  - (as in ArangoDB 3.6) 0.0012750625610351562
>>> 7.9: - (as in current devel) 0.6016845703125
>>>
>>> The figures are similar when I throw the error and catch it inside that
>>> for loop.
>>> I've read that later V8 reparses the source in order to get the
>>> printeable stacktrace; is this what gives such 

Re: [v8-users] Stacktrace performance

[Dan Elphick]

It sounds like you're talking about lazy source positions, but the code
you've listed there shouldn't be affected by that since it never symbolizes
a stack trace. You could confirm that by disabling it with the flag
--no-enable-lazy-source-positions.

If you added "var a = x.stack;" to your test8 function then it would
trigger symbolization (without printing it), since stack is actually a
function masquerading as a variable and so even accessing it will trigger
source position collection. I would then expect the first iteration to be
slower as it reparses, but then subsequent iterations would be fast.

Dan

On Mon, 10 Feb 2020 at 15:20, Wilfried Gösgens  wrote:

> Hi,
> reading the changelog I saw that many things changed about stacktrace
> generation in the recent V8 versions, which should change the performance
> of generating the error instance?
> I've tried this simple test with arangodb's arangosh and its embedded V8
> versions 7.1 and 7.9:
>
> function test1() {
>   function test2() {
> function test3() {
>   function test4() {
> function test5() {
>   function test6() {
> function test7() {
>   function test8() {
> x= new Error;
> return 1;
>   }
>   return test8();
> }
> return test7();
>   }
>   return test6();
> }
> return test5();
>   }
>   return test4();
> }
> return test3();
>   }
>   return test2();
> }
>
> before = time();
> for (let i = 1; i < 50; i ++) {
>   test1();
> }
> print(time() - before);
>
>
> 7.1:  - (as in ArangoDB 3.6) 0.0012750625610351562
> 7.9: - (as in current devel) 0.6016845703125
>
> The figures are similar when I throw the error and catch it inside that
> for loop.
> I've read that later V8 reparses the source in order to get the printeable
> stacktrace; is this what gives such a worse performance here?
> If yes, which way is one to achieve similar / faster performance with
> recent V8 versions?
>
> Cheers,
> Willi
>
> --
> --
> v8-users mailing list
> v8-users@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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/f27ad537-86c5-4f3e-be8c-b25b73dea7af%40googlegroups.com
> 
> .
>

-- 
-- 
v8-users mailing list
v8-users@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CALH_77sAzkDMDa-1h3p0e4T8XbDK9-Z6WNJXRqk%3DJuu1qquXLw%40mail.gmail.com.

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

[Dan Elphick]

My suggested fix there doesn't seem to work MSVC non-component builds so
probably won't work for component builds either. I think
https://chromium-review.googlesource.com/c/v8/v8/+/1918249 should work.

On Fri, 15 Nov 2019 at 15:05, Dan Elphick  wrote:

> No worries. You're finding real bugs which clang/gcc which don't show up
> with clang/gcc because of the way they do dll import/exports.
>
> In this case there's a missing inline keyword at:
>
> https://cs.chromium.org/chromium/src/v8/src/objects/hash-table.h?sq=package:chromium=0=150
>
> It should be:
> static *inline* bool IsKey
> <https://cs.chromium.org/chromium/src/v8/src/objects/hash-table.h?l=150=kythe%253A%252F%252Fchromium.googlesource.com%252Fchromium%252Fsrc%253Flang%253Dc%25252B%25252B%253Fpath%253Dsrc%252Fv8%252Fsrc%252Fobjects%252Fhash-table.h%2523QjdXsBUmVONrf0Gu9SJVCuXfXWKN9vtEFvKVl2ekWCI%2Bkythe%253A%252F%252Fchromium.googlesource.com%252Fchromium%252Fsrc%253Flang%253Dc%25252B%25252B%253Fpath%253Dsrc%252Fv8%252Fsrc%252Fobjects%252Fhash-table.h%2523UOF2H0st5qB__C7dy6rzK0z-foN2lvHyomBSlq-N_aA%2Bkythe%253A%252F%252Fchromium.googlesource.com%252Fchromium%252Fsrc%253Flang%253Dc%25252B%25252B%253Fpath%253Dsrc%252Fv8%252Fsrc%252Fobjects%252Fhash-table.h%2523Ir1Uhuuh9q-FacxbysFblDqzwPVdszv8FH6UmBjaUTI=IsKey=xref_usages>
> (ReadOnlyRoots
> <https://cs.chromium.org/chromium/src/v8/src/roots/roots.h?l=475=xref_jump_to_def=ReadOnlyRoots>
> roots
> <https://cs.chromium.org/chromium/src/v8/src/objects/hash-table.h?l=150=kythe%253A%252F%252Fchromium.googlesource.com%252Fchromium%252Fsrc%253Flang%253Dc%25252B%25252B%253Fpath%253Dsrc%252Fv8%252Fsrc%252Fobjects%252Fhash-table.h%2523fgsylI_uMJUkIWzvNKqe0xuuFjPRJixagIekxAilv8Q%2Bkythe%253A%252F%252Fchromium.googlesource.com%252Fchromium%252Fsrc%253Flang%253Dc%25252B%25252B%253Fpath%253Dsrc%252Fv8%252Fsrc%252Fobjects%252Fhash-table.h%2523dWaVgckFIDQzDkxollbPP1rFmxTpiLrderq0bS6TFDM%2Bkythe%253A%252F%252Fchromium.googlesource.com%252Fchromium%252Fsrc%253Flang%253Dc%25252B%25252B%253Fpath%253Dsrc%252Fv8%252Fsrc%252Fobjects%252Fhash-table.h%2523A1FQg9bNiX9Iu_b1BahDB8eXqwozdCuHoEwK92qJ2rM=roots=xref_usages>,
> Object
> <https://cs.chromium.org/chromium/src/v8/src/objects/objects.h?l=270=xref_jump_to_def=Object>
> k
> <https://cs.chromium.org/chromium/src/v8/src/objects/hash-table.h?l=150=kythe%253A%252F%252Fchromium.googlesource.com%252Fchromium%252Fsrc%253Flang%253Dc%25252B%25252B%253Fpath%253Dsrc%252Fv8%252Fsrc%252Fobjects%252Fhash-table.h%2523BrIHkkHzh9_LlxG-4BQgaJ-ldyG7tueUfddGD4rkuYE%2Bkythe%253A%252F%252Fchromium.googlesource.com%252Fchromium%252Fsrc%253Flang%253Dc%25252B%25252B%253Fpath%253Dsrc%252Fv8%252Fsrc%252Fobjects%252Fhash-table.h%2523CayiEZZehZYGiOqvrvIH0qPW8Evh2z6zyTBria7tz1Q%2Bkythe%253A%252F%252Fchromium.googlesource.com%252Fchromium%252Fsrc%253Flang%253Dc%25252B%25252B%253Fpath%253Dsrc%252Fv8%252Fsrc%252Fobjects%252Fhash-table.h%2523zHzy3uxbjnxXB2YRKbItLX3wzBE6yLqNhDm4_8NVeLA=k=xref_usages>
> );
>
> I'll upload a fix for this one, but I'm not likely to have time to spend
> on MSVC builds (since we don't officially support them), so probably won't
> do much else. If anything else is required, then please feel free to upload
> your own changes and I'll be happy to review them.
>
> Thanks,
> Dan
>
> On Fri, 15 Nov 2019 at 14:33, Ben Ernst  wrote:
>
>> Dan,
>> I resynced with your landed changes, and reverted 7186b6 as you
>> suggested. I encounter the error message below. As ever, I appreciate your
>> ongoing correspondence, I am sure it must be a painful process.
>> Ben
>>
>>  [exec] FAILED: obj/d8/async-hooks-wrapper.obj
>>  [exec] ninja -t msvc -e environment.x64 -- "C:\Program Files
>> (x86)\Microsoft Visual
>> Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64/cl.exe"
>> /nologo /showIncludes -DUSE_AURA=1 -D_HAS_EXCEPTIONS=0 -DCOMPONENT_BUILD
>> -D__STD_C -D_CRT_RAND_S -D_CRT_SECURE_NO_DEPRECATE
>> -D_SCL_SECURE_NO_DEPRECATE -D_ATL_NO_OPENGL -D_WINDOWS
>> -DCERT_CHAIN_PARA_HAS_EXTRA_FIELDS -DPSAPI_VERSION=2 -DWIN32 -D_SECURE_ATL
>> -D_USING_V110_SDK71_ -DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP
>> -DWIN32_LEAN_AND_MEAN -DNOMINMAX -D_UNICODE -DUNICODE
>> -DNTDDI_VERSION=NTDDI_WIN10_RS2 -D_WIN32_WINNT=0x0A00 -DWINVER=0x0A00
>> -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0
>> -DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64 -DENABLE_MINOR_MC
>> -DENABLE_HANDLE_ZAPPING -DV8_CONCURRENT_MARKING
>> -DV8_ENABLE_LAZY_SOURCE_POSITIONS -DV8_EMBEDDED_BUILTINS
>> -DV8_SHARED_RO_HEAP -DV8_WIN64_UNWINDING_INFO
>> -DV8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH
>> -DV8_31BIT_SMIS_ON_64BIT_ARCH -DV8_DEPRECATION_WARNINGS
>> -DV8_IMMINENT_DEPRECATION_WARNINGS -DV8_TARGET_ARCH_X64 -DV8_HAVE_TARGET_OS
>> -

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

[Dan Elphick]

0 /wd4121 /wd4244 /wd4505 /wd4510 /wd4512 /wd4610 /wd4838 /wd4995
> /wd4996 /wd4456 /wd4457 /wd4458 /wd4459 /wd4200 /wd4201 /wd4204 /wd4221
> /wd4245 /wd4267 /wd4305 /wd4389 /wd4702 /wd4701 /wd4703 /wd4661 /wd4706
> /wd4715 /Zi /MD /wd4245 /wd4267 /wd4324 /wd4701 /wd4702 /wd4703 /wd4709
> /wd4714 /wd4715 /wd4718 /wd4723 /wd4724 /wd4800 /O2 /Ob2 /Oy- /Zc:inline
> /Gw /TP /wd4577 /GR- /c ../../src/d8/async-hooks-wrapper.cc
> /Foobj/d8/async-hooks-wrapper.obj /Fd"obj/d8_cc.pdb"
>  [exec] C:\fd22cbe1\v8\src/objects/hash-table-inl.h(166): error C2491:
> 'v8::internal::HashTable::IsKey': definition of dllimport
> function not allowed
>
> On Saturday, 16 November 2019 00:42:59 UTC+10:30, Dan Elphick wrote:
>>
>> On 8.0, it looks like your errors are down to converting the return value
>> of ElementSizeLog2Of to uint8_t. Not sure why that's giving you an error
>> but triggering on the bots but you could try reverting
>> 7186b60147911736cdd385c787e6fd5e86052cb5
>> <https://chromium-review.googlesource.com/c/v8/v8/+/1914215> locally and
>> see if that works.
>>
>> My changes are now landed so you should be able to revert those local
>> changes and resync.
>>
>> On Fri, 15 Nov 2019 at 13:56, Ben Ernst  wrote:
>>
>>> Dan,
>>> My build on "master" (8.0) failed, but probably for reasons unrelated to
>>> your changes.
>>> I did my best to merge your changes to 7.9, I think I merged the changes
>>> correctly, but the compilation fails. It's possible that my merge is at
>>> fault though.
>>> I've attached both logs in case they are useful.
>>> Regards,
>>> Ben
>>>
>>> On Friday, 15 November 2019 03:21:38 UTC+10:30, Clemens Hammacher wrote:
>>>>
>>>> FYI: There is an open bug about cleaning up utils.h
>>>> <https://crbug.com/v8/8912>, and I worked a bit on that last Friday,
>>>> but did not get to split out the BitField class, and others. Thanks for
>>>> taking this over!
>>>>
>>>>
>>>> On Thu, Nov 14, 2019 at 4:55 PM Dan Elphick 
>>>> wrote:
>>>>
>>>>> The utils.h header file is a bit of a mess. I've just uploaded (but
>>>>> not yet committed)
>>>>> https://chromium-review.googlesource.com/c/v8/v8/+/1916604, which
>>>>> splits out the parts of that used by the problematic executable. I've
>>>>> checked the preprocessor output on Linux and it looks like it's not
>>>>> declaring any export symbols that aren't defined so that should work, but 
>>>>> I
>>>>> can't easily test this on MSVC, so please let me know if you have any
>>>>> further problems.
>>>>>
>>>>> This should be applied on top of the previous change and also it's
>>>>> based on master so may not apply cleanly to 7.8.
>>>>>
>>>>> On Thu, 14 Nov 2019 at 12:41, Ben Ernst  wrote:
>>>>>
>>>>>> Dan, I have attached the preprocessor output, following the same
>>>>>> directions as before. Many enthusiastic thanks for your help, I'm deeply
>>>>>> grateful. Ben.
>>>>>>
>>>>>> On Thursday, 14 November 2019 22:53:52 UTC+10:30, Ben Ernst wrote:
>>>>>>>
>>>>>>> Dan, the patch very nearly did the trick, there's just one last
>>>>>>> unresolved external symbol. Ben.
>>>>>>>
>>>>>>>  [exec] [5/686] LINK bytecode_builtins_list_generator.exe
>>>>>>> bytecode_builtins_list_generator.exe.pdb
>>>>>>>  [exec] FAILED: bytecode_builtins_list_generator.exe
>>>>>>> bytecode_builtins_list_generator.exe.pdb
>>>>>>>  [exec]
>>>>>>> C:/32cfab25/depot_tools/bootstrap-3_8_0b1_chromium_1_bin/python/bin/python.exe
>>>>>>> ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64
>>>>>>> False link.exe /nologo /OUT:./bytecode_builtins_list_generator.exe
>>>>>>> /PDB:./bytecode_builtins_list_generator.exe.pdb
>>>>>>> @./bytecode_builtins_list_generator.exe.rsp
>>>>>>>  [exec] generate-bytecodes-builtins-list.obj : error LNK2019:
>>>>>>> unresolved external symbol "public: void __cdecl
>>>>>>> v8::internal::VirtualMemory::Reset(void)" (?Reset@VirtualMemory
>>>>>>> @internal@v8@@QEAAXXZ) referenced in function &qu

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

[Dan Elphick]

The utils.h header file is a bit of a mess. I've just uploaded (but not yet
committed) https://chromium-review.googlesource.com/c/v8/v8/+/1916604,
which splits out the parts of that used by the problematic executable. I've
checked the preprocessor output on Linux and it looks like it's not
declaring any export symbols that aren't defined so that should work, but I
can't easily test this on MSVC, so please let me know if you have any
further problems.

This should be applied on top of the previous change and also it's based on
master so may not apply cleanly to 7.8.

On Thu, 14 Nov 2019 at 12:41, Ben Ernst  wrote:

> Dan, I have attached the preprocessor output, following the same
> directions as before. Many enthusiastic thanks for your help, I'm deeply
> grateful. Ben.
>
> On Thursday, 14 November 2019 22:53:52 UTC+10:30, Ben Ernst wrote:
>>
>> Dan, the patch very nearly did the trick, there's just one last
>> unresolved external symbol. Ben.
>>
>>  [exec] [5/686] LINK bytecode_builtins_list_generator.exe
>> bytecode_builtins_list_generator.exe.pdb
>>  [exec] FAILED: bytecode_builtins_list_generator.exe
>> bytecode_builtins_list_generator.exe.pdb
>>  [exec]
>> C:/32cfab25/depot_tools/bootstrap-3_8_0b1_chromium_1_bin/python/bin/python.exe
>> ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64
>> False link.exe /nologo /OUT:./bytecode_builtins_list_generator.exe
>> /PDB:./bytecode_builtins_list_generator.exe.pdb
>> @./bytecode_builtins_list_generator.exe.rsp
>>  [exec] generate-bytecodes-builtins-list.obj : error LNK2019:
>> unresolved external symbol "public: void __cdecl
>> v8::internal::VirtualMemory::Reset(void)" (?Reset@VirtualMemory
>> @internal@v8@@QEAAXXZ) referenced in function "public: __cdecl
>> v8::internal::VirtualMemory::VirtualMemory(class
>> v8::internal::VirtualMemory &&)" (??0VirtualMemory@internal@v8@@QEAA@
>> $$QEAV012@@Z)
>>  [exec]
>>  [exec]
>>  [exec] bytecode-operands.obj : error LNK2001: unresolved external
>> symbol "public: void __cdecl v8::internal::VirtualMemory::Reset(void)"
>> (?Reset@VirtualMemory@internal@v8@@QEAAXXZ)
>>  [exec]
>>  [exec]
>>  [exec] bytecodes.obj : error LNK2001: unresolved external symbol
>> "public: void __cdecl v8::internal::VirtualMemory::Reset(void)"
>> (?Reset@VirtualMemory@internal@v8@@QEAAXXZ)
>>  [exec]
>>  [exec]
>>  [exec] ./bytecode_builtins_list_generator.exe : fatal error LNK1120:
>> 1 unresolved externals
>>  [exec]
>>  [exec]
>>  [exec] [6/686] ACTION //:run_torque(//build/toolchain/win:x64)
>>
>>
>>
>> On Thursday, 14 November 2019 22:09:39 UTC+10:30, Dan Elphick wrote:
>>>
>>> So the problem is that utils.h includes include/v8.h. That declares
>>> things like IsolateFromNeverReadOnlySpaceObject, which is appearing in the
>>> preprocessor outputs as:
>>>
>>> __declspec(dllexport) internal::Isolate*
>>> IsolateFromNeverReadOnlySpaceObject(Address obj);
>>>
>>> It's marked as export because it's passing  -DBUILDING_V8_SHARED to the
>>> build command. Removing that is a little tricky, but the simpler way to fix
>>> is to rework the includes to avoid including v8.h:
>>>
>>> Here's a patch:
>>>
>>> diff --git a/src/parsing/scanner.h b/src/parsing/scanner.h
>>> index d9216f222a..a7386050d6 100644
>>> --- a/src/parsing/scanner.h
>>> +++ b/src/parsing/scanner.h
>>> @@ -10,6 +10,7 @@
>>>  #include 
>>>  #include 
>>>
>>> +#include "include/v8.h"
>>>  #include "src/base/logging.h"
>>>  #include "src/common/globals.h"
>>>  #include "src/common/message-template.h"
>>> diff --git a/src/runtime/runtime.h b/src/runtime/runtime.h
>>> index f5e56ac951..0e15898f73 100644
>>> --- a/src/runtime/runtime.h
>>> +++ b/src/runtime/runtime.h
>>> @@ -7,6 +7,7 @@
>>>
>>>  #include 
>>>
>>> +#include "include/v8.h"
>>>  #include "src/base/platform/time.h"
>>>  #include "src/common/globals.h"
>>>  #include "src/objects/elements-kind.h"
>>> diff --git a/src/utils/utils.h b/src/utils/utils.h
>>> index 6f04ea63d3..8ba4e6bef7 100644
>>> --- a/src/utils/utils.h
>>> +++ b/src/utils/utils.h
>>> @@ -12,7 +12,6 @@
>>>  #include 
>>>  #include 
>>>
>>> -#include "include/v8.h"
>

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

[Dan Elphick]

So the problem is that utils.h includes include/v8.h. That declares things
like IsolateFromNeverReadOnlySpaceObject, which is appearing in the
preprocessor outputs as:

__declspec(dllexport) internal::Isolate*
IsolateFromNeverReadOnlySpaceObject(Address obj);

It's marked as export because it's passing  -DBUILDING_V8_SHARED to the
build command. Removing that is a little tricky, but the simpler way to fix
is to rework the includes to avoid including v8.h:

Here's a patch:

diff --git a/src/parsing/scanner.h b/src/parsing/scanner.h
index d9216f222a..a7386050d6 100644
--- a/src/parsing/scanner.h
+++ b/src/parsing/scanner.h
@@ -10,6 +10,7 @@
 #include 
 #include 

+#include "include/v8.h"
 #include "src/base/logging.h"
 #include "src/common/globals.h"
 #include "src/common/message-template.h"
diff --git a/src/runtime/runtime.h b/src/runtime/runtime.h
index f5e56ac951..0e15898f73 100644
--- a/src/runtime/runtime.h
+++ b/src/runtime/runtime.h
@@ -7,6 +7,7 @@

 #include 

+#include "include/v8.h"
 #include "src/base/platform/time.h"
 #include "src/common/globals.h"
 #include "src/objects/elements-kind.h"
diff --git a/src/utils/utils.h b/src/utils/utils.h
index 6f04ea63d3..8ba4e6bef7 100644
--- a/src/utils/utils.h
+++ b/src/utils/utils.h
@@ -12,7 +12,6 @@
 #include 
 #include 

-#include "include/v8.h"
 #include "src/base/bits.h"
 #include "src/base/compiler-specific.h"
 #include "src/base/logging.h"

Please try that and see if it works and I'll upload up to master.


On Thu, 14 Nov 2019 at 11:06, Ben Ernst  wrote:

> Dan,
>
> Yes, torque builds OK.
>
> I have attached the preprocessed output, zipped up. I hope that this tells
> you something.
>
> I tried building the following versions of V8 (in addition to 7.8 I was
> building originally), they all have essentially the same problem.
>
> 7.9.317.22
> 7.7.299.15
> 7.2.502.28
>
> Thank you in advance for any ideas.
> Ben
>
> On Thursday, 14 November 2019 20:47:56 UTC+10:30, Dan Elphick wrote:
>>
>> If instead of building everything, does torque build? e.g. ninja -C
>>  torque. It looks like it does from the log but just want to
>> check. It seems odd that it can build that one but not the other simpler
>> executable.
>>
>> Below  is the command line for building bytecode-operands.obj from your
>> log. It specifies only the single .cc which doesn't include very much at
>> all so I don't see how it would get those symbols. You could try adding the
>> /P option to cl.exe (
>> https://docs.microsoft.com/en-us/cpp/build/reference/p-preprocess-to-a-file?view=vs-2019
>> <https://www.google.com/url?q=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fcpp%2Fbuild%2Freference%2Fp-preprocess-to-a-file%3Fview%3Dvs-2019=D=1=AFQjCNG-ELxt9CxA61sjMVK-8z8nrL4Efg>)
>> and see what the preprocessed output is.
>>
>> ninja -t msvc -e environment.x64
>> --
>> "C:\Program Files (x86)\Microsoft Visual
>> Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64/cl.exe"
>> /nologo /showIncludes
>> -DUSE_AURA=1 -D_HAS_EXCEPTIONS=0 -DCOMPONENT_BUILD -D__STD_C
>> -D_CRT_RAND_S -D_CRT_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_DEPRECATE
>> -D_ATL_NO_OPENGL -D_WINDOWS -DCERT_CHAIN_PARA_HAS_EXTRA_FIELDS
>> -DPSAPI_VERSION=2 -DWIN32 -D_SECURE_ATL -D_USING_V110_SDK71_
>> -DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP -DWIN32_LEAN_AND_MEAN
>> -DNOMINMAX -D_UNICODE -DUNICODE -DNTDDI_VERSION=NTDDI_WIN10_RS2
>> -D_WIN32_WINNT=0x0A00 -DWINVER=0x0A00 -DNDEBUG -DNVALGRIND
>> -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64
>> -DENABLE_MINOR_MC -DV8_INTL_SUPPORT -DV8_USE_SNAPSHOT
>> -DV8_USE_EXTERNAL_STARTUP_DATA -DV8_CONCURRENT_MARKING
>> -DV8_ENABLE_LAZY_SOURCE_POSITIONS -DV8_EMBEDDED_BUILTINS
>> -DV8_SHARED_RO_HEAP -DV8_WIN64_UNWINDING_INFO
>> -DV8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH
>> -DV8_DEPRECATION_WARNINGS -DV8_IMMINENT_DEPRECATION_WARNINGS
>> -DV8_TARGET_ARCH_X64
>> -DDISABLE_UNTRUSTED_CODE_MITIGATIONS -DBUILDING_V8_SHARED
>> -DV8_DEPRECATION_WARNINGS -DV8_IMMINENT_DEPRECATION_WARNINGS
>> -DUSING_V8_BASE_SHARED
>> -I../..  -I../..  -Igen -I../..  -Igen
>> /Gy /FS
>> /bigobj
>> /utf-8
>> /Zc:twoPhase /Zc:sizedDealloc-
>> /wd4117
>> /D__DATE__= /D__TIME__= /D__TIMESTAMP__=
>> /W4 /wd4091 /wd4127 /wd4251 /wd4275 /wd4312 /wd4324 /wd4351 /wd4355
>> /wd4503 /wd4589 /wd4611 /wd4100 /wd4121 /wd4244 /wd4505 /wd4510
>> /wd4512 /wd4610 /wd4838 /wd4995 /wd4996 /wd4456 /wd4457 /wd4458 /wd4459
>> /wd4200 /wd4201 /wd4204 /wd4221 /wd4245 /wd4267 /wd4305 /wd4389
>> /wd4702 /wd4701 /wd4703 /wd4661 /wd4706 /wd4715
&g

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

[Dan Elphick]

If instead of building everything, does torque build? e.g. ninja -C
 torque. It looks like it does from the log but just want to
check. It seems odd that it can build that one but not the other simpler
executable.

Below  is the command line for building bytecode-operands.obj from your
log. It specifies only the single .cc which doesn't include very much at
all so I don't see how it would get those symbols. You could try adding the
/P option to cl.exe (
https://docs.microsoft.com/en-us/cpp/build/reference/p-preprocess-to-a-file?view=vs-2019)
and see what the preprocessed output is.

ninja -t msvc -e environment.x64
--
"C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64/cl.exe"
/nologo /showIncludes
-DUSE_AURA=1 -D_HAS_EXCEPTIONS=0 -DCOMPONENT_BUILD -D__STD_C -D_CRT_RAND_S
-D_CRT_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_DEPRECATE
-D_ATL_NO_OPENGL -D_WINDOWS -DCERT_CHAIN_PARA_HAS_EXTRA_FIELDS
-DPSAPI_VERSION=2 -DWIN32 -D_SECURE_ATL -D_USING_V110_SDK71_
-DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP -DWIN32_LEAN_AND_MEAN -DNOMINMAX
-D_UNICODE -DUNICODE -DNTDDI_VERSION=NTDDI_WIN10_RS2
-D_WIN32_WINNT=0x0A00 -DWINVER=0x0A00 -DNDEBUG -DNVALGRIND
-DDYNAMIC_ANNOTATIONS_ENABLED=0 -DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64
-DENABLE_MINOR_MC -DV8_INTL_SUPPORT -DV8_USE_SNAPSHOT
-DV8_USE_EXTERNAL_STARTUP_DATA -DV8_CONCURRENT_MARKING
-DV8_ENABLE_LAZY_SOURCE_POSITIONS -DV8_EMBEDDED_BUILTINS
-DV8_SHARED_RO_HEAP -DV8_WIN64_UNWINDING_INFO
-DV8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH -DV8_DEPRECATION_WARNINGS
-DV8_IMMINENT_DEPRECATION_WARNINGS -DV8_TARGET_ARCH_X64
-DDISABLE_UNTRUSTED_CODE_MITIGATIONS -DBUILDING_V8_SHARED
-DV8_DEPRECATION_WARNINGS -DV8_IMMINENT_DEPRECATION_WARNINGS
-DUSING_V8_BASE_SHARED
-I../..  -I../..  -Igen -I../..  -Igen
/Gy /FS
/bigobj
/utf-8
/Zc:twoPhase /Zc:sizedDealloc-
/wd4117
/D__DATE__= /D__TIME__= /D__TIMESTAMP__=
/W4 /wd4091 /wd4127 /wd4251 /wd4275 /wd4312 /wd4324 /wd4351 /wd4355 /wd4503
/wd4589 /wd4611 /wd4100 /wd4121 /wd4244 /wd4505 /wd4510
/wd4512 /wd4610 /wd4838 /wd4995 /wd4996 /wd4456 /wd4457 /wd4458 /wd4459
/wd4200 /wd4201 /wd4204 /wd4221 /wd4245 /wd4267 /wd4305 /wd4389
/wd4702 /wd4701 /wd4703 /wd4661 /wd4706 /wd4715
/Zi /MD
/wd4245 /wd4267 /wd4324 /wd4701 /wd4702 /wd4703 /wd4709 /wd4714 /wd4715
/wd4718 /wd4723 /wd4724 /wd4800
/O2 /Ob2 /Oy- /Zc:inline /Gw /TP /wd4577 /GR-
/c ../../src/interpreter/bytecode-operands.cc
/Foobj/bytecode_builtins_list_generator/bytecode-operands.obj
/Fd"obj/bytecode_builtins_list_generator_cc.pdb"



On Wed, 13 Nov 2019 at 20:38, Ben Ernst  wrote:

> Dan,
>
> I've attached the output from a clean build with "-v" as you suggested.
> Thoroughly appreciate any advice. Quite desperate at this point.
>
> Marcelo,
>
> Thank you for the suggestion. Using "is_clang=true" succeeds, but results
> in a binary that is unusable. It cannot be imported into an MSVC project
> due to unresolved symbols. It looks like certain symbols clang doesn't
> think needs to be exported, but MSVC does expect them to be exported. My
> motivation for "use_custom_libcxx" is similar.
>
> Ben
>
> On Wednesday, 13 November 2019 22:27:39 UTC+10:30, Dan Elphick wrote:
>>
>> That's very odd. bytecode_builtins_list_generator is a very small
>> executable that depends on base and generates a header file. It should not
>> be using any of the symbols in your log below and would usually be built
>> and linked before compiling the files containing those symbols.
>>
>> Could you do a clean build and give the output of running the build with
>> ninja -v (so it prints all build commands even if they succeed)? Just the
>> lines involving the obj files in your log should be enough.
>>
>> Thanks,
>> Dan
>>
>> On Wed, 13 Nov 2019 at 11:32, Ben Ernst  wrote:
>>
>>> My full gn args are as follows:
>>>
>>> is_debug = false
>>> target_cpu = "x64"
>>> treat_warnings_as_errors=false
>>> is_component_build=true
>>> v8_enable_i18n_support=false
>>> v8_use_snapshot=true
>>> use_custom_libcxx=false
>>> is_clang=false
>>>
>>> But when I try to build V8 (n.b. on Windows) (n.b. V8 version 7.8.279) I
>>> get the following errors (among many others):
>>>
>>> [exec] [7/685] LINK bytecode_builtins_list_generator.exe
>>> bytecode_builtins_list_generator.exe.pdb
>>>  [exec] FAILED: bytecode_builtins_list_generator.exe
>>> bytecode_builtins_list_generator.exe.pdb
>>>  [exec]
>>> C:/6faf51f1/depot_tools/bootstrap-3_8_0b1_chromium_1_bin/python/bin/python.exe
>>> ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64
>>> False link.exe /nologo /OUT:./bytecode_builtins_list_ge

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

[Dan Elphick]

That's very odd. bytecode_builtins_list_generator is a very small
executable that depends on base and generates a header file. It should not
be using any of the symbols in your log below and would usually be built
and linked before compiling the files containing those symbols.

Could you do a clean build and give the output of running the build with
ninja -v (so it prints all build commands even if they succeed)? Just the
lines involving the obj files in your log should be enough.

Thanks,
Dan

On Wed, 13 Nov 2019 at 11:32, Ben Ernst  wrote:

> My full gn args are as follows:
>
> is_debug = false
> target_cpu = "x64"
> treat_warnings_as_errors=false
> is_component_build=true
> v8_enable_i18n_support=false
> v8_use_snapshot=true
> use_custom_libcxx=false
> is_clang=false
>
> But when I try to build V8 (n.b. on Windows) (n.b. V8 version 7.8.279) I
> get the following errors (among many others):
>
> [exec] [7/685] LINK bytecode_builtins_list_generator.exe
> bytecode_builtins_list_generator.exe.pdb
>  [exec] FAILED: bytecode_builtins_list_generator.exe
> bytecode_builtins_list_generator.exe.pdb
>  [exec]
> C:/6faf51f1/depot_tools/bootstrap-3_8_0b1_chromium_1_bin/python/bin/python.exe
> ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64
> False link.exe /nologo /OUT:./bytecode_builtins_list_generator.exe
> /PDB:./bytecode_builtins_list_generator.exe.pdb
> @./bytecode_builtins_list_generator.exe.rsp
>  [exec] generate-bytecodes-builtins-list.obj : error LNK2019:
> unresolved external symbol "class v8::internal::Isolate * __cdecl
> v8::internal::IsolateFromNeverReadOnlySpaceObject(unsigned __int64)"
> (?IsolateFromNeverReadOnlySpaceObject@internal@v8@@YAPEAVIsolate@12@_K@Z)
> referenced in function "public: class v8::Local __cdecl
> v8::Context::GetEmbedderData(int)" (?GetEmbedderData@Context@v8@
> @QEAA?AV?$Local@VValue@v8@@@2@H@Z)
>  [exec] bytecode-operands.obj : error LNK2001: unresolved external
> symbol "class v8::internal::Isolate * __cdecl
> v8::internal::IsolateFromNeverReadOnlySpaceObject(unsigned __int64)"
> (?IsolateFromNeverReadOnlySpaceObject@internal@v8@@YAPEAVIsolate@12@_K@Z)
>  [exec] bytecodes.obj : error LNK2001: unresolved external symbol
> "class v8::internal::Isolate * __cdecl
> v8::internal::IsolateFromNeverReadOnlySpaceObject(unsigned __int64)"
> (?IsolateFromNeverReadOnlySpaceObject@internal@v8@@YAPEAVIsolate@12@_K@Z)
>  [exec] generate-bytecodes-builtins-list.obj : error LNK2019:
> unresolved external symbol "public: __cdecl
> v8::HandleScope::~HandleScope(void)" (??1HandleScope@v8@@QEAA@XZ)
> referenced in function "public: __cdecl
> v8::EscapableHandleScope::~EscapableHandleScope(void)"
> (??1EscapableHandleScope@v8@@QEAA@XZ)
>
>
> What could I be doing wrong? Any suggestions appreciated.
>
>
>
> On Wednesday, 6 November 2019 21:30:10 UTC+10:30, Ben Ernst wrote:
>>
>> Thanks Hans, I'm sure I tried that before, but I'll give that a shot
>> again. Ben.
>>
>> On Monday, 4 November 2019 17:46:08 UTC+10:30, Hans Maier wrote:
>>>
>>> Hi,
>>>
>>> the libc provided together with v8 is incompatible with the msvc-libc.
>>> I had to provide "use_custom_libcxx=false" to be able to link it with
>>> my own program.
>>>
>>>
>>> Am Sonntag, 3. November 2019 12:43:57 UTC+1 schrieb Ben Ernst:

 Of note, the sample utilities "d8" and "v8_hello_world" build fine, and
 they don't get this same linker error. I can't see anything I'm doing
 differently, however.

 On Sunday, 3 November 2019 22:08:27 UTC+10:30, Ben Ernst wrote:
>
> Thanks Jakob, is there by any chance a correpsonding buildbot for
> Windows and MSVC++? I get this linker error from it seems V8 7.2 onwards,
> although I'm focussing on 7.8. The "monolith" build seems to be working
> though. I wonder if it's an MSVC++ peculiarity that is tripping me up?
> Regards,
> Ben
>
> On Saturday, 2 November 2019 02:17:38 UTC+10:30, Jakob Kummerow wrote:
>>
>> Yes, the component build is expected to work for every version, and
>> our buildbot thinks it does:
>> https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20shared
>>
>> The component build is also the default in Debug mode, which most V8
>> developers compile/use every day.
>>
>>
>> On Fri, Nov 1, 2019 at 1:00 AM Ben Ernst  wrote:
>>
>>> Is the idea of a "component build", where you specify
>>> "is_component_build=true" in the arguments to GN, actually supposed to 
>>> work
>>> at all in V8 (v7.8)?
>>>
>>> In particular, I am getting this unresolved external symbol:
>>>
>>> 1>ezv8_platform.obj : error LNK2019: unresolved external symbol
>>> "__declspec(dllimport) class std::unique_ptr>> std::default_delete > __cdecl
>>> v8::platform::NewDefaultPlatform(int,enum
>>> v8::platform::IdleTaskSupport,enum
>>> v8::platform::InProcessStackDumping,class std::unique_ptr>> v8::TracingController,struct 

Re: [v8-users] Re: v8::Isolate::New works on 7.2, fails on 7.3+

[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?

On Tuesday, July 16, 2019 at 6:18:48 AM UTC+1, Jakob Gruber wrote:
>
> Looks like allocation of the new string here 
> 
>  
> is failing. That code has been there since 71 though.
>
> On Mon, Jul 15, 2019 at 7:37 PM Christopher Nelson  > wrote:
>
>> 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!
>>
>> On Friday, July 12, 2019 at 4:54:39 PM UTC-4, Christopher Nelson wrote:
>>>
>>>
>>> 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  0x77dc66d9 in std::__1::basic_string>> std::__1::char_traits, std::__1::allocator >::append(char 
>>> const*, unsigned long) () from /lib/x86_64-linux-gnu/libc++.so.1
>>> #2  0x044bbd79 in operator+, 
>>> std::__1::allocator > () 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>> ../../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  0x044ba5f4 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 0x044ba834 in Initialize () at 
>>> ../../src/interpreter/interpreter.cc:270
>>> #12 0x0452aa8b in Init () at ../../src/isolate.cc:3336
>>> #13 0x048f72da in Initialize () at 
>>> ../../src/snapshot/snapshot-common.cc:50
>>> #14 0x03e2c492 in Initialize () at ../../src/api.cc:8174
>>> #15 0x03e2ca2f in New () at ../../src/api.cc:8196
>>> #16 0x03d986bc in hiram::js::isolate::isolate 
>>> (this=0x7fffcf38) at ../../../../../engine/src/js/isolate.cpp:20
>>> #17 0x03c93997 in C_A_T_C_HT_E_S_T6 () at 
>>> ../../../../../engine/test/test_element_node.cpp:62
>>> #18 0x03be6b33 in Catch::TestInvokerAsFunction::invoke 
>>> (this=0x7326650) at 
>>> ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:11841
>>> #19 0x03be16d6 in Catch::TestCase::invoke (this=0x738eb00) at 
>>> ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:11742
>>> #20 0x03be160a in Catch::RunContext::invokeActiveTestCase 
>>> (this=0x7fffd7c8) at 
>>> ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:10601
>>> #21 0x03be0164 in Catch::RunContext::runCurrentTest 
>>> (this=0x7fffd7c8, redirectedCout=..., redirectedCerr=...) at 
>>> ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:10574
>>> #22 0x03bdf4fc in Catch::RunContext::runTest 
>>> (this=0x7fffd7c8, testCase=...) at 
>>>