Hi - I think you're right - this is probably a RAM/max process size
issue. The new release of FSL has a much more memory-friendly version
of FILM (about a factor of 2); if that's still over limit then you'll
need to use a 64-bit platform.
The new release will be out _very_ soon...maybe tomorrow? Maybe
Thursday? If it wasn't for fixing things to run under Windows it
would be out already ;-)
Cheers, Steve.
On 4 Apr 2006, at 19:18, Yaroslav Halchenko wrote:
> Dear FSL People,
>
> Please advise: I was trying to analyze some BOLD data which was
> collected at relatively high spatial resolution, thus the
> dimensions of
> the BOLD file are: 128x128x40x334
>
> Whenever I am trying to do simple feat analysis (conveniently started
> from GUI), it crashes while running film_gls:
>
> (gdb) file /usr/apps/fsl/bin/film_gls
> Load new symbol table from "/share/apps/fsl/bin/film_gls"? (y or n) y
> Reading symbols from /share/apps/fsl/bin/film_gls...done.
> (gdb) set args -rn stats -noest filtered_func_data design.mat
> 1000.000000
> (gdb) run
> Starting program: /share/apps/fsl/bin/film_gls -rn stats -noest
> filtered_func_data design.mat 1000.000000
> Log directory is: stats++
> Completed
> Prewhitening and Computing PEs...
> Percentage done:
> 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,2
> 7,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50
> ,51,52,53,
> 54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,7
> 7,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,Co
> mpleted
> Saving results...
>
> Program received signal SIGABRT, Aborted.
> 0xb7e457a7 in raise () from /lib/tls/libc.so.6
> (gdb) bt
> #0 0xb7e457a7 in raise () from /lib/tls/libc.so.6
> #1 0xb7e4704b in abort () from /lib/tls/libc.so.6
> #2 0x414aa167 in __cxa_call_unexpected () from /usr/lib/libstdc+
> +.so.5
> #3 0x414aa1a4 in std::terminate () from /usr/lib/libstdc++.so.5
> #4 0x414aa316 in __cxa_throw () from /usr/lib/libstdc++.so.5
> #5 0x414aa56f in operator new () from /usr/lib/libstdc++.so.5
> #6 0x414aa63f in operator new[] () from /usr/lib/libstdc++.so.5
> #7 0x0807d5f0 in NEWMAT::GeneralMatrix::ReSize ()
> #8 0x0807d634 in NEWMAT::Matrix::ReSize ()
> #9 0x08073640 in MISCMATHS::VolumeSeries::unthresholdSeries ()
> #10 0x0806281c in main ()
>
>
> Apparently ReSize is called from unthresholdSeries with
> unthresholdSeries numVolumes:334 numUnThresholdedSeries:655360
>
> so it probably tries to allocate 334*655360*8=1751121920 bytes=1.63GB.
> At that point host has plenty of free memory (around 3-4 GB), so it
> should not be an issue. Also it is opteron box running in 32 bit mode,
> but I believe that this amount also doesn't go above 2GB limit. Also
> whenever I am trying to new double[334*655360] from within independent
> simple program, it seems to work fine.
>
> Please advise on what could I do? May be there is dev branch available
> for testing?
>
> thank you in advance
>
> --
> Yaroslav Halchenko
> Research Assistant, Psychology Department, Rutgers-Newark
> Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
> 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07105
> Student Ph.D. @ CS Dept. NJIT
------------------------------------------------------------------------
---
Stephen M. Smith, Professor of Biomedical Engineering
Associate Director, Oxford University FMRIB Centre
FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK
+44 (0) 1865 222726 (fax 222717)
[log in to unmask] http://www.fmrib.ox.ac.uk/~steve
------------------------------------------------------------------------
---
|