memory-leaks

问题 I am doing some heavy calculations with Python (using OpenCV and Numpy) and in the end, I end up with a lot of memory usage (>1GB) whereby all refs should be gone and I only have the end-result (which should not be more than a few MB). To debug this, it would be nice if I could get some stats somehow which show me how much object instances there are of what type, ordered by the total amount of memory they take (per object class). Or even nicer: Not per object class but per source code line

问题 I am using the instructions found here to try to find memory leaks in a Win32 application. As described, I put the #define _CRTDBG_MAP_ALLOC #include <stdlib.h> #include <crtdbg.h> Lines at the top of a file (the cpp file that contains WINAPI _tWinMain) and then at the exit point of winmain I added _CrtDumpMemoryLeaks(); Unfortunately I do not see the line numbers/locations for the leaks (but I do get a list of leaks). I also tried putting _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK

问题 I am using the instructions found here to try to find memory leaks in a Win32 application. As described, I put the #define _CRTDBG_MAP_ALLOC #include <stdlib.h> #include <crtdbg.h> Lines at the top of a file (the cpp file that contains WINAPI _tWinMain) and then at the exit point of winmain I added _CrtDumpMemoryLeaks(); Unfortunately I do not see the line numbers/locations for the leaks (but I do get a list of leaks). I also tried putting _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK

问题 I'm an intermediate Haskell programmer with tons of experience in strict FP and non-FP languages. Most of my Haskell code analyzes moderately large datasets (10^6..10^9 things), so laziness is always lurking. I have a reasonably good understanding of thunks, WHNF, pattern matching, and sharing, and I've been able to fix leaks with bang patterns and seq, but this profile-and-pray approach feels sordid and wrong. I want to know how experienced Haskell programmers approach laziness at design

问题 I'm an intermediate Haskell programmer with tons of experience in strict FP and non-FP languages. Most of my Haskell code analyzes moderately large datasets (10^6..10^9 things), so laziness is always lurking. I have a reasonably good understanding of thunks, WHNF, pattern matching, and sharing, and I've been able to fix leaks with bang patterns and seq, but this profile-and-pray approach feels sordid and wrong. I want to know how experienced Haskell programmers approach laziness at design

问题 A follow-up question to Memory leaks when calling ITK from Visual Studio DLL I refined the problem to the simplest example. struct A { public: A() { mp_data = new int(0x42); } ~A() { delete mp_data; } int* mp_data; }; A a; When such a global class is defined in a DLL, Visual Studio debug CRT reports that mp_data is leaked on application shutdown. Does anybody know a workaround except disabling leak reporting? 回答1: If you are calling _CrtDumpMemoryLeaks() at the end of the main function the

问题 After upgrading a project from Delphi 2007 to Delphi 2009 I'm getting an Unknown memory leak, so far I've been tryin to track it down using fastMM, here is what fastMM stack trace reports: A memory block has been leaked. The size is: 20 This block was allocated by thread 0x111C, and the stack trace (return addresses) at the time was: 40339E [System.pas][System][@GetMem][3412] 534873 [crtl][_malloc] 56D1C4 [canex.cpp][MidasLib][DllGetDataSnapClassObject][3918] 56D316 [canex.cpp][MidasLib]

问题 After a recent deployment in system test, one of our servlets was getting hit much harder than usual and we noticed memory started climbing and weblogic would eventually die. My intern, I was very proud, discovered the source of the memory leak. Whenever a request comes in, this line gets called: JAXBContext jc = JAXBContext.newInstance(“ruby.oracle_servlet.schemas”); For some reason, the object never gets garbage collected. Once we made it static and moved where we initialized it, our memory

问题 Does my java application continue running while jmap is taking its memory dump? 回答1: Your application is stopped. The only practical way to get an accurate heap dump would be to stop all application activity while the dump is being created. Whether this is a "brief" pause or a "long" pause depends on how much is dumped. If you use "-dump" then you will dump the entire heap, including unreachable objects. If you use "-dump:live" you will only dump reachable objects ... but that also entails

问题 we have the problem that our non-heap-memory is growing all the time. so we have to restart our jee (java8) - webapp every 3rd day (as you can see in the screenshot here: screenshot from non-heap- and heap-memory) I have already tried to find out what fills up that non-heap. But I couldn't find any tool to create a nonheap-dump. do you have any idea how i could investigate on that to find out what elements are increasingly growing? java-version java version "1.8.0_102" Java(TM) SE Runtime