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());
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
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
: 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
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 wh
R- /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
[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_
u 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
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
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
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
12 matches
Mail list logo
