Freesurfer

freesurfer@nmr.mgh.harvard.edu

16 participants
30084 discussions

FW: RE: [Freesurfer] vtkMultiThreader error
by Christopher Nunez 09 Jun '09

09 Jun '09

I am getting similar error messages when running on our grid and pipeline systems (see below). Our tech people had previously thought this could be related to memory capacity issues, but after increasing memory to 8gb when submitting my jobs with a qsub command, the problem is still not resolved. I'm beginning to have doubts about this being related to memory capacity. Could somebody please provide instructions on disabling the ribbon processing? Thank you. #@# Cortical ribbon mask Sun May 31 18:21:54 PDT 2009 /ifs/edevel/CN_SAN_DIEGO/FREESURFER/OUTPUT/164/mri \n mris_volmask --label_left_white 2 --label_left_ribbon 3 --label_right_white 41 --label_right_ribbon 42 --save_ribbon --save_distance 164 \n ERROR: In /usr/pubsw/packages/vtk/5.1.0-CVS/src/VTK/Common/vtkMultiThreader.cxx, line 372 vtkMultiThreader (0x3279bb60): Unable to create a thread. pthread_create() returned 12 ERROR: In /usr/pubsw/packages/vtk/5.1.0-CVS/src/VTK/Common/vtkMultiThreader.cxx, line 372 vtkMultiThreader (0x3279bb60): Unable to create a thread. pthread_create() returned 12 ERROR: In /usr/pubsw/packages/vtk/5.1.0-CVS/src/VTK/Common/vtkMultiThreader.cxx, line 372 vtkMultiThreader (0x3279bb60): Unable to create a thread. pthread_create() returned 12 ERROR: In /usr/pubsw/packages/vtk/5.1.0-CVS/src/VTK/Common/vtkMultiThreader.cxx, line 372 vtkMultiThreader (0x3279bb60): Unable to create a thread. pthread_create() returned 12 ERROR: In /usr/pubsw/packages/vtk/5.1.0-CVS/src/VTK/Common/vtkMultiThreader.cxx, line 372 vtkMultiThreader (0x3279bb60): Unable to create a thread. pthread_create() returned 12 ERROR: In /usr/pubsw/packages/vtk/5.1.0-CVS/src/VTK/Common/vtkMultiThreader.cxx, line 372 vtkMultiThreader (0x3279bb60): Unable to create a thread. pthread_create() returned 12 ERROR: In /usr/pubsw/packages/vtk/5.1.0-CVS/src/VTK/Common/vtkMultiThreader.cxx, line 372 vtkMultiThreader (0x3279bb60): Unable to create a thread. pthread_create() returned 12 ------------------------------------------------------------------- S. Christopher Nuñez, PhD Postdoctoral Fellow Developmental Cognitive Neuroimaging Group Laboratory of Neuro Imaging UCLA Dept of Neurology Neuroscience Research Building 1, Suite 225 635 Charles Young Drive South Los Angeles, CA 90095-7334 (310) 267-5555 ------------------------------------------------------------------- ________________________________________ From: hranilovich(a)ucla.edu [hranilovich(a)ucla.edu] Sent: Monday, June 08, 2009 12:13 PM To: Christopher Nunez Subject: Fwd: RE: [Freesurfer] vtkMultiThreader error Pretty much what I was saying the other day. It looks like maybe you can disable this step if you don't want this output, though? ----- Forwarded message from dhaglerjr(a)hotmail.com ----- Date: Mon, 8 Jun 2009 11:19:43 -0700 From: Don Hagler <dhaglerjr(a)hotmail.com> Reply-To: Don Hagler <dhaglerjr(a)hotmail.com> Subject: RE: [Freesurfer] vtkMultiThreader error To: nicks(a)nmr.mgh.harvard.edu, martin.kavec(a)gmail.com Cc: freesurfer maillist <freesurfer(a)nmr.mgh.harvard.edu> Hi Nick, Thanks for the reply. I will look into the memory limit issue some more (we recently instituted per job memory limits), but I have done a test run with a 16GB memory limit (running one job per node). Meanwhile, thanks for the novtk suggestion. Our fallback option is to just disable the ribbon generation. I don't think we ever use them for anything. Don > Subject: Re: [Freesurfer] vtkMultiThreader error > From: nicks(a)nmr.mgh.harvard.edu > To: martin.kavec(a)gmail.com; dhaglerjr(a)hotmail.com > Date: Mon, 8 Jun 2009 11:15:51 -0400 > CC: freesurfer(a)nmr.mgh.harvard.edu > > Don and Martin, > > I dont have a good solution for you to this problem. The error code > indicates an 'out-of-memory' error returned by pthread_create, and I do > know the mris_vol_mask uses a lot of memory (at least 1GB). > > I have not been able to find any clues to the source of this problem on > the web either. The only curious thing to it is that in the source > code, that section is conditionally compiled to ignore the return code > if 'VTK_HP_PTHREADS' is defined, which implies some sort of odd behavior > on some special HP platform build. > > mris_vol_mask has been a real thorn in the side of the recon-all stream, > but its not easy to replace because it does a subjectively better job of > finding the voxels which intersect the pial and white surfaces. For > comparison, or even to solve your problem, you can use > mris_vol_mask_novtk to create the ribbon.mgz files. The output is not > the same as that produced by mris_vol_mask though. Perhaps you can run > it, and compare the results side-by-side and give us your opinion on > which is the better ribbon (as there is no objective measure on what a > 'correct' ribbon.mgz should like like, ie, should it include voxels that > intersect more than half way through a surface, or not at all?). > > Nick > > > On Mon, 2009-06-08 at 09:16 +0200, Martin Kavec wrote: > > Hi Don, > > > I am in a similar situation. I am on a IBM BladeCenter cluster > (though with > one blade only) with 2 Quad core Intels, and I > experience intermittent > crashes of mri_volmask as well. Similarly > as you, when I run the mri_volmask > on the crashed subject on a > desktop, this passes perfectly fine and sometimes > also on the > cluster as well. > > > I am wonder whether how do you obtain the debug information > about the cause of > the crash (being in the vtkMultiThreader)? > > > I also wonder, whether the crashes could be due to different > compilation > environments of the VTK libraries used in teh FS > distribution (centos) and > your redhat. I went on the bug-report > site of VTK and there really isn't > anythink major reported on this > class. > > In my experience the mri_volmask runs fine for quite a > while and then crashes. > >From the debug messages you show it would > thus could be that the process may > hit some limit of the threads > which could be allocated to a process. > > > What do you think? > > > Martin > > On Saturday 06 June 2009 04:19:51 Don Hagler wrote: > > > When we run v430 on our cluster, running rocks redhat 4.3, we > get the error > > > message below when mris_volmask is run. From a google search, I see that > > > someone had the same error message back in Oct 2007. Was a > solution found > > > for this? It runs fine on our desktop machines as well as when we log in > > > directly to a node and run the job interactively. > > > > > > > > > > > > mris_volmask --label_left_white 2 --label_left_ribbon 3 > > > --label_right_white 41 --label_right_ribbon 42 --save_ribbon > > > --save_distance FREESURFERRECON_NTNU_PRE_095v2_20071126.173245.968000_1 > > > > > > SUBJECTS_DIR is /home/dhagler/data_test > > > ERROR: In /usr/pubsw/packages/vtk/5.2.0/src/Common/vtkMultiThreader.cxx, > > > line 372 vtkMultiThreader (0x1306ec80): Unable to create a > thread. > > pthread_create() returned 12 > > > > > > ERROR: In /usr/pubsw/packages/vtk/5.2.0/src/Common/vtkMultiThreader.cxx, > > > line 372 vtkMultiThreader (0x1306ec80): Unable to create a > thread. > > pthread_create() returned 12 > > > > > > ERROR: In /usr/pubsw/packages/vtk/5.2.0/src/Common/vtkMultiThreader.cxx, > > > line 372 vtkMultiThreader (0x1306ec80): Unable to create a > thread. > > pthread_create() returned 12 > > > > > > ERROR: In /usr/pubsw/packages/vtk/5.2.0/src/Common/vtkMultiThreader.cxx, > > > line 372 vtkMultiThreader (0x1306ec80): Unable to create a > thread. > > pthread_create() returned 12 > > > > > > ERROR: In /usr/pubsw/packages/vtk/5.2.0/src/Common/vtkMultiThreader.cxx, > > > line 372 vtkMultiThreader (0x1306ec80): Unable to create a > thread. > > pthread_create() returned 12 > > > > > > ERROR: In /usr/pubsw/packages/vtk/5.2.0/src/Common/vtkMultiThreader.cxx, > > > line 372 vtkMultiThreader (0x1306ec80): Unable to create a > thread. > > pthread_create() returned 12 > > > > > > ERROR: In /usr/pubsw/packages/vtk/5.2.0/src/Common/vtkMultiThreader.cxx, > > > line 372 vtkMultiThreader (0x1306ec80): Unable to create a > thread. > > pthread_create() returned 12 > > > > > > Segmentation fault > > > Linux compute-0-12.local 2.6.9-55.0.2.ELsmp #1 SMP Tue Jun 26 > 14:14:47 EDT > > > 2007 x86_64 x86_64 x86_64 GNU/Linux > > > > > > recon-all exited with ERRORS at Fri Jun 5 18:58:09 PDT 2009 > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > Hotmail® has ever-growing storage! Don't worry about storage limits. > > > > http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutori > > >al_Storage_062009 > > > > _______________________________________________ > > Freesurfer mailing list > > Freesurfer(a)nmr.mgh.harvard.edu > > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > > > _______________________________________________ > Freesurfer mailing list > Freesurfer(a)nmr.mgh.harvard.edu > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer _________________________________________________________________ Insert movie times and more without leaving Hotmail®. http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutor… ----- End forwarded message ----- n

