[Insight-users] All python tests fail

[Gaëtan Lehmann]

Le 29 nov. 07 à 20:09, Marco Nolden a écrit :

> Gaëtan Lehmann wrote:
>>
>> Le 29 nov. 07 à 13:52, Marco Nolden a écrit :
>>
>>> Gaëtan Lehmann wrote:
>>>>
>>>> Le 28 nov. 07 à 20:01, Marco Nolden a écrit :
>>>>
>>>>> nolden at mbi056:~$
>>>>> PYTHONPATH=/local/nolden/itk-bin-wo-cswig/Wrapping/WrapITK/ 
>>>>> Python/:/local/nolden/itk-bin-wo-cswig/bin/:$PYTHONPATH
>>>>>
>>>>>
>>>>> [...]
>>>> This one is nice.
>>>> Can you try to run one of the failed tests by hand, for example:
>>>>
>>>>
>>>> PYTHONPATH=/local/nolden/itk-bin-wo-cswig/Wrapping/WrapITK/ 
>>>> Python/:/local/nolden/itk-bin-wo-cswig/bin/:$PYTHONPATH
>>>>
>>>> /usr/bin/python /usr/bin/python
>>>> /local/nolden/itk-3.4.0/InsightToolkit-3.4.0/Wrapping/WrapITK/ 
>>>> Python/Tests/template.py;
>>>>
>>>> echo $?
>>>>
>>>> ? (There is no output log for this one in
>>>> http://www.itk.org/Testing/Sites/mbi056/Linux-c++/20071128-0957- 
>>>> Experimental/Results/ 
>>>> __Wrapping_WrapITK_Python_Tests_PythonTemplate.html)
>>>>
>>>>
>>>>
>>> Segmentation fault, see attached gdb output.
>>
>> the result is weird: the segfault seems to be in the import of  
>> pyexpat.
>> I've checked on my system (with python 2.4): this module is not  
>> loaded
>> in that test.
>> Can you locate which python command makes the program segfault?
>>
> I will try to find this out tomorrow. Also weird is the reference to
> "apport.report", which seems to be related to the ubuntu global crash
> handler Apport (https://wiki.ubuntu.com/Apport ) So maybe the stack
> trace is not  related to the crash itself.
>
>>>
>>>> Also, can you check if the tests are always failing? I suspect a  
>>>> problem
>>>> with itkTestDriver, rather than a problem in python layer.
>>>> I think you know how to use ctest, but just in case I'm wrong:  
>>>> you can
>>>> choose to run only the python tests with the command "ctest -R  
>>>> Python",
>>>> or even a single test with "ctest -R PythonTemplate" for example.
>>>>
>>> Same segfault for the MedianImageFilter test.
>>>
>>>  Just for fun I tried executing it with python2.4 and at least got a
>>> python error (after lots of warnings abount mismatching API  
>>> versions):
>>> Traceback (most recent call last):
>>>   File
>>> "/local/nolden/itk-3.4.0/InsightToolkit-3.4.0/Wrapping/WrapITK/ 
>>> Python/Tests/MedianImageFilter.py",
>>>
>>> line 13, in ?
>>>     filter  = itk.MedianImageFilter[IType, IType].New( reader,
>>> Radius=eval( argv[3] ) )
>>>   File
>>> "/local/nolden/itk-bin-wo-cswig/Wrapping/WrapITK/Python/ 
>>> itkTemplate.py",
>>> line 357, in New
>>>     attrib(value)
>>>   File "/local/nolden/itk-bin-wo-cswig/bin/itkMedianImageFilter.py",
>>> line 155, in SetRadius
>>>     def SetRadius(*args): return
>>> _itkMedianImageFilter.itkMedianImageFilterIUS2IUS2_Pointer_SetRadius 
>>> (*args)
>>>
>>> TypeError: Expected a pointer
>>>
>>> Don't know if this makes sense.
>>
>> This one is much clear for me: it means that a typemap have  
>> failed. Are
>> you using cableswig CVS?
>> Cableswig cvs is currently not usable with WrapITK: it now reports  
>> more
>> complete type names which are breaking the typemaps.
>>
> Yes, I'm using cableswig from CVS. The ubuntu package is broken (guess
> who had to find out ;) ). Which version does work? Can I use a
> date-based checkout from the CVS?

If you are NOT using gcc 4.2, you can use the official release:  
http://prdownloads.sourceforge.net/itk/CableSwig-ITK-3.4.0.tar.gz? 
download
If you are using gcc 4.2 (or more), well, you have to not use it  
until the problem is fixed in cableswig. Any earlier version of gcc  
would work.

>
>>> I did an additional test:
>>>
>>> 1. old wrapping method, same system:
>>> All tests fail, strangely no PYTHONPATH is set at all:
>>>
>>> http://www.itk.org/Testing/Sites/mbi056/Linux-c++/20071129-0907- 
>>> Experimental/Test.html
>>>
>>>
>>> After manually setting the path I could execute the  
>>> MedianImageFilter
>>> without errors but got a black result picture.
>>
>> maybe because of the 16bits png? Have you checked the value of the  
>> pixels?
>>
> You're right. Can't check right now if everythings correct but  
> there are
> pixel values.
>
>>>
>>> Right now I'm building ITK again with new wrapping and forced  
>>> python2.4
>>> (on ubuntu 7.10) and also started testing a x86-64 Suse 10.2.  
>>> Results
>>> should be available as an Experimental Build soon (Hostname eigg)
>>
> Ok, interesting: Using python2.4 on my ubuntu 7.10 produces the same
> error as above with the cvs cableswig. So if I get a working cableswig
> and use python2.4 everything should be fine :)

I would be surprised if that problem is only related to python 2.5: I  
have already tested it on linux and windows, and WrapITK can't work  
without that version on Mac OS X.

Gaëtan

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




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: =?ISO-8859-1?Q?Ceci_est_une_signature_=E9lectronique_PGP?=
Url : http://public.kitware.com/pipermail/insight-users/attachments/20071129/bade7abd/PGP.pgp