DcmSCP: addPresentationContext resulting in a Segfault

[Clement]

Hi guys,

I'm currently working on an application that uses DcmSCU and DcmSCP classes to retrieve DICOM files from a PACS.
Everything worked well but we have recently enabled C++11 and since then, I have got a segmentation fault whenever I add a presentation context to the DcmSCP class.

This is a small main that I have created to illustrate my problem :

Code: Select all

#include <dcmtk/config/osconfig.h>
#include <dcmtk/dcmnet/diutil.h>
#include <dcmtk/dcmdata/dcdict.h>
#include <dcmtk/dcmnet/scp.h>

#include <stdlib.h>

int main(int argc, char** argv)
{
    // Load dictionary
    dcmDataDict.wrlock().loadDictionary("/home/ctroesch/dicom.dic");
    dcmDataDict.unlock();

    // Set transfer syntaxes
    OFList < OFString > transferSyntaxes;
    transferSyntaxes.push_back(UID_LittleEndianExplicitTransferSyntax);

    // Create SCP
    DcmSCP scp;

    // Trigger Segfault
    scp.addPresentationContext(UID_CTImageStorage, transferSyntaxes);

    return EXIT_SUCCESS;
}

And this are the gdb backtraces :

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff74f426b in OFListBase::base_insert (this=0x6f17b0, pos=0x454b5f53545f4e45, newElem=0x6ae2e0) at /home/ctroesch/Workspace/FW4SPL/bp-vp-dev-cmake/build/dcmtk/dcmtk-prefix/src/dcmtk/ofstd/libsrc/oflist.cc:57
57	        newElem->prev = pos->prev;
(gdb) bt
#0  0x00007ffff74f426b in OFListBase::base_insert (this=0x6f17b0, pos=0x454b5f53545f4e45, newElem=0x6ae2e0) at /home/ctroesch/Workspace/FW4SPL/bp-vp-dev-cmake/build/dcmtk/dcmtk-prefix/src/dcmtk/ofstd/libsrc/oflist.cc:57
#1  0x00007ffff77410e0 in OFList<DcmPresentationContextItem>::insert (this=0x6f17b0, position=..., x=...) at /home/ctroesch/Workspace/FW4SPL/bp-vp-dev-cmake/build/dcmtk/dcmtk-prefix/src/dcmtk/ofstd/include/dcmtk/ofstd/oflist.h:294
#2  0x00007ffff7740edb in OFList<DcmPresentationContextItem>::push_back (this=0x6f17b0, x=...) at /home/ctroesch/Workspace/FW4SPL/bp-vp-dev-cmake/build/dcmtk/dcmtk-prefix/src/dcmtk/ofstd/include/dcmtk/ofstd/oflist.h:393
#3  0x00007ffff774073c in DcmPresentationContextMap::add (this=0x6f16a8, key=0x7ffff77ca633 "DCMSCP_GEN_PC_KEY", abstractSyntaxUID=0x6f1420 "1.2.840.10008.5.1.4.1.1.2", transferSyntaxKey=0x7ffff77ca621 "DCMSCP_GEN_TS_KEY")
    at /home/ctroesch/Workspace/FW4SPL/bp-vp-dev-cmake/build/dcmtk/dcmtk-prefix/src/dcmtk/dcmnet/libsrc/dccfpcmp.cc:107
#4  0x00007ffff773c53b in DcmAssociationConfiguration::addPresentationContext (this=0x6f1690, key=0x7ffff77ca633 "DCMSCP_GEN_PC_KEY", abstractSyntaxUID=0x6f1420 "1.2.840.10008.5.1.4.1.1.2", 
    transferSyntaxKey=0x7ffff77ca621 "DCMSCP_GEN_TS_KEY") at /home/ctroesch/Workspace/FW4SPL/bp-vp-dev-cmake/build/dcmtk/dcmtk-prefix/src/dcmtk/dcmnet/libsrc/dcasccfg.cc:61
#5  0x00007ffff77b9726 in DcmSCP::addPresentationContext (this=0x7fffffffd890, abstractSyntax=..., xferSyntaxes=..., role=ASC_SC_ROLE_DEFAULT, profile=...)
    at /home/ctroesch/Workspace/FW4SPL/bp-vp-dev-cmake/build/dcmtk/dcmtk-prefix/src/dcmtk/dcmnet/libsrc/scp.cc:1707
#6  0x0000000000401eab in main (argc=1, argv=0x7fffffffda28) at /home/ctroesch/Workspace/FW4SPL/CTR-VRRenderExt/src/f4s-ext/Utilities/SCPTest/src/main.cpp:26

Any clue on where it might come from and how I could fix that ?

Thanks a lot.
Regards

Clement

[Jan Schlamelcher]

Everything worked well but we have recently enabled C++11 and since then, I have got a segmentation fault whenever I add a presentation context to the DcmSCP class.

Which version of DCMTK are you using? Did you read this: http://support.dcmtk.org/docs-snapshot/ ... pport.html ?

[Clement]

Thanks for your link, I didn't know about C++11 activation in DCMTK