3 2

Anatomical stats for fsaverage
by Alex Fornito 09 Jun '09

09 Jun '09

Hi, I'm playing around with different ways of generating custom annotation files using the fsaverage surface, and would like to estimate the surface area of each ROI. I tried running mris_anatomical stats, but it seems to required wm.mgz, which is not contained in the fsaverage directories (please see below). Is there any way around this? I'm really just interested in extracting the surface area for each label in my .annot file. Thanks for your help, Alex mris_anatomical_stats -a lh.test.aparc.annot -f stats_table.txt -log logfile.txt fsaverage lh white computing statistics for each annotation in lh.test.aparc.annot outputting results to logfile.txt... reading volume /work/imaging5/af397/twins/fsaverage/mri/wm.mgz... ERROR: cannot find /work/imaging5/af397/twins/fsaverage/mri/wm.mgz mris_anatomical_stats: could not read input volume /work/imaging5/af397/twins/fsaverage/mri/wm.mgz No such file or directory

3 7

problem with spmregister
by Hesheng Liu 09 Jun '09

09 Jun '09

Hi, Guys, I am trying to coregister a CT image with MRI using spmregister, however I am getting the following error message. I have run the same command on many subjects before and never had a problem. Is there any update that I am not aware of? Any thoughts will be greatly appreciated. Hesheng Adding my matlab commands... >> >> >> >> >> >> >> >> >> /usr/pubsw/common/spm/spm5/spm_coreg.m >> >> >> >> >> INFO: Assuming RAS coordinate system >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> using ./tmp.spmreg.7057/refvol.spmregister.img as the target image >> using ./tmp.spmreg.7057/movvol.spmregister.img as the source image >> >> >> >> >> >> >> >> >> >> >> >> >> >> INFO: ignore warnings about scalefactor >> >> determining coregistration parameters... >> >> >> ERROR: spm_coreg >> ??? Undefined function or variable 'x'. >> Finished after 0.258371 sec >> >> Parameters >> ??? Undefined function or variable 'x'. >> >> >> >> >> ??? Undefined function or variable 'x'. >> >> Using spm_get_space ??? Undefined function or variable 'M'. >> >> >> ERROR: matlab exited with errors ERROR: spm_coreg /usr/pubsw/common/spm/spm5/spm_coreg.m

