crash at app quit in OFCondition::~OFCondition
Moderator: Moderator Team
-
- Posts: 3
- Joined: Thu, 2005-10-20, 21:54
crash at app quit in OFCondition::~OFCondition
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
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
-
- OFFIS DICOM Team
- Posts: 1444
- Joined: Tue, 2004-11-02, 17:22
- Location: Oldenburg, Germany
- Contact:
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.
-
- Posts: 3
- Joined: Thu, 2005-10-20, 21:54
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!
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!
-
- OFFIS DICOM Team
- Posts: 1444
- Joined: Tue, 2004-11-02, 17:22
- Location: Oldenburg, Germany
- Contact:
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();"
-
- Posts: 3
- Joined: Thu, 2005-10-20, 21:54
-
- Posts: 16
- Joined: Thu, 2011-08-18, 09:40
Crash as application quit
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.
Then I took out "push_back()" statement then the program run successfully (without crash).
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.
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);
Code: Select all
OFList<OFString> array;
OFString tmpStr;
//array.push_back(tmpStr);
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.
-
- DCMTK Developer
- Posts: 2049
- Joined: Fri, 2004-11-05, 13:47
- Location: Oldenburg, Germany
- Contact:
-
- Posts: 16
- Joined: Thu, 2011-08-18, 09:40
Hi Micheal,
I describe the test program as below.
The main purpose of the program is call managed class from c# code.
C# code:
C++ managed code:
header file
cpp file
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
cpp file
When the program is run, it exit with error:
"Unhandled exception at 0x75d0d36f in test.exe: 0xC0020001: The string binding is invalid."
Thanks
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());
}
}
}
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();
};
Code: Select all
#include "stdafx.h"
#include "ManagedTest.h"
TEST::TEST(){
}
TEST::~TEST(){
}
String^ TEST::ftest(){
return "for test";
};
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();
};
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);
}
"Unhandled exception at 0x75d0d36f in test.exe: 0xC0020001: The string binding is invalid."
Thanks
-
- DCMTK Developer
- Posts: 2049
- Joined: Fri, 2004-11-05, 13:47
- Location: Oldenburg, Germany
- Contact:
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
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
-
- Posts: 16
- Joined: Thu, 2011-08-18, 09:40
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
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
Who is online
Users browsing this forum: No registered users and 1 guest