crash at app quit in OFCondition::~OFCondition

[Sean McBride]

Hello,

I am new to dcmtk, but have successfully built it with gcc 4 on Mac OS X 10.4 as static libraries.

If I create an empty test application project using my IDE (xCode 2.2) and simply add libdcmdata.a and libofstd.a to the project, when the application quits it crashes in the OFCondition dtor. My main() is empty, and I am not otherwise using dcmtk explicitly.

Are the 2 libraries I added insufficient? Do they depend on something else? I'm using those 2 because in my real application adding those 2 were necessary and sufficient to get things to link.

The backtrace of the crash is:

#0 0x0049fee4 in OFCondition::~OFCondition (this=0x729f18) at ../../ofstd/include/ofcond.h:350
#1 0x0070445c in __static_initialization_and_destruction_0 (__initialize_p=0, __priority=65535) at ofcond.cc:50
#2 0x007045d4 in global destructors keyed to ECC_Normal () at ofcond.cc:109
#3 0x8fe109dc in __dyld__ZN16ImageLoaderMachO13doTerminationERKN11ImageLoader11LinkContextE ()
#4 0x8fe038ec in __dyld__ZN4dyld14runTerminatorsEv ()
#5 0x90013a5c in __cxa_finalize ()
#6 0x90013904 in exit ()
#7 0x000025ec in start ()
#8 0x0000248c in start ()

Thanks for _any_ help!
Sean

[Marco Eichelberg]

Your application is crashing in the destructor of a global const object that libofstd declares (EC_Normal), which is strange because the destructor of this class and the corresponding base class are actually empty. The libraries you have linked against are sufficient, that is not your problem. It seems to me that for some reason the virtual method table for class OFConditionConst has not been instantiated by the compiler, which is the only thing I can see that could explain the application crash in the destructor. Actually using some DCMTK code inside your application will most likely solve the problem. Try declaring something like "OFCondition cond = EC_Normal;" in your main function and retry.

[Sean McBride]

Hi Marco, thanks for your reply,

I added the piece of code you suggested, and I no longer crash in ~OFCondition. Unfortunately, I now crash in ~OFListBase:

#1 0x006f71e4 in OFListBase::~OFListBase (this=0x300660) at oflist.cc:60
#2 0x004a69a0 in OFList<DcmDictEntry*>::~OFList (this=0x300660) at ../../ofstd/include/oflist.h:285
#3 0x0046b560 in DcmDictEntryList::~DcmDictEntryList (this=<incomplete type>) at dchashdi.cc:53
#4 0x004689c8 in DcmHashDict::clear (this=0x4d6a04) at dchashdi.cc:216
#5 0x00464ca0 in DcmDataDictionary::clear (this=0x4d6a04) at dcdict.cc:149
#6 0x00464ce4 in DcmDataDictionary::~DcmDataDictionary (this=0x4d6a04) at dcdict.cc:143
#7 0x00465f2c in GlobalDcmDataDictionary::~GlobalDcmDataDictionary (this=0x4d6a04) at dcdict.cc:781
#8 0x00467c48 in __static_initialization_and_destruction_0 (__initialize_p=0, __priority=65535) at dcdict.cc:61
#9 0x00467ce4 in global destructors keyed to dcmDataDict () at dcdict.cc:819
#10 0x8fe109dc in __dyld__ZN16ImageLoaderMachO13doTerminationERKN11ImageLoader11LinkContextE ()
#11 0x8fe038ec in __dyld__ZN4dyld14runTerminatorsEv ()
#12 0x90013a5c in __cxa_finalize ()
#13 0x90013904 in exit ()
#14 0x000025ec in start ()
#15 0x0000248c in start ()

Something is obviously wrong in the realm of global destructors, but I am at a loss to understand it... I am using the exact same compiler version to build both the dcmtk libraries and my application.

Is there something I could declare similiar to the "OFCondition cond = EC_Normal;" that might fix this one? Thanks!

[Marco Eichelberg]

Weird problem indeed - in this case the linker seems to optimize away some code that is really needed in the global destructors. The problem you observe now is related to the global data dictionary. Any access to the data dictionary from the main application should fix this. Try something like "OFBool result = dcmDataDict.isDictionaryLoaded();"

[Sean McBride]

Well, I have made progress. With Xcode 2.2's new gcc 4.0.1 things are better. The only time I still see these crashes now is in a debug build when ZeroLink is enabled. If I disable ZeroLink then all is well. Release builds are fine. So I guess it was/is a gcc bug afterall. Thanks.