2 1

FW: fsaverage, posterior slices missing
by Sharmili 57 09 Jun '09

09 Jun '09

From: sharmili75(a)hotmail.com To: freesurfer(a)nmr.mgh.harvard.edu Subject: fsaverage, posterior slices missing Date: Tue, 9 Jun 2009 12:01:48 +0000 Hi, I tried to run make_average_suject with 22 Subjects (11 Schizophrenia and 11 controls). In tkmedit I checked the result. the posterior slices seem to be missing in fsaverage orig.mgz but tksurfer ist complete. I've attached a screenshot. Has anyone have an idea, how to solve this problem. Thanks Sharmili Posteingang immer voll? Der erste Speicher, der mitwächst: Unbegrenzter Speicher bei Windows Live Hotmail! _________________________________________________________________ http://redirect.gimas.net/?n=M0906xIE8_MSN4 Internet Explorer 8 jetzt für MSN - kostenlos!

2 1

Stand processing prepared for longitudinal pipeline.
by Hui Zheng 08 Jun '09

08 Jun '09

Hi, We are processing our data for the longitudinal pipeline. I found some subjects' brainmask with skull/dura remaining, and a portion of the skull was segmented as cortical gray matter in aseg. I'd like to ask if this kind of problem will affect the longitudinal registration/template creation? I have one more question. Is the method described in the paper by Golland P (2003), Permutation Tests for Classification: Towards Statistical Significance in Image-Based Studies, used in FreeSurfer? Thanks, Zheng Hui

