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

M Stauffer (V) mstauff at verizon.net
Wed Mar 9 13:00:56 EST 2011


If you're still interested in interactively debugging a cmake-built exe
using xcode, see below. I'm also much more used to debugging in an IDE,
so prefer this (once it's setup!).

compile with -g

- Open Xcode
- Create an Empty project (it's one of the choices for project type)
- Right click "Executables" under "Groups and Files" and select Add->New
Custom Executable
- Set the path for your executable and click "Finish"
- Optional: in the "Executable Info" window (accessible from right click
then "Get Info" on the executable in "Groups and Files"), set the
working directory to the path to your executable.
- Right click your <Project Name> under "Groups and Files" and select
Add->Existing Files and select your source file. I added only the source
for the test driver (e.g. ReviewCxxTests.cxx) and it worked, also
showing me source files for other itk files when the debugger hit a
breakpoint.

After that you're all set. You probably want to click your source file
in "Groups and Files" set a breakpoint and start the debugger with break
points on. You'll see all the graphical debugger goodness!!

NOTE:
This won't copy your executable or source code to the project directory.
If you save this project, close Xcode, modify your source code,
recompile, re-open your project in Xcode - all your new code and new
executable will be right there ready for your debugging pleasure.

Cheers,
Michael 

>-----Original Message-----
>From: insight-developers-bounces at itk.org 
>[mailto:insight-developers-bounces at itk.org] On Behalf Of Gaëtan Lehmann
>Sent: Wednesday, March 09, 2011 1:07 AM
>To: Mark Roden
>Cc: Hans J. Johnson; Insight Developers; Luis Ibanez
>Subject: Re: [Insight-developers] How to run the tests: 
>itkGDCMImageIOTest3
>
>
>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
>
>



More information about the Insight-developers mailing list