[Insight-users] Cannot access LightObject functions in object instantiated in DLL

Cory Quammen cquammen at cs.unc.edu
Wed May 12 10:20:48 EDT 2010


Dear Gao,

> Thank you for your answer. I do think that function is correct, as in it
> does not give the problems. I purposely added that function to show that the
> problem was really in the itk::LightObject. The function was added *after* I
> found the problem.

Thanks for clarifying. Nevertheless, functions that return a pointer
to an object allocated on the stack will almost always cause you a
world of hurt down the road. See the section "Pointer persistence" on
this page: http://www.yolinux.com/TUTORIALS/C++MemoryCorruptionAndMemoryLeaks.html

As for the rest of your problem, you've gone way beyond my expertise
in ITK's reference counting mechanism. Sorry I can't help you there.

Cory

> Today, I spent the whole day on tracking down the cause of this problem, and
> I think I found it. When I intantiate the filter, I used a common pointer.
> If I would directly run the member function Register() the program crashed,
> as Register() is a member function of LightObject. So I tried to instantiate
> directly into a smart pointer, and also then I got a crash when running
> member functions of LightObject. However, if I manually run Register() on
> the smart pointer, directly after creating, everything works fine, but I do
> have to run a UnRegister() when destroying the object, otherwise it will
> result in a memory leak. Why it works this way is totally beyond me, but
> then again, I do not have any experience with working with DLLs. If you have
> any suggestions to what is going wrong, I would greatly appreciate to hear
> this.
>
> Thank you again for responding to my message.
>
> Sincerely,
>
> Gao Han
>
> For reference, I put the code in the form of a macro, which you can find it
> below here:
>
> // Macro for setting input. Arguments:
> //          dataT       - Type of the data
> //          dataE       - Enumeration label of the data
> //          dataO       - The data object
> //          typeI       - value keeping track of the current filter type
> //          filterT     - Current filter type
> //          filterO     - Filter Object
> //          nextO       - Next filter in the chain
> #define SET_INPUT( dataT , dataE , dataO, typeI , filterT , filterO, nextO )
> \
>        {
> \
>            MCAD::dataT * d = dynamic_cast<MCAD::dataT *>(dataO);
> \
>            if (d)
> \
>            {
> \
>                filterT * f = dynamic_cast<filterT *>(filterO.GetPointer());
> \
>                if (!f)
> \
>                {
> \
>                    filterT::Pointer nf = filterT::New();
> \
>                    nf->Register();
> \
>                    f = nf.GetPointer();
> \
>                    typeI = MCAD::dataE;
> \
>                }
> \
>                f->SetInput(d);
> \
>                nextO->SetInput(f->GetOutput());
> \
>                filterO = f;
> \
>                return true;
> \
>            }
> \
>        }
>
>
>
> Cory Quammen wrote:
>>
>> This line
>>
>>>    std::cout << filt->tralalie() << "\n";           // Fine....
>>
>> May be causing a problem.
>>
>> In your function
>>
>>>    char * tralalie() {return "In itkImageToVTKImageFilter.h";}
>>
>> Here you are allocating a character array on the stack which is
>> deallocated as soon as tralalie() returns. When you print out the
>> return value from tralalie(), std::cout steps through the now-invalid
>> memory. It probably works well enough to fool you into thinking it
>> works, but it could be corrupting memory in a way that doesn't show up
>> until you call
>>
>> std::cout << filt->GetReferenceCount() << "\n";    // Crash with
>>
>> Try removing the call to filt-tralalie() and see if that fixes your
>> problem.
>>
>> Hope that helps,
>> Cory
>>
>> --
>> Cory Quammen
>> Center for Computer Integrated Systems for Microscopy and Manipulation
>> (CISMM)
>> Department of Computer Science
>> University of North Carolina at Chapel Hill
>> http://www.cs.unc.edu/~cquammen
>> _____________________________________
>> 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://www.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-users
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Cannot-access-LightObject-functions-in-object-instantiated-in-DLL-tp28522610p28535624.html
> Sent from the ITK - Users mailing list archive at Nabble.com.
>
> _____________________________________
> 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://www.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-users
>



-- 
Cory Quammen
Center for Computer Integrated Systems for Microscopy and Manipulation (CISMM)
Department of Computer Science
University of North Carolina at Chapel Hill
http://www.cs.unc.edu/~cquammen


More information about the Insight-users mailing list