1 0

mri_glmfit significiance verification outside freesurfer
by Jeff Sadino 08 Jun '09

08 Jun '09

Hello Surfers, I am trying to verify the p-value sig.mgh maps outputted from the mri_glmfit command as the first part of a more advanced analysis. We have been extracting the thickness data for a single vertex from each of our 58 subjects in two control groups and then running a significiance analysis is SAS. We thought that the output from SAS should match the p-value in the sig.mgh file, but the p-values do not match at all. We have tested multiple data points. Does freesurfer do some sort of a more advanced significance analysis that is not in the standard documentation? Thank you very much, Jeff Sadino _________________________________________________________________ Windows Live™ SkyDrive™: Get 25 GB of free online storage. http://windowslive.com/online/skydrive?ocid=TXT_TAGLM_WL_SD_25GB_062009

4 4

Brain cortical structures segmentation - comparison of hippocampal volumes
by Flavio Seixas 08 Jun '09

08 Jun '09

My name is Flavio, student at Universidade Federal Fluminense. I research image segmentation methods applied to brain cortical structures segmentation. I've compared against the hippocampal region got from FIRST-FSL to Freesurfer, using the same magnetic resonance (MR) image. The FSL is a neuroimage analysis tool developed by FMRI group from Oxford. I found out a great volume difference between segmentations. Despite different automated image analysis tool, I was expecting a higher volume overlap index when comparing the same brain structure from the same MR image. I got about 25% volume overlap. Is there any "recon-all" flag that I can use in conjunction with entire process so as to get better volume overlap? I would appreciate any suggestion. Thank you in advance, Flavio.

4 4

TAL QA check failed
by Barnali Basu 08 Jun '09

08 Jun '09

Experts, I got the following error while running a subject with recon-all autorecon1 ERROR: Talairach QA check failed! z-score = -8 <= -4 = threshold Manual Talairach alignment may be necessary, or include the -notal-check flag to skip this test. See http://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/Talairach Linux barnali-work 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux recon-all exited with ERRORS at Fri Jun 5 22:35:17 PDT 2009 I gathered from other posts on this error that the fix depends upon the z -score. In this case the z-score is -8, what is the best way to get it fixed. Previously i had fixed similar error and i had fixed it with tkregister2, but z-score was different Thanks and Regards -- Barnali Basu Cell : 425 638 2936 Home: 206 257 0174

2 3

Re: [Freesurfer] mris_anatomical_stats
by Nick Schmansky 08 Jun '09

08 Jun '09

