'pure virtual method' crash on exit (linux/gcc)

Compilation and installation of DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
kuhagen
Posts: 1
Joined: Thu, 2007-02-08, 13:59
Location: Bremen, Germany

'pure virtual method' crash on exit (linux/gcc)

#1 Post by kuhagen »

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

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1437
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

#2 Post by Marco Eichelberg »

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.

jprecio
Posts: 6
Joined: Tue, 2007-03-27, 23:02

#3 Post by jprecio »

Hi,
I've the same problem and I wonder if you could tell me how did you solved it (if you have solved it :-))

Thanks,
Javier

kamil
Posts: 63
Joined: Fri, 2009-04-17, 09:18

#4 Post by kamil »

jprecio wrote:Hi,
I've the same problem and I wonder if you could tell me how did you solved it (if you have solved it :-))

Thanks,
Javier
Hi, the same problem, how to solve it ? Thank you!

phahn
Posts: 5
Joined: Fri, 2009-08-21, 13:28

Problem still exists in 3.6.0

#5 Post by phahn »

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?

Uli Schlachter
DCMTK Developer
Posts: 120
Joined: Thu, 2009-11-26, 08:15

#6 Post by Uli Schlachter »

My suggestion would be not to call into any external code in static destructors.
What is your static destructor doing anyway? Does the same happen with a static library instead of a dynamic one?

tarento
Posts: 2
Joined: Mon, 2012-01-30, 10:03

Same problem for me

#7 Post by tarento »

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 ...

chaircrusher
Posts: 32
Joined: Tue, 2011-12-20, 23:24
Location: iowa city,ia

#8 Post by chaircrusher »

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.
This was already reported by Sean McBride 7 years ago: viewtopic.php?t=503

chaircrusher
Posts: 32
Joined: Tue, 2011-12-20, 23:24
Location: iowa city,ia

#9 Post by chaircrusher »

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.
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.

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.

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

#10 Post by J. Riesmeier »

We've just committed a major rewrite of the OFCondition class that should solve this (and all related) issues.

tarento
Posts: 2
Joined: Mon, 2012-01-30, 10:03

#11 Post by tarento »

I have just tried the 20120222 snapshot -> It works

Thanks

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest