Hans:

This is really disturbing. I spent many hours this weekend tracking down the problem, and it is really weird.

It seems to be failing differently on different computers/compilers, so I am looking into a valgrind build to see if some memory corruption is occurring.

When debugging I have the equivalent of:

std::cout << "PRE: " << LBFSGBoptimizer->GetUpperBound().size() << " " << localUpperBound.size() << std::endl;
#PRE: 0 9645
LBFSGBoptimizer->SetUpperBound(localUpperBound);

std::cout << "POST: " << LBFSGBoptimizer->GetUpperBound().size() << " " << localUpperBound.size() << std::endl;
#POST: 0 9645 <----- THIS IS WRONG!!! it should be POST: 9645 9645

=========
When I step into the SetUpperBound function with the debugger, m_UpperBound = localUpperBound seems to work and does set the values of m_UpperBound inside the function, but as soon as it returns, the optimizer->GetUpperBound().size() is not correct.

==========

This is passing on all stand-alone static builds of BRAINSTools, but the internal slicer build is failing.

==========

I'll continue to work on it this week, but it seems like a bigger nastier problem than a bug in BRAINSFit alone.

Hans

From: Steve Pieper <pieper@ibility.net>

I just tried the current nightly build and got the same crash as yesterday when running registration.

It's clearly something still screwed up with the IO factories and linking - the stack below should never happen:

Thread 4 Crashed:
0 libITKIOHDF5-4.4.1.dylib 0x000000010339fc08 std::vector<double, std::allocator<double> >::operator=(std::vector<double, std::allocator<double> > const&) + 56
1 libvtkSlicerEMSegmentModuleLogic.dylib0x0000000117ad0269 itk::MattesMutualInformationImageToImageMetric<itk::Image<float, 3u>, itk::Image<float, 3u> >::GetValueAndDerivativeThreadPreProcess(unsigned int, bool) const + 105
2 libBRAINSFitEZLib.dylib 0x000000011df416ed itk::BRAINSFitHelper::Update() + 557
3 libBRAINSFitEZLib.dylib 0x000000011ddeff41 ModuleEntryPoint + 74417
4 libqSlicerBaseQTCLI.dylib 0x0000000100227e11 vtkSlicerCLIModuleLogic::ApplyTask(void) + 32545
5 libSlicerBaseLogic.dylib 0x00000001030a064f vtkSlicerApplicationLogic::ProcessProcessingTasks() + 127
6 libSlicerBaseLogic.dylib 0x00000001030a07af vtkSlicerApplicationLogic::ProcessingThreaderCallback(void) + 31
7 libsystem_c.dylib 0x00007fff8fa518bf _pthread_start + 335
8 libsystem_c.dylib 0x00007fff8fa54b75 thread_start + 13

On Sat, Apr 6, 2013 at 9:12 AM, Johnson, Hans J <hans-johnson@uiowa.edu> wrote:

This is weird.

Inside of Slicer build tree, I make a separate LOCAL_BRAINSTools-build directory and I build a separate build tree FROM THE SAME SOURCE TREE USED BY SLICER!  

My build ( a Static Build) works, Slicer build of the same source code ( a shared lib build)  fails with a weird exception about a variable that is not initialized.

Hans

Okay - we'll, I did a little experimenting and found out what is up. Do I win a prize? ;D

It turns out that the BRAINSTools build turns on ITK_FUTURE_LEGACY_REMOVE [1] but slicer's ITK build turns it off. The impact of this flag [3] is to disable certain methods, so now it makes some sense why code compiled with the legacy methods removed would have incorrect virtual function pointers when linked against libraries where the legacy methods existed.

If BRAINSFit requires this flag to be set, then it should probably refuse to compile against a version of ITK where the flag was not set.

As a side complication, turning off the legacy code also means you cannot turn on ITKV3_COMPATIBILITY, which slicer currently needs in order to build.

The best way forward is probably for us to move slicer's code entirely to ITKv4 and turn off the legacy and v3 compatibility features from the build.

I suggest we look at this next at the slicer hangout.

[1] https://github.com/BRAINSia/BRAINSTools/blob/master/Common.cmake#L176

[2] https://github.com/Slicer/Slicer/blob/master/SuperBuild/External_ITKv4.cmake#L97

[3] https://github.com/Kitware/ITK/blob/master/Modules/Core/Common/include/itkMacro.h#L401

Here's a fix that works for me after a rebuild:

https://github.com/BRAINSia/BRAINSTools/pull/26

commit ea67a47cc5a2f043c4d24e167335a6ccd5bab963
Author: hjohnson <hjohnson@3bd1e089-480b-0410-8dfb-8563597acbee>
Date: Mon Apr 22 20:52:09 2013 +0000

ENH: Reset BRAINSTools to build without the ITK_FUTURE_LEGACY_REMOVE

The inconsistent use of ITK_FUTURE_LEGACY_REMOVE was causing major runtime
errors with regards to virtual functions being located in different places
in the object files between compilation units.

This update also turns off many new tools that are not ready for
distribution with Slicer.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21906 3bd1e089-480b-0410-8dfb-8563597acbee

=====

In addition, a patch set is being reviewed for ITKv4 that will make using the ITK_FUTURE_LEGACY_REMOVE feature easier to use.

Closing resolved issues that have not been updated in more than 3 months