[Insight-users] ResampleImageFilter crashes in release mode

[Bill Lorensen]

Maybe there is a clash of the symbols between the two libraries. We
should try to track this down. ITK should have very few external
static variables. In general that's back coding practice to have these
global symbols.

On Tue, Jul 7, 2009 at 5:08 PM, Luis Ibanez<luis.ibanez at kitware.com> wrote:
>
> Hi Michael,
>
>
>   Thanks for testing the code in your platform.
>
>
> The fact that the order of libraries matters may indicate
> that the problem results from the order of initialization
> of a static variable.
>
> Something that may originate from any singleton class,
> or from any of our static variables in ITK or in
> wxWindows...
>
>
> Thanks for posting to the list the solution that
> you found.
>
> We probably should put this somewhere
> in the ITK Wiki...
>
> Maybe in the FAQ...
>
>
>
>    Thanks
>
>
>       Luis
>
>
>
> ------------------------
> Michael Schildt wrote:
>>
>> Hello Luis,
>>
>> first of all, thank you a lot for the efforts you are putting into
>> answering my questions and for your hints. It helps me a lot but raises some
>> new questions.
>> Your modified example runs and runs not under windows. It depends on the
>> order of library linking. If ITK comes first the program runs fine. If
>> wxWidgets comes first it does not. The same is true for my first example.
>> So, without any changes in source both are running fine with the right
>> linking order.
>>
>> 1) I changed the order of lines for linking in your CMakeLists.txt to:
>>  TARGET_LINK_LIBRARIES(itkWxWindows
>>    ${wxWidgets_LIBRARIES}
>>    ITKCommon
>>    )
>>
>> Then the example crashs again at resampler->Update().
>>
>> With this new insights, i checked against my application by changing the
>> order of the linking. And, it runs perfect now. It seems order is important
>> but normally it must not.
>>
>> Luis Ibanez schrieb:
>>
>>>
>>> Hi Michael,
>>>
>>> Thanks for reducing the problem to a minimal
>>> example and posting it to the list.
>>>
>>> I have build your code under Linux (Ubuntu)
>>> and ran Valgrind on it.
>>>
>>> Found that you were not initializing the pixel
>>> data of the memory buffers passed to the
>>> Import filter, and fixed that.
>>>
>>> Also fixed an assignment between smart
>>> pointers that was not compiling under gcc
>>>
>>>  TransformType::ConstPointer cversor = iversor;
>>>
>>> was replaced with:
>>>
>>>  TransformType::ConstPointer cversor = iversor.GetPointer();
>>
>> 2) What is the difference between first and second statement? Or better,
>> what is GetPointer() doing and when to use the method call and when to use
>> the object directly? (documentation says about GetPointer: "Access function
>> to pointer.")
>>
>>>
>>>
>>> although a better solution is to change the API of
>>> your "transformImage" method to take const raw
>>> pointers instead of SmartPointer. (the code was
>>> modified accordingly).
>>
>> 3) That is somehow ambiguous. Within my custom library i do it always that
>> way. Just within ITK i use the smartpointers, because it is recommended. As
>> far as i understood, Smartpointer are better than normal pointer, because
>> they know how many references are held to the object and it can be destroyed
>> automatically when the number of references become zero.
>> So, please can you specfify a rule when to use smartpointer and when to
>> use normal  pointers for ITK?
>>
>>>
>>> The code runs under Linux, both under Release and
>>> Debug without crashing.
>>
>> 4) I will check under Linux later. I did not test this issue under Linux
>> until now.
>>
>>>
>>> Please find the modified code attached.
>>>
>>> (Note that, I put the boolean flag of the import filter
>>> to "true", temporarily, in order to avoid a memory
>>> leak report in Valgrind. You probably want to
>>> put it back to "false" in your code).
>>>
>>> Also, note that you will need to copy in the same
>>> directory as the main.cxx, the file:
>>>
>>>   Insight/Testing/Code/BasicFilters/itkFilterWatcher.h
>>>
>>> This is just to capture progress events.
>>>
>>>
>>> Please try the attached code and let us know
>>> if that makes any difference when you run it
>>> in your Windows system.
>>>
>>>
>> 5) What is SetOutputDirection() good for - documentation says: "Set the
>> output direciton cosine matrix."
>> But actually, i do not understand what this means. Could you help me out
>> once more?
>>
>>
>> With best reguards,
>>   Michael Schildt
>>
>>>
>>>      Regards,
>>>
>>>
>>>           Luis
>>>
>>>
>>> ---------------------------------------------------------
>>> On Mon, Jul 6, 2009 at 5:39 AM, Michael Schildt
>>> <michael.schildt at ifn-magdeburg.de <mailto:michael.schildt at ifn-magdeburg.de>>
>>> wrote:
>>>
>>>    Hello Luis,
>>>
>>>    I checked your points 1) and 3) to 5) but had no luck.
>>>
>>>    But with 2) i have tracked down the problem to be an interplay of
>>>    ITK and wxWidgets and found a workaround too.
>>>    Basically, when i use an wxSplitterWindow ITK crashes, when
>>>    commenting the wxSlitterWindow stuff out ITK works as expected. I
>>>    used ITK 3.14, wxPack 2.8.9 and Visual Studio 2008 Express Edition.
>>>    I have created a minimal example application (main.cpp,
>>>    CMakeLists.txt) attched at the end of the message that makes this
>>>    problem reproducable without additional dependencies. Running in
>>>    Release or RelWithDebInfo will crash under Windows XP at
>>>    resampler->Update(). Commenting out line 36 (m_splitter2 = new
>>>    wxSplitterWindow( this, wxID_ANY, wxDefaultPosition,
>>>    wxDefaultSize, 0 );) will make ITK running smooth without a crash.
>>>
>>>    And, a workaround was found while trying program on an other  PC.
>>>    By using wxPack 2.8.8 instead of wxPack 2.8.9 the problem is gone.
>>>    So, a downgrade to prior minor Version of wxWidgets is sufficient.
>>>
>>>    But, i have not really an exmplaination for that. Especially the
>>>    fact that the splitter in not instanciated before ITK runs. Would
>>>    be nice to find how wxWidgets influences ITK!
>>>
>>>    Best reguards,
>>>      Michael Schildt
>>>
>>>
>>>
>>
> _____________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.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-users
>