[Insight-developers] How to run the tests: itkGDCMImageIOTest3

Gaëtan Lehmann gaetan.lehmann at jouy.inra.fr
Tue Mar 8 14:58:07 EST 2011


Le 8 mars 11 à 05:26, Mark Roden a écrit :

> OK, I figured it out.
>
> The moral of this story is:
>
> Avoid XCode 4 like the plague.
>
> Once I figured out how to change the command line options in XCode 3,
> a process that took 5 minutes, getting to the error, seeing the
> problem, and fixing it took another five minutes.  XCode 4?  There is
> no way to open the header file for a cxx file from the cxx file, nor
> can you go back to a file that you had open previously.  It is a
> plague upon all right-thinking people, a horrible throwback.
>
> I did a gerrit push to a new topic, and I'm hoping I did that right.
> It says that this version is dependent on another checkin, so they
> should be linked, right?  If not, I guess that will be another round
> of me learning how badly I messed up the process this time.

Mark,

You should create a new branch for any independent change.
If you don't do that, all your changes will appear to depend on the  
others.

If your two changes are made to fix the same issue, for example to  
take in account the reviews on the first change, then you shouldn't  
submit a second change but rather modify the first one by using

   git commit --amend

You can still merge your two changes with

   git rebase -i

resubmit the merged change to gerrit and abandon the second change.

See details at

   http://www.itk.org/Wiki/ITK/Git/Develop

Gaëtan

>
> Thanks for your patience,
> Mark
>
> On Mon, Mar 7, 2011 at 4:51 PM, Luis Ibanez  
> <luis.ibanez at kitware.com> wrote:
>> Hi  Mark
>>
>>
>> On Mon, Mar 7, 2011 at 7:11 PM, Mark Roden <mmroden at gmail.com> wrote:
>>> Hi Luis,
>>>
>>> Wow, you think using an IDE slows down development, and you have  
>>> to go
>>> through all of this to debug something?
>>
>>
>> I ran this in a debugger a week ago,
>> and it took me five minutes to do so
>> including finding the line of code in
>> which the code crashes.
>>
>> You have been struggling with it for
>> several days and still have not run it....
>>
>> I would call that "evidence".       :-)
>>
>>
>> but that's fine,
>> we all develop with our poison of choice...
>>
>>
>>>  I think you and I need to
>>> discuss how to use IDE tools over a beer at the next conference.
>>
>> It is a deal !
>>
>>
>>> Something about hitting 'f5' and just having it work is pretty  
>>> sweet.
>>> Especially if that test is hardcoded somewhere using relative paths,
>>> which definitely looks like a possibility if the test can be run  
>>> from
>>> the command line directly.
>>>
>>
>>
>> That's what the middle mouse button is for    :-)
>>
>>
>>> In any event, when I run the program, I get:
>>>
>>> Starting program:
>>> /Users/mmroden/Documents/src/itk/itk-build-unix/bin/IOCxxTests
>>> "itkGDCMImageIOTest"
>>> "/Users/mmroden/Documents/src/itk/ITK/Testing/Data/Input/ 
>>> 012345.002.050"
>>> "/Users/mmroden/Documents/src/itk/itk-build-unix/Testing/Temporary/ 
>>> itkGDCMImageIOTest3.dcm"
>>> "/Users/mmroden/Documents/src/itk/itk-build-unix/Testing/Temporary/ 
>>> itkGDCMImageIOTest3.png"
>>> "/Users/mmroden/Documents/src/itk/itk-build-unix/Testing/Temporary/ 
>>> itkGDCMRescaleImageIOTest3.dcm"
>>>
>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>> Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000050
>>> 0x0000000100740d85 in gdcm::JPEGCodec::Decode ()
>>>
>>> That's a very different stack trace than what you were reporting.
>>>
>>
>>
>> Well,
>> that's not a stack trace.
>>
>> You need to type "backtrace" or "bt" inside gdb
>> after the program crashes, to see the real stack trace.
>>
>>
>>> I'm going to wrestle with this a bit more, but this just hurts.
>>
>>
>> You need to put a break point in the call of that function,
>> and you will see that it calls itself in a loop.
>>
>>
>>> there no way to have a direct command line application that a) reads
>>> in whatever files are used by the ctest app so that I don't have to
>>> manually enter all the command line stuff (all it is is another
>>> opportunity for error) and b) let's me trace right in there?  Maybe
>>> IDE development has made me soft by thinking I could debug something
>>> in ten minutes or less :)
>>>
>>
>> The fastest way to debug this will be to take the test
>> out of the test driver, write a CMakeList.txt file for it,
>> and run it locally with a copy of the input DICOM file.
>>
>> That will take less than ten minutes.
>>
>>
>>     Luis
>>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers

-- 
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr  http://www.itk.org
http://www.mandriva.org  http://www.bepo.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: Ceci est une signature ?lectronique PGP
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110308/285c2e77/attachment.pgp>


More information about the Insight-developers mailing list