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

Gaëtan Lehmann gaetan.lehmann at jouy.inra.fr
Wed Mar 9 01:06:56 EST 2011


Hi Mark,

Your new commit should have this line

   Change-Id: Change-Id: I413102b25d1c9eee60eace2585c2f857ad564a67

at the end of the commit message. That way, your new commit would be  
considered as the new revision of the previous changes you've submitted.
This line is added automatically by the ITK's git hooks in the commit  
message - I guess your hooks were not configured when you recorded  
your first commit.

You should

   git commit --amend

add the line with the Change-Id in the commit message, run

   git gerrit-push

again, and abandon those changes

   http://review.source.kitware.com/1156
   http://review.source.kitware.com/1162

Thanks,

Gaëtan



Le 8 mars 11 à 21:49, Mark Roden a écrit :

> 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
>>
>>

-- 
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/20110309/7511c035/attachment.pgp>


More information about the Insight-developers mailing list