From claude at bic.mni.mcgill.ca  Wed Sep 12 13:29:14 2007
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Wed, 12 Sep 2007 13:29:14 -0400 (EDT)
Subject: [MINC-development] set_cache_output_volume_parameters in minc2,
	64 bits
Message-ID: <200709121729.l8CHTEw310579184@yorick.bic.mni.mcgill.ca>


Hi,

Any minc developers out there?

I stumbled across a seg fault running classify this morning while testing the
latest image-processing tools in minc2. The problem appears to be due to volume 
caching, as in the following example taken from classify:

      if ( cache_set ) {
        set_cache_output_volume_parameters(fuzzy_volume[k],
                                           fuzzy_filename[k],
                                           fuzzy_type,
                                           FALSE,
                                           fuzzy_voxel_min,
                                           fuzzy_voxel_max,
                                           input_filename[0],
                                           history,
                                           (minc_output_options *) NULL ) ;

      } /* if ( cache_set ) */

There are other functions associated with caching as well. The seg fault occurs
while writing the minc file.

When I deactivated caching in classify (it has a convenient -nocache option),
then execution completed normally, giving the same output as minc1 with cache.
Compilation was on a Linux 64-bit Red Hat machine, gcc 3.4.4. The problem does 
not seem to show up in minc2 in 32 bits, nor in minc1 32 or 64 bits. I'm using
the pre-release minc-2.0.13 package.

Perhaps someone has some free time to look at this problem as I don't have
time right now. Given that I found an easy way to bypass the problem, I'm not
too motivated to play in the source code if I don't have too. :-)

Any ideas?

bye

Claude

From a.janke at gmail.com  Wed Sep 12 19:41:49 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 13 Sep 2007 09:41:49 +1000
Subject: [MINC-development] set_cache_output_volume_parameters in minc2,
	64 bits
In-Reply-To: <200709121729.l8CHTEw310579184@yorick.bic.mni.mcgill.ca>
References: <200709121729.l8CHTEw310579184@yorick.bic.mni.mcgill.ca>
Message-ID: <d747ed50709121641s6cee11e3hecf346e3b54dc915@mail.gmail.com>

Hi Claude,

Seems like you are very busy breaking MINC as of late... :)  Myself I
disable caching alltogether (and let the OS look after it) in
volume_io.

ie:

   export VOLUME_CACHE_THRESHOLD=1000000000

Apparently if you set it to 0 this works too, but the above looks more
impressive.

I have a long term goal of just removing all the caching code from
volume_io but it is very low on my list given the new MINC2 interfaces
that bert wrote.


a


On 9/13/07, Claude LEPAGE <claude at bic.mni.mcgill.ca> wrote:
>
> Hi,
>
> Any minc developers out there?
>
> I stumbled across a seg fault running classify this morning while testing the
> latest image-processing tools in minc2. The problem appears to be due to volume
> caching, as in the following example taken from classify:
>
>       if ( cache_set ) {
>         set_cache_output_volume_parameters(fuzzy_volume[k],
>                                            fuzzy_filename[k],
>                                            fuzzy_type,
>                                            FALSE,
>                                            fuzzy_voxel_min,
>                                            fuzzy_voxel_max,
>                                            input_filename[0],
>                                            history,
>                                            (minc_output_options *) NULL ) ;
>
>       } /* if ( cache_set ) */
>
> There are other functions associated with caching as well. The seg fault occurs
> while writing the minc file.
>
> When I deactivated caching in classify (it has a convenient -nocache option),
> then execution completed normally, giving the same output as minc1 with cache.
> Compilation was on a Linux 64-bit Red Hat machine, gcc 3.4.4. The problem does
> not seem to show up in minc2 in 32 bits, nor in minc1 32 or 64 bits. I'm using
> the pre-release minc-2.0.13 package.
>
> Perhaps someone has some free time to look at this problem as I don't have
> time right now. Given that I found an easy way to bypass the problem, I'm not
> too motivated to play in the source code if I don't have too. :-)
>
> Any ideas?
>
> bye
>
> Claude
> _______________________________________________
> MINC-development mailing list
> MINC-development at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
>


-- 
Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883