Kevin, I've tracked down some memory trampling going on in mris_anatomical_stats, and posted a fixed version for linux x86_64 here: ftp://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/fixes/linux- centos4_x86_64 Nick On Mon, 2009-06-08 at 15:10 -0700, Kevin Scheibel wrote: > I am running mris_anatomical_stats and keep getting the same error. > Here’s the entire log file…looks like the big error happens at ‘glibc > detected’ > > > > computing statistics for each annotation > in /ifs/woods/scott_temp/kevin_work/freeseg/subj/078/label/rh.aparc.annot. > > outputting results > to /ifs/tmp/pipeline-4.2/pipelnvr/2009June08_15h03m16s361ms/MRISAnatomicalStats.StatsFile_0-077.stats... > > reading > volume /ifs/woods/scott_temp/kevin_work/freeseg/subj_xfm/078/mri/wm.mgz... > > reading input > surface /ifs/woods/scott_temp/kevin_work/freeseg/subj_xfm/078/surf/lh.pial... > > reading input pial > surface /ifs/woods/scott_temp/kevin_work/freeseg/subj_xfm/078/surf/lh.pial... > > reading input white > surface /ifs/woods/scott_temp/kevin_work/freeseg/subj_xfm/078/surf/lh.white... > > reading colortable from annotation file... > > colortable with 36 entries read > (originally /autofs/space/amaebi_026/users/buckner_cortical_atlas/scripts/colortable_final.txt) > > *** glibc detected > *** /usr/local/freesurfer-4.3.0_64bit/bin/mris_anatomical_stats: free > (): invalid pointer: 0x00002af35c93d000 *** > > ======= Backtrace: ========= > > /lib64/libc.so.6[0x35c4671684] > > /lib64/libc.so.6(cfree+0x8c)[0x35c4674ccc] > > /lib64/libc.so.6(_IO_free_backup_area+0x18)[0x35c466dd68] > > /lib64/libc.so.6(_IO_file_overflow+0x1d2)[0x35c466bd62] > > /lib64/libc.so.6(_IO_vfprintf+0x4a7e)[0x35c4646d4e] > > /lib64/libc.so.6(_IO_fprintf+0x88)[0x35c464cf68] > > /usr/local/freesurfer-4.3.0_64bit/bin/mris_anatomical_stats(vfprintf > +0x338d)[0x40898d] > > /lib64/libc.so.6(__libc_start_main+0xf4)[0x35c461d8b4] > > /usr/local/freesurfer-4.3.0_64bit/bin/mris_anatomical_stats > (__gxx_personality_v0+0xfa)[0x40626a] > > ======= Memory map: ======== > > 00400000-00786000 r-xp 00000000 00:16 > 238900739 /usr/local/freesurfer-4.3.0_64bit/bin/mris_anatomical_stats > > 00886000-008e0000 rw-p 00386000 00:16 > 238900739 /usr/local/freesurfer-4.3.0_64bit/bin/mris_anatomical_stats > > 008e0000-0209f000 rw-p 008e0000 00:00 0 > > 04da5000-0b132000 rw-p 04da5000 00:00 0 > > 35c4200000-35c421a000 r-xp 00000000 08:01 > 4321433 /lib64/ld-2.5.so > > 35c441a000-35c441b000 r--p 0001a000 08:01 > 4321433 /lib64/ld-2.5.so > > 35c441b000-35c441c000 rw-p 0001b000 08:01 > 4321433 /lib64/ld-2.5.so > > 35c4600000-35c474a000 r-xp 00000000 08:01 > 4321434 /lib64/libc-2.5.so > > 35c474a000-35c4949000 ---p 0014a000 08:01 > 4321434 /lib64/libc-2.5.so > > 35c4949000-35c494d000 r--p 00149000 08:01 > 4321434 /lib64/libc-2.5.so > > 35c494d000-35c494e000 rw-p 0014d000 08:01 > 4321434 /lib64/libc-2.5.so > > 35c494e000-35c4953000 rw-p 35c494e000 00:00 0 > > 35c4a00000-35c4a21000 r-xp 00000000 08:01 > 12354411 /usr/lib64/libjpeg.so.62.0.0 > > 35c4a21000-35c4c20000 ---p 00021000 08:01 > 12354411 /usr/lib64/libjpeg.so.62.0.0 > > 35c4c20000-35c4c21000 rw-p 00020000 08:01 > 12354411 /usr/lib64/libjpeg.so.62.0.0 > > 35c4e00000-35c4e57000 r-xp 00000000 08:01 > 12354412 /usr/lib64/libtiff.so.3.8.2 > > 35c4e57000-35c5056000 ---p 00057000 08:01 > 12354412 /usr/lib64/libtiff.so.3.8.2 > > 35c5056000-35c5059000 rw-p 00056000 08:01 > 12354412 /usr/lib64/libtiff.so.3.8.2 > > 35c5200000-35c5282000 r-xp 00000000 08:01 > 4321204 /lib64/libm-2.5.so > > 35c5282000-35c5481000 ---p 00082000 08:01 > 4321204 /lib64/libm-2.5.so > > 35c5481000-35c5482000 r--p 00081000 08:01 > 4321204 /lib64/libm-2.5.so > > 35c5482000-35c5483000 rw-p 00082000 08:01 > 4321204 /lib64/libm-2.5.so > > 35c6200000-35c6214000 r-xp 00000000 08:01 > 12346484 /usr/lib64/libz.so.1.2.3 > > 35c6214000-35c6413000 ---p 00014000 08:01 > 12346484 /usr/lib64/libz.so.1.2.3 > > 35c6413000-35c6414000 rw-p 00013000 08:01 12346484 > /usr/lib64/libz.so.1.2.3 > > 35c6600000-35c6609000 r-xp 00000000 08:01 > 4321447 /lib64/libcrypt-2.5.so > > 35c6609000-35c6808000 ---p 00009000 08:01 > 4321447 /lib64/libcrypt-2.5.so > > 35c6808000-35c6809000 r--p 00008000 08:01 > 4321447 /lib64/libcrypt-2.5.so > > 35c6809000-35c680a000 rw-p 00009000 08:01 > 4321447 /lib64/libcrypt-2.5.so > > 35c680a000-35c6838000 rw-p 35c680a000 00:00 0 > > 35c6a00000-35c6ae6000 r-xp 00000000 08:01 > 12346051 /usr/lib64/libstdc++.so.6.0.8 > > 35c6ae6000-35c6ce5000 ---p 000e6000 08:01 > 12346051 /usr/lib64/libstdc++.so.6.0.8 > > 35c6ce5000-35c6ceb000 r--p 000e5000 08:01 > 12346051 /usr/lib64/libstdc++.so.6.0.8 > > 35c6ceb000-35c6cee000 rw-p 000eb000 08:01 > 12346051 /usr/lib64/libstdc++.so.6.0.8 > > 35c6cee000-35c6d00000 rw-p 35c6cee000 00:00 0 > > 35c7200000-35c720d000 r-xp 00000000 08:01 > 4321444 /lib64/libgcc_s-4.1.2-20080102.so.1 > > 35c720d000-35c740d000 ---p 0000d000 08:01 > 4321444 /lib64/libgcc_s-4.1.2-20080102.so.1 > > 35c740d000-35c740e000 rw-p 0000d000 08:01 > 4321444 /lib64/libgcc_s-4.1.2-20080102.so.1 > > 2af35799b000-2af35799e000 rw-p 2af35799b000 00:00 0 > > 2af3579a7000-2af3579a8000 rw-p 2af3579a7000 00:00 0 > > 2af3579a8000-2af3579aa000 r-xp 00000000 08:01 > 4321435 /lib64/libdl-2.5.so > > 2af3579aa000-2af357baa000 ---p 00002000 08:01 > 4321435 /lib64/libdl-2.5.so > > 2af357baa000-2af357bab000 r--p 00002000 08:01 > 4321435 /lib64/libdl-2.5.so > > 2af357bab000-2af357bac000 rw-p 00003000 08:01 > 4321435 /lib64/libdl-2.5.so > > 2af357bac000-2af357bc1000 r-xp 00000000 08:01 4321439 > /lib64/libpthread-2.5.so > > 2af357bc1000-2af357dc0000 ---p 00015000 08:01 > 4321439 /lib64/libpthread-2.5.so > > 2af357dc0000-2af357dc1000 r--p 00014000 08:01 > 4321439 /lib64/libpthread-2.5.so > > 2af357dc1000-2af357dc2000 rw-p 00015000 08:01 > 4321439 /lib64/libpthread-2.5.so > > 2af357dc2000-2af35c93f000 rw-p 2af357dc2000 00:00 0 > > 2af360000000-2af360021000 rw-p 2af360000000 00:00 0 > > 2af360021000-2af364000000 ---p 2af360021000 00:00 0 > > 7fff52ee6000-7fff5310f000 rw-p 7fff52ee6000 00:00 0 > [stack] > > ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 > [vdso] > > /ifs/woods/scott_temp/kevin_work/freeseg/freesurfer-4.3.0_64bit/bin/mris_anatomical_stats.sh: line 8: 28655 Aborted /usr/local/freesurfer-4.3.0_64bit/bin/mris_anatomical_stats $@ > > > > > > > > Kevin Scheibel > > k.scheibel(a)ucla.edu > > > > > _______________________________________________ > Freesurfer mailing list > Freesurfer(a)nmr.mgh.harvard.edu > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

