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

[Mark Roden]

Hi Gaetan,

OK, now everything's there in 1162:
http://review.source.kitware.com/#change,1162

Should I abandon the previous changes?  I squashed the second commit,
as it's really just a matter of the first commit working.

If that's cool, then I'll go ahead and assign reviewers again and
abandon the older gerrit commits.

Mark

2011/3/8 Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>:
>
> 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
>
>