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 b
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
ved 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:
>
is 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 T
[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]
>>
mber 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
>&g
i /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
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 findi
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 f
rames 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,
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 do
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 l
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::Init
13 matches
Mail list logo
