Here is an interesting case. As these things go, it is an unlikely occurrence, but it just happened that it has been interfering with my development.
In summary, I have been bothered by the fact that, in certain cases, Dispose() will not release the GlobalHandles pool_ memory to the system. The problem is very easy to duplicate: simply create a program with the V8 lib. And make Dispose() the only V8-related statement in the program. On exit, you end up with an 89K memory leak (size depending on the platform). There are other leaks, but of lesser importance than this one. What happens is that pool_ was implicitly allocated by the following line in global-handles.cc: static GlobalHandles::Pool pool_ Of course, this implicit allocation happens even if V8 is not formally initialized. When the Dispose() statement is executed, TearDown() is called and it proceeds to deallocate resources, including the pool_ chunk -- but only under normal circumstances. And this is where the problem occurs. In effect, TearDown() checks if the "has_been_setup flag" is set, denoting that V8 was initialized. In the present case, the flag is not set because there was no invocation of V8 prior to the invocation of Dispose(). As a result, the GlobalHandles::Release() method is not called by TearDown() and pool_ is not released. I understand that the conditions under which this happens are odd. But in my program, I do not always have to start up the V8 engine, but I always execute Dispose(), just in case. I guess that will teach me :-). Anyhow, I know how to avoid the problem now, but it may be a good idea to make sure that TearDown() disposes of all statically allocated memory blocks, regardless of the state of the "has_been_setup" flag. I will modify my local files accordingly. Frederic -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev To unsubscribe from this group, send email to v8-dev+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
