Running recon-all with the v3.0.2 release, I have noticed recently that the process will run into seg faults at various stages (e.g. topology correction, sphere reg, or cortical parcellation). This seems somewhat random, but judging from some other posts, and the fact that it happenened when I was running multiple jobs at once but didn't (for the same subject) when it was the only job, it seems to be memory dependent. That is, when there is not enough available memory, things crash without warning or relevant error messages (e.g. not enough memory). Does that seem like an accurate assessment of things?
Aside from hardware solutions (e.g. more RAM or bigger swap space), is there anything that can be done to the software to allow the user to balance speed with memory usage? And die in a less mysterious way?
Hi Don,
we certainly try to trap all memory allocation failures, but no doubt have missed a few. We'll try to track them down, but in the meantime you're better of running things in series since it won't run any faster anyway, and this way it will stop failing :)
Bruce
On Sun, 4 Jun 2006, Don Hagler wrote:
Running recon-all with the v3.0.2 release, I have noticed recently that the process will run into seg faults at various stages (e.g. topology correction, sphere reg, or cortical parcellation). This seems somewhat random, but judging from some other posts, and the fact that it happenened when I was running multiple jobs at once but didn't (for the same subject) when it was the only job, it seems to be memory dependent. That is, when there is not enough available memory, things crash without warning or relevant error messages (e.g. not enough memory). Does that seem like an accurate assessment of things?
Aside from hardware solutions (e.g. more RAM or bigger swap space), is there anything that can be done to the software to allow the user to balance speed with memory usage? And die in a less mysterious way?
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
freesurfer@nmr.mgh.harvard.edu