[Hua Cong Danh]

Hi,

It is old topic, but I have run into a problem similar to this recently.
I built and used dcmtk as static library in the managed project (I used VS2008). The project was built successfully, but it crashed when I executed it. I had searched the code many times and found a strange behavior that I could not understand.

It related to OFList class and push_back() function. First, I put some code like this and the program exited with crash.

Code: Select all

OFList<OFString>   array;
OFString tmpStr;
array.push_back(tmpStr);

Then I took out "push_back()" statement then the program run successfully (without crash).

Code: Select all

OFList<OFString>   array;
OFString tmpStr;
//array.push_back(tmpStr);

Note that my program is an empty one (it does not call these code when running).

I also tried put some code like: "OFCondition cond = EC_Normal;", "OFBool result = dcmDataDict.isDictionaryLoaded();" but they did not help.

Could anyone help me to deal with this problem.

[Michael Onken]

Hi,

I do not think the error is connected to the one above. Could you write a minimal test program and try it out? If it does not work, you may post it so we can have a look.

Best regards,
Michael

[Hua Cong Danh]

Hi Micheal,

I describe the test program as below.

The main purpose of the program is call managed class from c# code.
C# code:

Code: Select all

using System;
using System.Collections.Generic;
using System.Text;

namespace test
{
    class Program
    {
        static void Main(string[] args)
        {
            TEST tst = new TEST();
            Console.WriteLine(tst.ftest());
        }
    }
}

C++ managed code:
header file

Code: Select all

#pragma managed

#ifndef __AFXWIN_H__
#error "include 'stdafx.h' before including this file for PCH"
#endif

using namespace System::Runtime::InteropServices;	// For conversion of String to char*
using namespace System;

#include "UnmanagedTest.h"

public ref class TEST{
public:
	TEST();
	~TEST();
	String^ ftest();
};

cpp file

Code: Select all

#include "stdafx.h"
#include "ManagedTest.h"

TEST::TEST(){
}
TEST::~TEST(){
}
String^ TEST::ftest(){
	return "for test";
};

Although in this program it never call unmanaged code, but i think these unmanaged code is the cause of problem.
C++ unmanaged code
header file

Code: Select all

#include "dcmtk/config/osconfig.h"    
#include "dcmtk/ofstd/ofstdinc.h"
#include "dcmtk/ofstd/ofstd.h"
#include "dcmtk/ofstd/ofconapp.h"
#include "dcmtk/ofstd/ofdatime.h"
#include "dcmtk/dcmnet/dicom.h"        
#include "dcmtk/dcmnet/dimse.h"
#include "dcmtk/dcmnet/diutil.h"
#include "dcmtk/dcmnet/dcasccfg.h"      
#include "dcmtk/dcmnet/dcasccff.h"     
#include "dcmtk/dcmdata/dcfilefo.h"
#include "dcmtk/dcmdata/dcuid.h"
#include "dcmtk/dcmdata/dcdict.h"
#include "dcmtk/dcmdata/cmdlnarg.h"
#include "dcmtk/dcmdata/dcmetinf.h"
#include "dcmtk/dcmdata/dcuid.h"       
#include "dcmtk/dcmdata/dcdeftag.h"
#include "dcmtk/dcmdata/dcostrmz.h"     

class dcmtkTest
{
public:
  dcmtkTest();
  ~dcmtkTest();
  void test();
};

cpp file

Code: Select all

#include "stdafx.h"

#include "UnmanagedTest.h"

dcmtkTest::dcmtkTest()
{
}
dcmtkTest::~dcmtkTest()
{
}
void dcmtkTest::test()
{
	OFList<OFString>   outputFileNameArray;
	OFString tmpStrabc;
	outputFileNameArray.push_back(tmpStrabc);
}

When the program is run, it exit with error:
"Unhandled exception at 0x75d0d36f in test.exe: 0xC0020001: The string binding is invalid."

Thanks

[Michael Onken]

Hi,

this seems to be a problem caused by specific combinations of managed code calling unmanaged code with the latter coping with static variables.

I have no experiences with managed code so I cannot help you with this one easily.

If you google you can find several people having the same problem, not corresponding to DCMTK, so I do not think this is DCMTK-specific. A workaround (if this is identical with your problem) may be described by Microsoft itself.

HTH,
Michael

[Hua Cong Danh]

Hi,

I have solved the problem by separate managed code and unmanaged code in different compilation (refer to this instruction).
The program run OK now .

So the problem is not caused by DCMTK.

Regards