[Ctk-developers] Crash in ~OFCondition()

[Julien Finet]

Hi Marco,

Sorry, I don't know since when the problem appeared as we "recently" (few
months) added the DICOM support in Slicer and the crash is somewhat tricky
to reproduce and not on all machines (I had to install a VM to investigate
the issue).

Julien.

On Wed, Feb 15, 2012 at 9:13 AM, Marco Nolden
<m.nolden at dkfz-heidelberg.de>wrote:

> Hi Jörg and Julien,
>
> I'm also affected by the problem now on Fedora 16. Is there any
> workaround? I can't start our application at all. @Julien: did you notice
> which change in CTK introduced the problem?
>
> Best
> Marco
>
>
>
> On 02/03/2012 05:40 PM, Julien Finet wrote:
>
>> Hi Jorg,
>>
>> I tried to compile CTK with the latest DCTMK and I still have the "pure
>> virtual method called" crash with DCMTK trunk compiled within CTK.
>> Minor changes to CTK must be done to be able to build CTK with DCMTK
>> trunk: (see https://github.com/finetjul/**CTK/tree/dcmtk-trunk<https://github.com/finetjul/CTK/tree/dcmtk-trunk>
>> )
>>   (I then configure my ofConditionCrash project doing the following:
>> ccmake
>> -DDCMTK_DIR:STRING=~/Work/CTK/**CTK-Superbuild/CMakeExternals/**Install
>> ../src).
>> Can you suggest a work-around for the time being ?
>>
>> However, if I manually build DCMTK, then there is no crash in my project
>> ofConditionCrash. I'm not sure what's different between DCMTK in CTK and
>> a stand alone DCMTK :-/
>>
>> Anyway, when you guys rewrite the OfCondition code, can you please try
>> to build DCMTK in CTK and test the ofConditionCrash project (you might
>> want to make it a unit test within DCMTK) ?
>>
>> Thanks a lot for your help,
>> Julien.
>> p.s. see bellow a DCMTK trunk build error (ubuntu 11.10, 64bits, cmake
>> 2.8.5) with a suggested fix.
>>
>> HEAD is now at b99bb83... Don't call MSVC++ with -fvisibility=hidden.
>> [ 60%] [ 60%] No update step for 'DCMTK'
>> No patch step for 'DCMTK'
>> [ 60%] Performing configure step for 'DCMTK'
>> loading initial cache file
>> /home/julien/Work/Slicer/**Slicer4/Slicer4-Debug/CTK-**
>> build/DCMTK-cmake/tmp/DCMTK-**cache.cmake
>> CMake Error at CMake/FindICONV.cmake:20 (FIND_PACKAGE_HANDLE_STANDARD_**
>> ARGS):
>>   Unknown CMake command "FIND_PACKAGE_HANDLE_STANDARD_**ARGS".
>> Call Stack (most recent call first):
>>   CMake/3rdparty.cmake:229 (FIND_PACKAGE)
>>   CMakeLists.txt:260 (INCLUDE)
>>
>> -- Configuring incomplete, errors occurred!
>> make[5]: *** [DCMTK-cmake/src/DCMTK-stamp/**DCMTK-configure] Error 1
>> make[4]: *** [CMakeFiles/DCMTK.dir/all] Error 2
>> make[3]: *** [all] Error 2
>> make[2]: *** [CTK-prefix/src/CTK-stamp/CTK-**build] Error 2
>> make[1]: *** [CMakeFiles/CTK.dir/all] Error 2
>> make: *** [all] Error 2
>>
>> Can be fixed by adding: include(**FindPackageHandleStandardArgs) in
>> CMake/FindICONV.cmake
>>
>> On Fri, Feb 3, 2012 at 8:41 AM, Julien Finet <julien.finet at kitware.com
>> <mailto:julien.finet at kitware.**com <julien.finet at kitware.com>>> wrote:
>>
>>    Great, thanks a lot !
>>
>>    Maybe we should upgrade the DCMTK version in CTK...
>>
>>    Thanks,
>>    Julien.
>>
>>    On Fri, Feb 3, 2012 at 8:21 AM, OFFIS DICOM Team <dicom at offis.de
>>    <mailto:dicom at offis.de>> wrote:
>>
>>        Hi Julien,
>>
>>
>>            I wrote a simpler project that reproduces the crash, can you
>>            try it on your
>>            machine ?
>>
>>
>>        sure, I just did it and can confirm that the program crashes on
>>        this machine with the error message "pure virtual method called".
>>
>>
>>            Let me know how it goes. For information, I use the same
>>            DCMTK built by CTK:
>>            $ ccmake
>>            -DDCMTK_DIR=~/Work/CTK/CTK-__**noPython/CMakeExternals/__**
>> Install
>>
>>            ../src
>>
>>
>>        Thank you for the hint, I used the same version of DCMTK and
>>        could reproduce the crash. When I used the current development
>>        version from our public git repository, it did not crash. Maybe,
>>        is has to do with our ongoing efforts regarding the support of
>>        shared libraries (see CHANGES file).
>>
>>        Anyway, since the current concept of the OFCondition classes
>>        creates much trouble with both shared libraries and static
>>        objects, we are currently trying to rewrite the code.
>>
>>
>>        Regards,
>>        Jörg Riesmeier
>>        --
>>        OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
>>        E-Mail: dicom at offis.de <mailto:dicom at offis.de>, URL:
>>        http://dicom.offis.de
>>
>>
>>
>>
>
> --
> ------------------------------**------------------------------**----------
> Dipl.-Inform. Med. Marco Nolden
> Deutsches Krebsforschungszentrum       (German Cancer Research Center)
> Div. Medical & Biological Informatics          Tel: (+49) 6221-42 2325
> Im Neuenheimer Feld 280                        Fax: (+49) 6221-42 2345
> D-69120 Heidelberg                             eMail: M.Nolden at dkfz.de
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20120215/2b3b826a/attachment.html>