id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	blockedby	blocking	notify_on_close	platform	project
1471	AtomicStructure not fully cleaning up memory on close	Tristan Croll	Eric Pettersen	"The real-world scenario here is that I'm running analysis scripts over >1000 models, using some of my tools from ISOLDE. I'm running in GUI mode since ISOLDE's tools aren't tested in non-gui mode (and I save PNG files from Matplotlib - not sure if that would work in non-gui mode anyway...). But the minimal test that replicates the problem is:

{{{
pdb_ids = #Some list of a few dozen PDB IDs (or filenames)
from chimerax.core.commands import open as cxopen
for i in range(10):
    for pdb_id in pdb_ids:
        cxopen.open(session, pdb_id)
    session.models.close(session.models.list())
}}}

Dumping a memory map of the process shows a large number of anonymous ~64MB blocks:

{{{
Address           Kbytes     RSS   Dirty Mode  Mapping
0000000000400000       4       4       0 r-x-- ChimeraX
0000000000600000       4       4       4 r---- ChimeraX
0000000000601000       4       4       4 rw--- ChimeraX
0000000002515000  443132  405040  405040 rw---   [ anon ]
00000000401ab000    1288    1288    1288 rw---   [ anon ]
00000000404a9000    1288    1288    1288 rw---   [ anon ]
0000000040aaf000     644     644     644 rw---   [ anon ]
0000000040b86000       8       4       0 r-xs- .glU5NXLN (deleted)
0000000040bdd000     644     644     644 rw---   [ anon ]
0000000040cb9000     644     644     644 rw---   [ anon ]
000000004121f000     644     644     644 rw---   [ anon ]
000000004144d000     644     644     644 rw---   [ anon ]
0000000041833000     644     644     644 rw---   [ anon ]
0000000041c81000     644     644     644 rw---   [ anon ]
0000000041e86000     644     644     644 rw---   [ anon ]
0000000041f43000     644     644     644 rw---   [ anon ]
00007fef34000000   64768   64768   64768 rw---   [ anon ]
00007fef37f40000     768       0       0 -----   [ anon ]
00007fef38000000   22356   22356   22356 rw---   [ anon ]
00007fef395d5000   43180       0       0 -----   [ anon ]
00007fef3c000000   65032   65032   65032 rw---   [ anon ]
00007fef3ff82000     504       0       0 -----   [ anon ]
00007fef40000000   63976   63976   63976 rw---   [ anon ]
00007fef43e7a000    1560       0       0 -----   [ anon ]
00007fef44000000   64240   64240   64240 rw---   [ anon ]
00007fef47ebc000    1296       0       0 -----   [ anon ]
00007fef4c000000   64504   64504   64504 rw---   [ anon ]
00007fef4fefe000    1032       0       0 -----   [ anon ]
00007fef50000000   64768   64768   64768 rw---   [ anon ]
00007fef53f40000     768       0       0 -----   [ anon ]
00007fef54000000   65032   65032   65032 rw---   [ anon ]
00007fef57f82000     504       0       0 -----   [ anon ]
00007fef58000000   64240   64240   64240 rw---   [ anon ]
00007fef5bebc000    1296       0       0 -----   [ anon ]
00007fef5c000000   65032   65032   65032 rw---   [ anon ]
... etc.
}}}

... some of which seem to slowly clean up over time (in minutes to tens of minutes), but others hang around seemingly indefinitely. It's non-linear as well - on my system memory usage shoots up to 10-15 GB quite quickly, but on the analysis I left running overnight (which has gotten through about 9000 models so far) it's hit an equilibrium at around 27GB. It also seems to be grinding a lot more slowly than in a freshly-started session."	defect	closed	moderate		Core		fixed		chimera-programmers				Linux64 (X11)	ChimeraX