I am running Geant4.9.5 under Windows operating systems, and I am seeing what appear to be systematic memory leak crashes. The application will steadily increase its memory usage until the system resources are depleted and a fatal exception occurs. This has happened on several applications and on 4 separate PC’s and with two different O.S.’s, XP and Windows 7. The applications are compiled as Microsoft Visual Studio projects created using the Geant CMake utility. Most of the work has been done with V9 (2008), but also V10 has been used. The run time required before the crash depends on the application and the PC. So far, in addition to the application of interest to me, my “working code”, I have also tested several novice examples, and crashes have occurred in all cases. The most striking case is novice example 1. With the verbose values set to zero and numberOfEvent to 1e8, the system RAM was consumed at a rate of about 0.8 MB/sec, and the crash occurred after about 45 minutes, at roughly 6e6 events (on a PC with 4 GB RAM). Novice example 3 crashed after 26 hours and example 6 crashed after about 7 hours. In all the novice examples, the exception generated was identical with that observed in the working code, and the behavior of system memory is also the same. The process memory usage as indicated in the Windows Task Manager increases indefinitely with run time, and the free physical memory decreases until some critical point where a failure occurs. Attempts to isolate the crash site have failed because the site varies somewhat from run to run. I also tried setting the Windows low-fragmentation heap option, but without effect. The VS debugger is typically confused by the fatal exception, but on at least one occasion indicated a null pointer to a block of memory on the heap during a free-heap call. The key feature, again, is that the Geant process invariably depletes the system supply of available memory, apparently without any limit other than run time. These same codes have been run on Linux systems without crashes. On the Linux system, the process memory, typically about a GB for the working code, seems to remain fairly constant for the duration of the run. Some of these run times are days or weeks. (cf Problem ID 282 and 1474)
Thanks for reporting the problem. We could reproduce it rather easily. It turns out that this is due to the mechanism used in the CMake build for extracting symbols for the generation of the DLL libraries, which is actually ignoring some symbols with templated signature. The problem, obviously, does not occur when using static libraries (or DLLs generated with the old GNUMake system, where a different bug-free extractor was adopted). We're looking to fix this problem and provide the fix in a next patch. A quick workaround for now is to explicitly install static libraries on your Windows system.
Created attachment 175 [details] Patched source for 9.5.p01 The problem is now fixed adopting the workaround implemented in the attached tar-ball to applied to the source code of 9.5.p01 release. It overcomes the deficiency in the CMake system on exported templated symbols. The fix will be included in the next patch release. To apply the attached patch, just uncompress it inside your 9.5.p01/ source directory and rebuild the libraries from scratch.
