'pure virtual method' crash on exit (linux/gcc)
Moderator: Moderator Team
'pure virtual method' crash on exit (linux/gcc)
Hello
I have a shared lib, linked against a static version of dcmtk. The app linked against the shared lib crashes on exit. The backtrace of the crash is:
#10 0x03d80ec2 in std::terminate () from /usr/lib/libstdc++.so.6
#11 0x03d81565 in __cxa_pure_virtual () from /usr/lib/libstdc++.so.6
#12 0x03abd1c8 in ~OFCondition (this=0x3bb7504) at ../dcmtk/ofstd/include/dcmtk/ofstd/ofcond.h:350
Looking at ofcond.h:350 shows me, that there is indeed called a pure virtual method in the destructor of OFCondition (namely theCondition->deletable() with 'theCondition' being of type OFConditionBase, which defines deletable() as pure virtual), so the message is correct. The question is: is this a bug in DCMTK or a consequence of wrong usage of OFCondition?
For info: the OS is Linux, gcc is version 4.1.1, dcmtk is 3.5.4
I found an old posting with a very similar problem (viewtopic.php?t=503), but the suggested solutions there did not change anything.
Is the problem known, or has someone some info for me, where to look and how to solve the problem?
Thanks in advance, regards
Stephan
I have a shared lib, linked against a static version of dcmtk. The app linked against the shared lib crashes on exit. The backtrace of the crash is:
#10 0x03d80ec2 in std::terminate () from /usr/lib/libstdc++.so.6
#11 0x03d81565 in __cxa_pure_virtual () from /usr/lib/libstdc++.so.6
#12 0x03abd1c8 in ~OFCondition (this=0x3bb7504) at ../dcmtk/ofstd/include/dcmtk/ofstd/ofcond.h:350
Looking at ofcond.h:350 shows me, that there is indeed called a pure virtual method in the destructor of OFCondition (namely theCondition->deletable() with 'theCondition' being of type OFConditionBase, which defines deletable() as pure virtual), so the message is correct. The question is: is this a bug in DCMTK or a consequence of wrong usage of OFCondition?
For info: the OS is Linux, gcc is version 4.1.1, dcmtk is 3.5.4
I found an old posting with a very similar problem (viewtopic.php?t=503), but the suggested solutions there did not change anything.
Is the problem known, or has someone some info for me, where to look and how to solve the problem?
Thanks in advance, regards
Stephan
-
- OFFIS DICOM Team
- Posts: 1446
- Joined: Tue, 2004-11-02, 17:22
- Location: Oldenburg, Germany
- Contact:
First of all, this problem has not yet been noted, but then we don't usually use DCMTK in a shared library environment. My best guess is that there is a problem with the order of destruction of OFCondition objects. DCMTK uses quite a few static OFConditionConst objects which are referenced by OFCondition objects if these contain one of the standard error codes, such as EC_Normal. If these objects are destructed at a point in time when there is still an OFCondition object in use, then the destructor of the OFCondition object will de-reference a pointer to an object that does not exist anymore, and that could possibly cause the problem you see. I have to admit that I have never checked details about the order of execution of global constructors and destructors when contained in shared objects, but I could imagine something going wrong there.
Problem still exists in 3.6.0
I have exactly the same situation and the problem is still present in DCMTK 3.6.0.
@Marco Eichelberg
As you mentioned you don't usually use DCMTK as a shared library. I was wondering how you use it. I think building some shared module that handles DICOM and internally makes use of DCMTK sounds like a very common approach. What do you suggest to solve the problem?
@Marco Eichelberg
As you mentioned you don't usually use DCMTK as a shared library. I was wondering how you use it. I think building some shared module that handles DICOM and internally makes use of DCMTK sounds like a very common approach. What do you suggest to solve the problem?
-
- DCMTK Developer
- Posts: 120
- Joined: Thu, 2009-11-26, 08:15
Same problem for me
I have the same problem with DCMTK 3.6.0, shared linked, gcc 4.1.2 32 bits.
I tried the OFCondition variable Hack but it does nothing.
Has someone a solution for this ...
I tried the OFCondition variable Hack but it does nothing.
Has someone a solution for this ...
-
- Posts: 32
- Joined: Tue, 2011-12-20, 23:24
- Location: iowa city,ia
This was already reported by Sean McBride 7 years ago: viewtopic.php?t=503Marco Eichelberg wrote:First of all, this problem has not yet been noted, but then we don't usually use DCMTK in a shared library environment.
-
- Posts: 32
- Joined: Tue, 2011-12-20, 23:24
- Location: iowa city,ia
1. DCMTK needs to work as a shared library. This is almost always how libraries are deployed as Linux packages, and there are many applications that for one reason or another REQUIRE linking shared.Marco Eichelberg wrote:First of all, this problem has not yet been noted, but then we don't usually use DCMTK in a shared library environment. My best guess is that there is a problem with the order of destruction of OFCondition objects. DCMTK uses quite a few static OFConditionConst objects which are referenced by OFCondition objects if these contain one of the standard error codes, such as EC_Normal. If these objects are destructed at a point in time when there is still an OFCondition object in use, then the destructor of the OFCondition object will de-reference a pointer to an object that does not exist anymore, and that could possibly cause the problem you see. I have to admit that I have never checked details about the order of execution of global constructors and destructors when contained in shared objects, but I could imagine something going wrong there.
2. If DCMTK is dependent on the order of destruction of static global objects, then it is dependent on undefined behavior with respect to C++ standards.
I'm seeing a different problem -- a free of unallocated memory -- in the static object destructors called after main() exits. This -- I suspect -- is because a destructor is being called on the same object more than once. I'm building on a system I can use valgrind on to test this hypothesis.
-
- DCMTK Developer
- Posts: 2506
- Joined: Tue, 2011-05-03, 14:38
- Location: Oldenburg, Germany
- Contact:
We've just committed a major rewrite of the OFCondition class that should solve this (and all related) issues.
Who is online
Users browsing this forum: Amazon [Bot] and 1 guest