So I have compiled DCMTK 3.6.1 (20140617) using CMake and those settings :

Code: Select all

cmake ... -DDCMTK_USE_CXX11_STL:BOOL=ON -DDCMTK_CXX11_FLAGS=-std=c++11

I have then compiled my code using gcc and the "-std=c++11" configuration. The compilation went well but I still have the same segmentation fault... It may not come from C++11 after all

[Jan Schlamelcher]

Which compiler are you using? As explained in the page, DCMTK will automatically set DCMTK_CXX11_FLAGS like you did if you use a quite recent gcc for example, so you won't have to do that manually. If you are using an older gcc, try setting CMAKE_CXX_FLAGS to -std=c++ manually and don't enable DCMTK_USE_CXX11_STL, as this is not recommended for older compilers anway and might cause the problems (older Versions of DCMTK behaved as if DCMTK_USE_CXX11_STL was always enabled, as long as you were use a compiler with C++11 options).
But I don't really think thats your problem and will have a more detailed look at this.

[Jan Schlamelcher]

I just compiled you program (with changed path to the dictionary) on a quite old gcc and enabled C++11. This is my gdb output:

Code: Select all

Starting program: /home/jan/dcmtk_test/gcc-4.7/test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Inferior 1 (process 14854) exited normally]

So i can't really tell what the problem might be so far.

[Clement]

Thanks for your time Jan.

I'm using gcc 4.8.2 and if I try to compile DCMTK without the -DDCMTK_CXX11_FLAGS=-std=c++11 setting, the compilation fails and gives me that error :

Code: Select all

error: #error DCMTK was configured to use the C++11 STL, but your compiler is not configured for building with C++11 features.

It seems to be a very specific error so I will continue to investigate and maybe I will come up with a solution.

Thanks again

[Jan Schlamelcher]

That should not happen, it may be a bug in my code. As you can see, CMake should automatically set std=c++11 when using gcc 4.8.2:

Code: Select all

MACRO(ALLOW_CXX11_SUPPORT FLAGS)
  ...
  SET(DCMTK_CXX11_FLAGS ${FLAGS} CACHE STRING "Flags used to enable C++11 support.")
ENDMACRO(ALLOW_CXX11_SUPPORT)

IF(GXX_VERSION VERSION_GREATER 4.8.1 OR GXX_VERSION VERSION_EQUAL 4.8.1)
    ALLOW_CXX11_SUPPORT("-std=c++11")
...

My guess would be that you gcc exposes itself as "4.8" and not "4.8.2" which causes cmake to think its version was less than 4.8.1. So bottomline: What you do is the right way to work around this detection failure. Maybe i can find a way to enhance the detection mechanism, but that still should not fix your problem though.

EDIT: try

Code: Select all

g++ -dumpversion

, does this ouptut 4.8.2 or 4.8 ?

EDIT2: it seems gcc previous to 4.9 (what i was testing with while writing the code) only outputs the patch version when using g++ --version instead of g++ -dumpversion. This is quite ugly since i will have to parse away the other information to get the version using this command, but i think i will implement version checking based on --version in the next couple of days then.

[Clement]

Yes you are right about gcc. :)

I have tried my code on a Windows plateform (I'm on linux) and it seems to work well. I'll try on a different linux computer and let you know.

[Clement]

Ok so I've tried on OSX and Windows and it works well, but on Linux with gcc and Clang I keep getting the same result...

[Jan Schlamelcher]

Thats strage, as linux is our main developement platform. Did you compile gcc and Clang yourself? Which distribution are you using? I'll try your program on Arch-Linux / gcc 4.9.0, let's see what happens.

[Jan Schlamelcher]

http://xkcd.com/583/

Code: Select all

Starting program: /home/jan/src/snapshot_test/dcmtk_test/gcc-4.9.0/test
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[Inferior 1 (process 615) exited normally]

[Clement]

Hi Jan,

I'm on Ubuntu 14.04 and I didn't compile gcc or clang myself.
Actually, it appears that I only get this segfault in Debug mode... Could you try compiling my code in Debug mode ?

Thanks a lot.

[Jan Schlamelcher]

Actually, it appears that I only get this segfault in Debug mode... Could you try compiling my code in Debug mode ?

Ic, per default dcmtk sets itself to compile in release mode. I'll try that.
EDIT: Maybe you compiled your application in debug mode but DCMTK in release mode? That should of course not emit a segfault, but maybe it does.
EDIT2: Compiling your code in debug mode changes nothing (i guess i already did that previously, since afaik building in debug mode is CMake's "normal" default behaviour). I'll try with a debug compiled DCMTK next.

[Clement]

EDIT: Maybe you compiled your application in debug mode but DCMTK in release mode? That should of course not emit a segfault, but maybe it does.

I tried compiling my application in release and debug mode with a release and debug compiled DCMTK and it only seems to crash when using the debug version :)

[Jan Schlamelcher]

Nope, sorry, it does not want to segfault. I tried your code + debug with release DCMTK and debug DCMTK without any effect.