1 0

mris_anatomical_stats
by Kevin Scheibel 08 Jun '09

08 Jun '09

I am running mris_anatomical_stats and keep getting the same error. Here's the entire log file.looks like the big error happens at 'glibc detected' computing statistics for each annotation in /ifs/woods/scott_temp/kevin_work/freeseg/subj/078/label/rh.aparc.annot. outputting results to /ifs/tmp/pipeline-4.2/pipelnvr/2009June08_15h03m16s361ms/MRISAnatomicalStats .StatsFile_0-077.stats... reading volume /ifs/woods/scott_temp/kevin_work/freeseg/subj_xfm/078/mri/wm.mgz... reading input surface /ifs/woods/scott_temp/kevin_work/freeseg/subj_xfm/078/surf/lh.pial... reading input pial surface /ifs/woods/scott_temp/kevin_work/freeseg/subj_xfm/078/surf/lh.pial... reading input white surface /ifs/woods/scott_temp/kevin_work/freeseg/subj_xfm/078/surf/lh.white... reading colortable from annotation file... colortable with 36 entries read (originally /autofs/space/amaebi_026/users/buckner_cortical_atlas/scripts/colortable_fin al.txt) *** glibc detected *** /usr/local/freesurfer-4.3.0_64bit/bin/mris_anatomical_stats: free(): invalid pointer: 0x00002af35c93d000 *** ======= Backtrace: ========= /lib64/libc.so.6[0x35c4671684] /lib64/libc.so.6(cfree+0x8c)[0x35c4674ccc] /lib64/libc.so.6(_IO_free_backup_area+0x18)[0x35c466dd68] /lib64/libc.so.6(_IO_file_overflow+0x1d2)[0x35c466bd62] /lib64/libc.so.6(_IO_vfprintf+0x4a7e)[0x35c4646d4e] /lib64/libc.so.6(_IO_fprintf+0x88)[0x35c464cf68] /usr/local/freesurfer-4.3.0_64bit/bin/mris_anatomical_stats(vfprintf+0x338d) [0x40898d] /lib64/libc.so.6(__libc_start_main+0xf4)[0x35c461d8b4] /usr/local/freesurfer-4.3.0_64bit/bin/mris_anatomical_stats(__gxx_personalit y_v0+0xfa)[0x40626a] ======= Memory map: ======== 00400000-00786000 r-xp 00000000 00:16 238900739 /usr/local/freesurfer-4.3.0_64bit/bin/mris_anatomical_stats 00886000-008e0000 rw-p 00386000 00:16 238900739 /usr/local/freesurfer-4.3.0_64bit/bin/mris_anatomical_stats 008e0000-0209f000 rw-p 008e0000 00:00 0 04da5000-0b132000 rw-p 04da5000 00:00 0 35c4200000-35c421a000 r-xp 00000000 08:01 4321433 /lib64/ld-2.5.so 35c441a000-35c441b000 r--p 0001a000 08:01 4321433 /lib64/ld-2.5.so 35c441b000-35c441c000 rw-p 0001b000 08:01 4321433 /lib64/ld-2.5.so 35c4600000-35c474a000 r-xp 00000000 08:01 4321434 /lib64/libc-2.5.so 35c474a000-35c4949000 ---p 0014a000 08:01 4321434 /lib64/libc-2.5.so 35c4949000-35c494d000 r--p 00149000 08:01 4321434 /lib64/libc-2.5.so 35c494d000-35c494e000 rw-p 0014d000 08:01 4321434 /lib64/libc-2.5.so 35c494e000-35c4953000 rw-p 35c494e000 00:00 0 35c4a00000-35c4a21000 r-xp 00000000 08:01 12354411 /usr/lib64/libjpeg.so.62.0.0 35c4a21000-35c4c20000 ---p 00021000 08:01 12354411 /usr/lib64/libjpeg.so.62.0.0 35c4c20000-35c4c21000 rw-p 00020000 08:01 12354411 /usr/lib64/libjpeg.so.62.0.0 35c4e00000-35c4e57000 r-xp 00000000 08:01 12354412 /usr/lib64/libtiff.so.3.8.2 35c4e57000-35c5056000 ---p 00057000 08:01 12354412 /usr/lib64/libtiff.so.3.8.2 35c5056000-35c5059000 rw-p 00056000 08:01 12354412 /usr/lib64/libtiff.so.3.8.2 35c5200000-35c5282000 r-xp 00000000 08:01 4321204 /lib64/libm-2.5.so 35c5282000-35c5481000 ---p 00082000 08:01 4321204 /lib64/libm-2.5.so 35c5481000-35c5482000 r--p 00081000 08:01 4321204 /lib64/libm-2.5.so 35c5482000-35c5483000 rw-p 00082000 08:01 4321204 /lib64/libm-2.5.so 35c6200000-35c6214000 r-xp 00000000 08:01 12346484 /usr/lib64/libz.so.1.2.3 35c6214000-35c6413000 ---p 00014000 08:01 12346484 /usr/lib64/libz.so.1.2.3 35c6413000-35c6414000 rw-p 00013000 08:01 12346484 /usr/lib64/libz.so.1.2.3 35c6600000-35c6609000 r-xp 00000000 08:01 4321447 /lib64/libcrypt-2.5.so 35c6609000-35c6808000 ---p 00009000 08:01 4321447 /lib64/libcrypt-2.5.so 35c6808000-35c6809000 r--p 00008000 08:01 4321447 /lib64/libcrypt-2.5.so 35c6809000-35c680a000 rw-p 00009000 08:01 4321447 /lib64/libcrypt-2.5.so 35c680a000-35c6838000 rw-p 35c680a000 00:00 0 35c6a00000-35c6ae6000 r-xp 00000000 08:01 12346051 /usr/lib64/libstdc++.so.6.0.8 35c6ae6000-35c6ce5000 ---p 000e6000 08:01 12346051 /usr/lib64/libstdc++.so.6.0.8 35c6ce5000-35c6ceb000 r--p 000e5000 08:01 12346051 /usr/lib64/libstdc++.so.6.0.8 35c6ceb000-35c6cee000 rw-p 000eb000 08:01 12346051 /usr/lib64/libstdc++.so.6.0.8 35c6cee000-35c6d00000 rw-p 35c6cee000 00:00 0 35c7200000-35c720d000 r-xp 00000000 08:01 4321444 /lib64/libgcc_s-4.1.2-20080102.so.1 35c720d000-35c740d000 ---p 0000d000 08:01 4321444 /lib64/libgcc_s-4.1.2-20080102.so.1 35c740d000-35c740e000 rw-p 0000d000 08:01 4321444 /lib64/libgcc_s-4.1.2-20080102.so.1 2af35799b000-2af35799e000 rw-p 2af35799b000 00:00 0 2af3579a7000-2af3579a8000 rw-p 2af3579a7000 00:00 0 2af3579a8000-2af3579aa000 r-xp 00000000 08:01 4321435 /lib64/libdl-2.5.so 2af3579aa000-2af357baa000 ---p 00002000 08:01 4321435 /lib64/libdl-2.5.so 2af357baa000-2af357bab000 r--p 00002000 08:01 4321435 /lib64/libdl-2.5.so 2af357bab000-2af357bac000 rw-p 00003000 08:01 4321435 /lib64/libdl-2.5.so 2af357bac000-2af357bc1000 r-xp 00000000 08:01 4321439 /lib64/libpthread-2.5.so 2af357bc1000-2af357dc0000 ---p 00015000 08:01 4321439 /lib64/libpthread-2.5.so 2af357dc0000-2af357dc1000 r--p 00014000 08:01 4321439 /lib64/libpthread-2.5.so 2af357dc1000-2af357dc2000 rw-p 00015000 08:01 4321439 /lib64/libpthread-2.5.so 2af357dc2000-2af35c93f000 rw-p 2af357dc2000 00:00 0 2af360000000-2af360021000 rw-p 2af360000000 00:00 0 2af360021000-2af364000000 ---p 2af360021000 00:00 0 7fff52ee6000-7fff5310f000 rw-p 7fff52ee6000 00:00 0 [stack] ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vdso] /ifs/woods/scott_temp/kevin_work/freeseg/freesurfer-4.3.0_64bit/bin/mris_ana tomical_stats.sh: line 8: 28655 Aborted /usr/local/freesurfer-4.3.0_64bit/bin/mris_anatomical_stats $@ Kevin Scheibel k.scheibel(a)ucla.edu

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Freesurfer