From jason at bic.mni.mcgill.ca  Thu Sep 13 10:21:31 2007
From: jason at bic.mni.mcgill.ca (Jason Lerch)
Date: Thu, 13 Sep 2007 10:21:31 -0400
Subject: [MINC-development] set_cache_output_volume_parameters in minc2,
	64 bits
In-Reply-To: <d747ed50709121641s6cee11e3hecf346e3b54dc915@mail.gmail.com>
References: <200709121729.l8CHTEw310579184@yorick.bic.mni.mcgill.ca>
Message-ID: <46E9476B.4050904@bic.mni.mcgill.ca>

Andrew Janke wrote:
> Hi Claude,
>
> Seems like you are very busy breaking MINC as of late... :)  Myself I
> disable caching alltogether (and let the OS look after it) in
> volume_io.
>
> ie:
>
>    export VOLUME_CACHE_THRESHOLD=1000000000
>
> Apparently if you set it to 0 this works too, but the above looks more
> impressive.
>   

Just in case anyone is foolish enough to follow Andrew's advice here: 
setting VOLUME_CACHE_THRESHOLD to 0 will cause everything to be cached, 
setting it to -1 (or anything less than 0) will cause caching to be 
disabled.

Jason

> I have a long term goal of just removing all the caching code from
> volume_io but it is very low on my list given the new MINC2 interfaces
> that bert wrote.
>
>
> a
>
>
> On 9/13/07, Claude LEPAGE <claude at bic.mni.mcgill.ca> wrote:
>   
>> Hi,
>>
>> Any minc developers out there?
>>
>> I stumbled across a seg fault running classify this morning while testing the
>> latest image-processing tools in minc2. The problem appears to be due to volume
>> caching, as in the following example taken from classify:
>>
>>       if ( cache_set ) {
>>         set_cache_output_volume_parameters(fuzzy_volume[k],
>>                                            fuzzy_filename[k],
>>                                            fuzzy_type,
>>                                            FALSE,
>>                                            fuzzy_voxel_min,
>>                                            fuzzy_voxel_max,
>>                                            input_filename[0],
>>                                            history,
>>                                            (minc_output_options *) NULL ) ;
>>
>>       } /* if ( cache_set ) */
>>
>> There are other functions associated with caching as well. The seg fault occurs
>> while writing the minc file.
>>
>> When I deactivated caching in classify (it has a convenient -nocache option),
>> then execution completed normally, giving the same output as minc1 with cache.
>> Compilation was on a Linux 64-bit Red Hat machine, gcc 3.4.4. The problem does
>> not seem to show up in minc2 in 32 bits, nor in minc1 32 or 64 bits. I'm using
>> the pre-release minc-2.0.13 package.
>>
>> Perhaps someone has some free time to look at this problem as I don't have
>> time right now. Given that I found an easy way to bypass the problem, I'm not
>> too motivated to play in the source code if I don't have too. :-)
>>
>> Any ideas?
>>
>> bye
>>
>> Claude
>> _______________________________________________
>> MINC-development mailing list
>> MINC-development at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
>>
>>     
>
>
>   


From a.janke at gmail.com  Thu Sep 13 18:05:25 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 14 Sep 2007 08:05:25 +1000
Subject: [MINC-development] set_cache_output_volume_parameters in minc2,
	64 bits
In-Reply-To: <46E9476B.4050904@bic.mni.mcgill.ca>
References: <d747ed50709121641s6cee11e3hecf346e3b54dc915@mail.gmail.com>
	<46E9476B.4050904@bic.mni.mcgill.ca>
Message-ID: <d747ed50709131505q6b1bb694o11cec0147d8b9082@mail.gmail.com>

> > Seems like you are very busy breaking MINC as of late... :)  Myself I
> > disable caching alltogether (and let the OS look after it) in
> > volume_io.
> >
> >    export VOLUME_CACHE_THRESHOLD=1000000000
> >
> > Apparently if you set it to 0 this works too, but the above looks more
> > impressive.
>
> Just in case anyone is foolish enough to follow Andrew's advice here:
> setting VOLUME_CACHE_THRESHOLD to 0 will cause everything to be cached,
> setting it to -1 (or anything less than 0) will cause caching to be
> disabled.

So that's why 0 didnt seem to work that well... :)

Thanks Jason.


a