Den 20. mar. 2010 01.57 skrev fcharp <[email protected]>:
> Ok -- more follow-up. As I said before, there were still some leaks
> left. I am still working with the Win32 "Hello world" example. Even
> after adding the Dispose() method at the end of the program, there are
> still leaks -- and one of them is significant (89K).
>
Is this a repeated leak or is it a one-off leak of 89k for the entire run of
the program?
>
> To make sure that I was not looking at leaks caused by other parts of
> the program, I commented out every v8-related line and include from
> the file. I then ran it and it came back without leaks. I then added
> just the one "Dispose()" statement to the program, with the #include
> "v8.h" and the leaks were back as follows:
>
> --------------------------------------------------------------------------
>
> Detected memory leaks!
> Dumping objects ->
> {115} normal block at 0x00927FA8, 8 bytes long.
> Data: < ` > 00 60 06 01 B0 00 00 00
> {112} normal block at 0x00927E88, 28 bytes long.
> Data: < _ F2 > E0 5F 06 01 F0 46 32 00 FF FF FF FF 00 00 00
> 00
> {111} normal block at 0x00927E30, 28 bytes long.
> Data: < _ F2 > E0 5F 06 01 B8 46 32 00 FF FF FF FF 00 00 00
> 00
> {106} normal block at 0x009278E0, 28 bytes long.
> Data: < _ F2 > E0 5F 06 01 80 46 32 00 FF FF FF FF 00 00 00
> 00
> {105} normal block at 0x00927890, 20 bytes long.
> Data: < x > FF FF FF FF 00 CD CD CD CD CD CD CD 90 78 92
> 00
> {104} normal block at 0x00927840, 20 bytes long.
> Data: < @x > FF FF FF FF 00 CD CD CD CD CD CD CD 40 78 92
> 00
> {103} normal block at 0x007D0068, 81904 bytes long.
> Data: < > 00 00 00 00 CD CD CD CD 04 00 00 00 CD CD CD
> CD
> {102} normal block at 0x00921FD8, 16 bytes long.
> Data: < > 0C 1A 17 01 00 00 00 00 CD CD CD CD 00 00 00
> 00
> {101} normal block at 0x009277E8, 28 bytes long.
> Data: < _ J0 > E0 5F 06 01 A8 4A 30 00 FF FF FF FF 00 00 00
> 00
> Object dump complete.
> --------------------------------------------------------------------------
>
> The leak at {103} is 81904 bytes long!... So it does look like V8 does
> not clean up everything, even when the Dispose() statement is the one
> and only call made to V8 (kinda ironic).
>
> The biggest offender is the 89K block from line 103. I dug a little
> deeper this time and found out that it is allocated by the
> GlobalHandles::Pool::Pool() method, which calls Malloced::operator
> new. The problem seems to be that this pool of global handles memory
> is not freed by V8.
>
> So... Can anybody contribute to this monologue, please? Do you know of
> memory leaks on other platforms, maybe? How do you get around them?
> Why do they happen?
>
> Frederic
>
>
> On Mar 19, 7:19 pm, fcharp <[email protected]> wrote:
> > Follow-up on my previous post (mea culpa) -- I added v8::V8::Dispose()
> > in the functions responsible for shutting V8 down. Dispose() invokes
> > TearDown(), which effectively cleans up the memory. I bumped into the
> > method while examining the V8.h include file. As these things go, the
> > "Hello world" examples from the V8 developer site does not include
> > Dispose() -- I suppose it has not been updated recently. Anyhow,
> > Dispose() seems to do the trick, at the cost, of course, of
> > terminating for good the V8 engine.
> >
> > Frederic
> >
>
> --
> v8-users mailing list
> [email protected]
> http://groups.google.com/group/v8-users
>
> To unsubscribe from this group, send email to v8-users+
> unsubscribegooglegroups.com or reply to this email with the words "REMOVE
> ME" as the subject.
>
--
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
To unsubscribe, reply using "remove me" as the subject.
