> Hi, > > Sherief, thank you for our kind help. You're welcome :).
> I really did use globals. > I found a way to run DumpMemorLeaks after all globals and static > variables are deallocated, I used > _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF); I should've RTFMed harder :(. > I made some malloc and new leaks around the code I'm interested in to > see if it works - worked great, but I found > NO leaks in sqlite sqlite3_prepare. As expected. > I'm not sure if it means that there is an error in Deleaker or > CrtDumpMemoryLeaks doesn't report mallocs from DLL ( i bet on Deleaker > because it claims that there is a leak in heap so CrtDumpMemoryLeaks > should show this ). > > How do you think? > > Bartek The behavior of _CrtDumpMemoryLeaks() is a bit tricky across module barriers. Though not in MSDN, but from a simple app/dll combination I built I found out that _CrtDumpMemoryLeaks() reports memory leaks caused by the calling module only (exe or dll: if dll leaks and exe calls it, no leak will be reported). Also, it doesn't watch memory not allocated by the CRT, such as via Heap*() functions. How much do you know about the DLLs you're using? Are they reliable? Does your leak checker support some sort of stack-trace option to show where the leaked memory was allocated? How does it handle non-CRT allocations (not malloc() and new)? - Sherief _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
