Working set is the size of memory pages recently used by the application. If the application releases memory, working set size may remain the same until the memory is needed for another process. So, this may be normal. If memory usage keep increasing when you repeatedly load a data and close the scene (e.g., working set is 2GB then 3GB, 4GB, 5GB, …) then that may indicate that there is a memory leak.
Dear all, thank you for your support.
Indeed, as you told, in my windows PC the unfreed RAM is reallocated when needed automatically.
NB: During the weekend I have only a Macbook Mojave to work, so I’ll post the steps to reproduce the error on monday. However I noticed that opening the same images on Slicer for MacOS the required RAM is much less (less than 1GB…). Could this be normal?
At the moment I can post a RT structure which is causing a slicer crash on MacOS. Probably it’s something similar to the problem found on Windows 7 but here the process closes.
I’ve downloaded the execuitable installer which should be compiled every night. I’ve changed nothing.
If you say it’s not a problem, for me it’s fine. It’s only a bit strange to have a page-long list of errors when you close the program. That’s why I made this post.
However I still have the crash problem I reported a couple o posts ago.
Those memory leak warnings displays are on by default when you manually build Slicer nightly. Maybe someone built Slicer manually, packaged it and then you installed it from that and not from the Slicer website.
It’s definitely a problem if it happens for the Stable Release. By default, we should probably not run memory leak check on Preview Releases either (if we do it now then we should probably change the build scripts), as this is debug information only intended for developers.
Importing that RTSTRUCT crashes Slicer, because it is invalid: number of values in contour data must be 3 x number of contour points, but in the file there are only 1 x number of contour points.
We’ve tested SlicerRT DICOM importer on thousands of data sets but never encountered such error, that’s why we did not notice that this can crash the application. Now I’ve added an extra check to avoid crash in the future and report this as an error.
Let developers of the software that created this RTSTRUCT file know that they produce non-compliant DICOM files. The incorrectly set “number of contour points” is just one of the many issues in the file (for example, usage of coded entries are completely misinterpreted by the developers).
@lassoan I came back to this thread to test if memory leaks are displayed using preview releases built by the factory machines and indeed they are displayed.
Using “3D Slicer 4.11.0-2019-08-22” downloaded from Slicer’s website and creating a leak such as a=slicer.mrmlScene.CreateNodeByClass("vtkMRMLScalarVolumeNode") in the python interactor and then closing Slicer, I received a vtk debug leaks output window. This was tested using a Windows 7 machine which the original poster was also using.
Does anyone know if testing of preview releases is using memory leaks output to determine faults? As in will a memory leak introduced during a specific test cause that test to fail if on Slicer close there are memory leaks?