Memory leak with simple DcmSCPPool

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
theonlylawislove
Posts: 34
Joined: Thu, 2014-07-17, 09:07

Memory leak with simple DcmSCPPool

#1 Post by theonlylawislove »

I am experiencing a memory leak running minimal DcmSCPPool

Code: Select all

class ServerThreadSCP : public DcmThreadSCP
{
public:
    ServerThreadSCP()
    {

    }
};

class ServerSCPPool : public DcmSCPPool<ServerThreadSCP>
{
public:

};

struct ProcessThread : public OFThread
{
public:
    OFCondition result;
    bool isRunning;
    ServerSCPPool* pool;
    ProcessThread(ServerSCPPool* pool)
    {
        result = EC_Normal;
        this->isRunning = false;
        this->pool = pool;
    }
protected:
    void run()
    {
        result = pool->listen();
        isRunning = false;
    }
};


Code: Select all

auto pool = new ServerSCPPool();
auto thread = new ProcessThread(pool);

DcmSCPConfig& config = pool->getConfig();
config.setPort(peerPort);
config.setAETitle(aeTitle);
config.setHostLookupEnabled(true);

OFList<OFString> echoTransferSyntaxes;
echoTransferSyntaxes.push_back(UID_LittleEndianImplicitTransferSyntax);
config.addPresentationContext(UID_VerificationSOPClass, echoTransferSyntaxes);

pool->setMaxThreads(100);

thread->start();
Then, I use the precompiled echoscu binaries and a bash script to repeatedly send echo requests.

Code: Select all

#!/bin/bash

while true
do
echoscu localhost 5001
done
Then, you will see memory climb up very quickly.

theonlylawislove
Posts: 34
Joined: Thu, 2014-07-17, 09:07

Re: Memory leak with simple DcmSCPPool

#2 Post by theonlylawislove »

This is what valgrind gives me, if it helps.

Code: Select all

==25837== Memcheck, a memory error detector
==25837== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==25837== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==25837== Command: ./medxdcmtk-cons
==25837== Parent PID: 30409
==25837== 
--25837-- 
--25837-- Valgrind options:
--25837--    -v
--25837--    --tool=memcheck
--25837--    --leak-check=full
--25837--    --num-callers=40
--25837--    --log-file=valgrind.log
--25837-- Contents of /proc/version:
--25837--   Linux version 4.4.0-65-generic (buildd@lgw01-12) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #86-Ubuntu SMP Thu Feb 23 17:49:58 UTC 2017
--25837-- 
--25837-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-avx-avx2-bmi
--25837-- Page sizes: currently 4096, max supported 4096
--25837-- Valgrind library directory: /usr/lib/valgrind
--25837-- Reading syms from /mnt/LinuxData/git/medxchange.dicom/native/projects/build-medxdcmtk-cons-Desktop_Qt_5_8_0_GCC_64bit-Debug/medxdcmtk-cons
--25837-- Reading syms from /lib/x86_64-linux-gnu/ld-2.23.so
--25837--   Considering /lib/x86_64-linux-gnu/ld-2.23.so ..
--25837--   .. CRC mismatch (computed e101f79f wanted 8d6608d4)
--25837--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.23.so ..
--25837--   .. CRC is valid
--25837-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux
--25837--   Considering /usr/lib/valgrind/memcheck-amd64-linux ..
--25837--   .. CRC mismatch (computed 5529a2c7 wanted 5bd23904)
--25837--    object doesn't have a symbol table
--25837--    object doesn't have a dynamic symbol table
--25837-- Scheduler: using generic scheduler lock implementation.
--25837-- Reading suppressions file: /usr/lib/valgrind/default.supp
==25837== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-25837-by-pknopf-on-???
==25837== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-25837-by-pknopf-on-???
==25837== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-25837-by-pknopf-on-???
==25837== 
==25837== TO CONTROL THIS PROCESS USING vgdb (which you probably
==25837== don't want to do, unless you know exactly what you're doing,
==25837== or are doing some strange experiment):
==25837==   /usr/lib/valgrind/../../bin/vgdb --pid=25837 ...command...
==25837== 
==25837== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==25837==   /path/to/gdb ./medxdcmtk-cons
==25837== and then give GDB the following command
==25837==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=25837
==25837== --pid is optional if only one valgrind process is running
==25837== 
--25837-- REDIR: 0x401cdc0 (ld-linux-x86-64.so.2:strlen) redirected to 0x3809e181 (???)
--25837-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so
--25837--   Considering /usr/lib/valgrind/vgpreload_core-amd64-linux.so ..
--25837--   .. CRC mismatch (computed a30c8eaa wanted 7ae2fed4)
--25837--    object doesn't have a symbol table
--25837-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so
--25837--   Considering /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so ..
--25837--   .. CRC mismatch (computed 402c2ab5 wanted 745f25ae)
--25837--    object doesn't have a symbol table
==25837== WARNING: new redirection conflicts with existing -- ignoring it
--25837--     old: 0x0401cdc0 (strlen              ) R-> (0000.0) 0x3809e181 ???
--25837--     new: 0x0401cdc0 (strlen              ) R-> (2007.0) 0x04c31020 strlen
--25837-- REDIR: 0x401b710 (ld-linux-x86-64.so.2:index) redirected to 0x4c30bc0 (index)
--25837-- REDIR: 0x401b930 (ld-linux-x86-64.so.2:strcmp) redirected to 0x4c320d0 (strcmp)
--25837-- REDIR: 0x401db20 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x4c35270 (mempcpy)
--25837-- Reading syms from /mnt/LinuxData/git/medxchange.dicom/native/projects/build-medxdcmtk-cons-Desktop_Qt_5_8_0_GCC_64bit-Debug/libdcmtk.so.10
--25837-- Reading syms from /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
--25837--   Considering /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 ..
--25837--   .. CRC mismatch (computed 834c912e wanted c67ab13d)
--25837--    object doesn't have a symbol table
--25837-- Reading syms from /lib/x86_64-linux-gnu/libgcc_s.so.1
--25837--   Considering /lib/x86_64-linux-gnu/libgcc_s.so.1 ..
--25837--   .. CRC mismatch (computed b9a68419 wanted 29d51b00)
--25837--    object doesn't have a symbol table
--25837-- Reading syms from /lib/x86_64-linux-gnu/libc-2.23.so
--25837--   Considering /lib/x86_64-linux-gnu/libc-2.23.so ..
--25837--   .. CRC mismatch (computed 0423f85c wanted cbe1e5cd)
--25837--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.23.so ..
--25837--   .. CRC is valid
--25837-- Reading syms from /lib/x86_64-linux-gnu/libpthread-2.23.so
--25837--   Considering /usr/lib/debug/.build-id/4d/7f52f335dc9665c2dcf308ce6514a6ae86dede.debug ..
--25837--   .. build-id is valid
--25837-- Reading syms from /lib/x86_64-linux-gnu/libm-2.23.so
--25837--   Considering /lib/x86_64-linux-gnu/libm-2.23.so ..
--25837--   .. CRC mismatch (computed eda5a952 wanted 8f48b034)
--25837--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libm-2.23.so ..
--25837--   .. CRC is valid
--25837-- REDIR: 0x6c92e50 (libc.so.6:strcasecmp) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--25837-- REDIR: 0x6c8e6d0 (libc.so.6:strcspn) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--25837-- REDIR: 0x6c95140 (libc.so.6:strncasecmp) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--25837-- REDIR: 0x6c90b40 (libc.so.6:strpbrk) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--25837-- REDIR: 0x6c90ed0 (libc.so.6:strspn) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--25837-- REDIR: 0x6c9259b (libc.so.6:memcpy@GLIBC_2.2.5) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--25837-- REDIR: 0x6c90850 (libc.so.6:rindex) redirected to 0x4c308a0 (rindex)
--25837-- REDIR: 0x6c87580 (libc.so.6:malloc) redirected to 0x4c2db20 (malloc)
--25837-- REDIR: 0x6c8eb70 (libc.so.6:strlen) redirected to 0x4c30f60 (strlen)
--25837-- REDIR: 0x6c92040 (libc.so.6:__GI_memcmp) redirected to 0x4c33b90 (__GI_memcmp)
--25837-- REDIR: 0x6c8d120 (libc.so.6:strcmp) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--25837-- REDIR: 0x6ca29c0 (libc.so.6:__strcmp_sse2_unaligned) redirected to 0x4c31f90 (strcmp)
--25837-- REDIR: 0x66f9e60 (libstdc++.so.6:operator new(unsigned long)) redirected to 0x4c2e080 (operator new(unsigned long))
--25837-- REDIR: 0x66f9f10 (libstdc++.so.6:operator new[](unsigned long)) redirected to 0x4c2e7a0 (operator new[](unsigned long))
--25837-- REDIR: 0x6c92600 (libc.so.6:memset) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--25837-- REDIR: 0x6d75d80 (libc.so.6:__memset_avx2) redirected to 0x4c344c0 (memset)
--25837-- REDIR: 0x6c8e5b0 (libc.so.6:strcpy) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--25837-- REDIR: 0x6ca8e20 (libc.so.6:__strcpy_sse2_unaligned) redirected to 0x4c31040 (strcpy)
--25837-- REDIR: 0x6d50dc0 (libc.so.6:__memmove_avx_unaligned) redirected to 0x4c32230 (memcpy@GLIBC_2.2.5)
--25837-- REDIR: 0x66f7f40 (libstdc++.so.6:operator delete[](void*)) redirected to 0x4c2f6e0 (operator delete[](void*))
--25837-- REDIR: 0x6c97840 (libc.so.6:memcpy@@GLIBC_2.14) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--25837-- REDIR: 0x6d512b0 (libc.so.6:__memcpy_avx_unaligned) redirected to 0x4c324a0 (memcpy@@GLIBC_2.14)
--25837-- REDIR: 0x66f7f10 (libstdc++.so.6:operator delete(void*)) redirected to 0x4c2f1e0 (operator delete(void*))
--25837-- REDIR: 0x6c88160 (libc.so.6:calloc) redirected to 0x4c2faa0 (calloc)
--25837-- REDIR: 0x6c92000 (libc.so.6:bcmp) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--25837-- REDIR: 0x6d71840 (libc.so.6:__memcmp_sse4_1) redirected to 0x4c33cd0 (__memcmp_sse4_1)
--25837-- REDIR: 0x6c99bb0 (libc.so.6:strchrnul) redirected to 0x4c34da0 (strchrnul)
--25837-- REDIR: 0x6c8ed10 (libc.so.6:strnlen) redirected to 0x4c30ee0 (strnlen)
--25837-- REDIR: 0x6c92800 (libc.so.6:__GI_mempcpy) redirected to 0x4c34fa0 (__GI_mempcpy)
--25837-- REDIR: 0x6d19890 (libc.so.6:__strcpy_chk) redirected to 0x4c34e10 (__strcpy_chk)
--25837-- REDIR: 0x6c90810 (libc.so.6:strncpy) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--25837-- REDIR: 0x6ca9450 (libc.so.6:__strncpy_sse2_unaligned) redirected to 0x4c31570 (__strncpy_sse2_unaligned)
--25837-- REDIR: 0x6c8efc0 (libc.so.6:__GI_strncmp) redirected to 0x4c31710 (__GI_strncmp)
--25837-- REDIR: 0x6c914b0 (libc.so.6:__GI_strstr) redirected to 0x4c354d0 (__strstr_sse2)
--25837-- REDIR: 0x6c91cb0 (libc.so.6:memchr) redirected to 0x4c32170 (memchr)
--25837-- REDIR: 0x6c978c0 (libc.so.6:__GI_memcpy) redirected to 0x4c32b00 (__GI_memcpy)
--25837-- REDIR: 0x6d4f400 (libc.so.6:__strncasecmp_avx) redirected to 0x4c31940 (strncasecmp)
--25837-- REDIR: 0x6c87940 (libc.so.6:free) redirected to 0x4c2ed80 (free)
--25837-- REDIR: 0x6c8d160 (libc.so.6:__GI_strcmp) redirected to 0x4c31fe0 (__GI_strcmp)
--25837-- REDIR: 0x6c92ce0 (libc.so.6:__GI_stpcpy) redirected to 0x4c33f80 (__GI_stpcpy)
--25837-- Reading syms from /lib/x86_64-linux-gnu/libnss_files-2.23.so
--25837--   Considering /lib/x86_64-linux-gnu/libnss_files-2.23.so ..
--25837--   .. CRC mismatch (computed c650ec10 wanted d93fc4b1)
--25837--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libnss_files-2.23.so ..
--25837--   .. CRC is valid
--25837-- REDIR: 0x6c8e5f0 (libc.so.6:__GI_strcpy) redirected to 0x4c31110 (__GI_strcpy)
--25837-- REDIR: 0x6ca2970 (libc.so.6:__GI_strncpy) redirected to 0x4c31310 (__GI_strncpy)
--25837-- REDIR: 0x6c8cf00 (libc.so.6:__GI_strchr) redirected to 0x4c30a00 (__GI_strchr)
--25837-- REDIR: 0x6c999a0 (libc.so.6:rawmemchr) redirected to 0x4c34dd0 (rawmemchr)
--25837-- REDIR: 0x6d19620 (libc.so.6:__memcpy_chk) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--25837-- REDIR: 0x6d512a0 (libc.so.6:__memcpy_chk_avx_unaligned) redirected to 0x4c35360 (__memcpy_chk)
--25837-- REDIR: 0x66f7f60 (libstdc++.so.6:operator delete[](void*, std::nothrow_t const&)) redirected to 0x4c2f8c0 (operator delete[](void*, std::nothrow_t const&))
--25837-- REDIR: 0x66f9f40 (libstdc++.so.6:operator new[](unsigned long, std::nothrow_t const&)) redirected to 0x4c2ea70 (operator new[](unsigned long, std::nothrow_t const&))
==25837== 
==25837== Process terminating with default action of signal 2 (SIGINT)
==25837==    at 0x6CFA69D: ??? (syscall-template.S:84)
==25837==    by 0x6C7E5E7: _IO_file_underflow@@GLIBC_2.2.5 (fileops.c:592)
==25837==    by 0x6C7F60D: _IO_default_uflow (genops.c:413)
==25837==    by 0x6C7A107: getc (getc.c:38)
==25837==    by 0x6755B4C: __gnu_cxx::stdio_sync_filebuf<char, std::char_traits<char> >::underflow() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==25837==    by 0x6712B79: std::basic_istream<char, std::char_traits<char> >& std::getline<char, std::char_traits<char>, std::allocator<char> >(std::basic_istream<char, std::char_traits<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, char) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==25837==    by 0x4048E7: main (main.cpp:31)
--25837-- Discarding syms at 0x80f61b0-0x80fc2a1 in /lib/x86_64-linux-gnu/libnss_files-2.23.so due to munmap()
==25837== 
==25837== HEAP SUMMARY:
==25837==     in use at exit: 1,089,791 bytes in 13,196 blocks
==25837==   total heap usage: 697,846 allocs, 684,650 frees, 60,946,691 bytes allocated
==25837== 
==25837== Searching for pointers to 13,196 not-freed blocks
==25837== Checked 4,091,705,872 bytes
==25837== 
==25837== 288 bytes in 1 blocks are possibly lost in loss record 517 of 550
==25837==    at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==25837==    by 0x40136D4: allocate_dtv (dl-tls.c:322)
==25837==    by 0x40136D4: _dl_allocate_tls (dl-tls.c:539)
==25837==    by 0x6FD526E: allocate_stack (allocatestack.c:588)
==25837==    by 0x6FD526E: pthread_create@@GLIBC_2.2.5 (pthread_create.c:539)
==25837==    by 0x521C763: OFThread::start() (in /mnt/LinuxData/git/medxchange.dicom/native/projects/build-medxdcmtk-cons-Desktop_Qt_5_8_0_GCC_64bit-Debug/libdcmtk.so.10)
==25837==    by 0x405D71: medx_dicom_server_start (serverscp.cpp:107)
==25837==    by 0x4048C5: main (main.cpp:28)
==25837== 
==25837== 140,544 bytes in 488 blocks are possibly lost in loss record 549 of 550
==25837==    at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==25837==    by 0x40136D4: allocate_dtv (dl-tls.c:322)
==25837==    by 0x40136D4: _dl_allocate_tls (dl-tls.c:539)
==25837==    by 0x6FD526E: allocate_stack (allocatestack.c:588)
==25837==    by 0x6FD526E: pthread_create@@GLIBC_2.2.5 (pthread_create.c:539)
==25837==    by 0x521C763: OFThread::start() (in /mnt/LinuxData/git/medxchange.dicom/native/projects/build-medxdcmtk-cons-Desktop_Qt_5_8_0_GCC_64bit-Debug/libdcmtk.so.10)
==25837==    by 0x577C265: DcmBaseSCPPool::runAssociation(T_ASC_Association*, DcmSharedSCPConfig const&) (in /mnt/LinuxData/git/medxchange.dicom/native/projects/build-medxdcmtk-cons-Desktop_Qt_5_8_0_GCC_64bit-Debug/libdcmtk.so.10)
==25837==    by 0x577D154: DcmBaseSCPPool::listen() (in /mnt/LinuxData/git/medxchange.dicom/native/projects/build-medxdcmtk-cons-Desktop_Qt_5_8_0_GCC_64bit-Debug/libdcmtk.so.10)
==25837==    by 0x406965: ServerSCPThread::run() (serverscp.cpp:25)
==25837==    by 0x521C6C9: thread_stub (in /mnt/LinuxData/git/medxchange.dicom/native/projects/build-medxdcmtk-cons-Desktop_Qt_5_8_0_GCC_64bit-Debug/libdcmtk.so.10)
==25837==    by 0x6FD46B9: start_thread (pthread_create.c:333)
==25837==    by 0x6D0A82C: clone (clone.S:109)
==25837== 
==25837== LEAK SUMMARY:
==25837==    definitely lost: 0 bytes in 0 blocks
==25837==    indirectly lost: 0 bytes in 0 blocks
==25837==      possibly lost: 140,832 bytes in 489 blocks
==25837==    still reachable: 948,959 bytes in 12,707 blocks
==25837==                       of which reachable via heuristic:
==25837==                         newarray           : 4,432 bytes in 28 blocks
==25837==         suppressed: 0 bytes in 0 blocks
==25837== Reachable blocks (those to which a pointer was found) are not shown.
==25837== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==25837== 
==25837== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
==25837== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

theonlylawislove
Posts: 34
Joined: Thu, 2014-07-17, 09:07

Re: Memory leak with simple DcmSCPPool

#3 Post by theonlylawislove »

If I do this...
pool->setMaxThreads(0);
...I get our of resource error with echo, which is expected, but I get no memory leak.

So, the issue is somewhere in runAssocation (or the threads being started).

Here is the valgrind output now.

Code: Select all

==17562== Memcheck, a memory error detector
==17562== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==17562== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==17562== Command: ./medxdcmtk-cons
==17562== Parent PID: 30409
==17562== 
--17562-- 
--17562-- Valgrind options:
--17562--    -v
--17562--    --tool=memcheck
--17562--    --leak-check=full
--17562--    --num-callers=40
--17562--    --log-file=valgrind.log
--17562-- Contents of /proc/version:
--17562--   Linux version 4.4.0-65-generic (buildd@lgw01-12) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #86-Ubuntu SMP Thu Feb 23 17:49:58 UTC 2017
--17562-- 
--17562-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-avx-avx2-bmi
--17562-- Page sizes: currently 4096, max supported 4096
--17562-- Valgrind library directory: /usr/lib/valgrind
--17562-- Reading syms from /mnt/LinuxData/git/medxchange.dicom/native/projects/build-medxdcmtk-cons-Desktop_Qt_5_8_0_GCC_64bit-Debug/medxdcmtk-cons
--17562-- Reading syms from /lib/x86_64-linux-gnu/ld-2.23.so
--17562--   Considering /lib/x86_64-linux-gnu/ld-2.23.so ..
--17562--   .. CRC mismatch (computed e101f79f wanted 8d6608d4)
--17562--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.23.so ..
--17562--   .. CRC is valid
--17562-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux
--17562--   Considering /usr/lib/valgrind/memcheck-amd64-linux ..
--17562--   .. CRC mismatch (computed 5529a2c7 wanted 5bd23904)
--17562--    object doesn't have a symbol table
--17562--    object doesn't have a dynamic symbol table
--17562-- Scheduler: using generic scheduler lock implementation.
--17562-- Reading suppressions file: /usr/lib/valgrind/default.supp
==17562== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-17562-by-pknopf-on-???
==17562== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-17562-by-pknopf-on-???
==17562== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-17562-by-pknopf-on-???
==17562== 
==17562== TO CONTROL THIS PROCESS USING vgdb (which you probably
==17562== don't want to do, unless you know exactly what you're doing,
==17562== or are doing some strange experiment):
==17562==   /usr/lib/valgrind/../../bin/vgdb --pid=17562 ...command...
==17562== 
==17562== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==17562==   /path/to/gdb ./medxdcmtk-cons
==17562== and then give GDB the following command
==17562==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=17562
==17562== --pid is optional if only one valgrind process is running
==17562== 
--17562-- REDIR: 0x401cdc0 (ld-linux-x86-64.so.2:strlen) redirected to 0x3809e181 (???)
--17562-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so
--17562--   Considering /usr/lib/valgrind/vgpreload_core-amd64-linux.so ..
--17562--   .. CRC mismatch (computed a30c8eaa wanted 7ae2fed4)
--17562--    object doesn't have a symbol table
--17562-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so
--17562--   Considering /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so ..
--17562--   .. CRC mismatch (computed 402c2ab5 wanted 745f25ae)
--17562--    object doesn't have a symbol table
==17562== WARNING: new redirection conflicts with existing -- ignoring it
--17562--     old: 0x0401cdc0 (strlen              ) R-> (0000.0) 0x3809e181 ???
--17562--     new: 0x0401cdc0 (strlen              ) R-> (2007.0) 0x04c31020 strlen
--17562-- REDIR: 0x401b710 (ld-linux-x86-64.so.2:index) redirected to 0x4c30bc0 (index)
--17562-- REDIR: 0x401b930 (ld-linux-x86-64.so.2:strcmp) redirected to 0x4c320d0 (strcmp)
--17562-- REDIR: 0x401db20 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x4c35270 (mempcpy)
--17562-- Reading syms from /mnt/LinuxData/git/medxchange.dicom/native/projects/build-medxdcmtk-cons-Desktop_Qt_5_8_0_GCC_64bit-Debug/libdcmtk.so.10
--17562-- Reading syms from /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
--17562--   Considering /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 ..
--17562--   .. CRC mismatch (computed 834c912e wanted c67ab13d)
--17562--    object doesn't have a symbol table
--17562-- Reading syms from /lib/x86_64-linux-gnu/libgcc_s.so.1
--17562--   Considering /lib/x86_64-linux-gnu/libgcc_s.so.1 ..
--17562--   .. CRC mismatch (computed b9a68419 wanted 29d51b00)
--17562--    object doesn't have a symbol table
--17562-- Reading syms from /lib/x86_64-linux-gnu/libc-2.23.so
--17562--   Considering /lib/x86_64-linux-gnu/libc-2.23.so ..
--17562--   .. CRC mismatch (computed 0423f85c wanted cbe1e5cd)
--17562--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.23.so ..
--17562--   .. CRC is valid
--17562-- Reading syms from /lib/x86_64-linux-gnu/libpthread-2.23.so
--17562--   Considering /usr/lib/debug/.build-id/4d/7f52f335dc9665c2dcf308ce6514a6ae86dede.debug ..
--17562--   .. build-id is valid
--17562-- Reading syms from /lib/x86_64-linux-gnu/libm-2.23.so
--17562--   Considering /lib/x86_64-linux-gnu/libm-2.23.so ..
--17562--   .. CRC mismatch (computed eda5a952 wanted 8f48b034)
--17562--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libm-2.23.so ..
--17562--   .. CRC is valid
--17562-- REDIR: 0x6c92e50 (libc.so.6:strcasecmp) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17562-- REDIR: 0x6c8e6d0 (libc.so.6:strcspn) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17562-- REDIR: 0x6c95140 (libc.so.6:strncasecmp) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17562-- REDIR: 0x6c90b40 (libc.so.6:strpbrk) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17562-- REDIR: 0x6c90ed0 (libc.so.6:strspn) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17562-- REDIR: 0x6c9259b (libc.so.6:memcpy@GLIBC_2.2.5) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17562-- REDIR: 0x6c90850 (libc.so.6:rindex) redirected to 0x4c308a0 (rindex)
--17562-- REDIR: 0x6c87580 (libc.so.6:malloc) redirected to 0x4c2db20 (malloc)
--17562-- REDIR: 0x6c8eb70 (libc.so.6:strlen) redirected to 0x4c30f60 (strlen)
--17562-- REDIR: 0x6c92040 (libc.so.6:__GI_memcmp) redirected to 0x4c33b90 (__GI_memcmp)
--17562-- REDIR: 0x6c8d120 (libc.so.6:strcmp) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17562-- REDIR: 0x6ca29c0 (libc.so.6:__strcmp_sse2_unaligned) redirected to 0x4c31f90 (strcmp)
--17562-- REDIR: 0x66f9e60 (libstdc++.so.6:operator new(unsigned long)) redirected to 0x4c2e080 (operator new(unsigned long))
--17562-- REDIR: 0x66f9f10 (libstdc++.so.6:operator new[](unsigned long)) redirected to 0x4c2e7a0 (operator new[](unsigned long))
--17562-- REDIR: 0x6c92600 (libc.so.6:memset) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17562-- REDIR: 0x6d75d80 (libc.so.6:__memset_avx2) redirected to 0x4c344c0 (memset)
--17562-- REDIR: 0x6c8e5b0 (libc.so.6:strcpy) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17562-- REDIR: 0x6ca8e20 (libc.so.6:__strcpy_sse2_unaligned) redirected to 0x4c31040 (strcpy)
--17562-- REDIR: 0x6d50dc0 (libc.so.6:__memmove_avx_unaligned) redirected to 0x4c32230 (memcpy@GLIBC_2.2.5)
--17562-- REDIR: 0x66f7f40 (libstdc++.so.6:operator delete[](void*)) redirected to 0x4c2f6e0 (operator delete[](void*))
--17562-- REDIR: 0x6c97840 (libc.so.6:memcpy@@GLIBC_2.14) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17562-- REDIR: 0x6d512b0 (libc.so.6:__memcpy_avx_unaligned) redirected to 0x4c324a0 (memcpy@@GLIBC_2.14)
--17562-- REDIR: 0x66f7f10 (libstdc++.so.6:operator delete(void*)) redirected to 0x4c2f1e0 (operator delete(void*))
--17562-- REDIR: 0x6c88160 (libc.so.6:calloc) redirected to 0x4c2faa0 (calloc)
--17562-- REDIR: 0x6c92000 (libc.so.6:bcmp) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17562-- REDIR: 0x6d71840 (libc.so.6:__memcmp_sse4_1) redirected to 0x4c33cd0 (__memcmp_sse4_1)
--17562-- REDIR: 0x6c99bb0 (libc.so.6:strchrnul) redirected to 0x4c34da0 (strchrnul)
--17562-- REDIR: 0x6c8ed10 (libc.so.6:strnlen) redirected to 0x4c30ee0 (strnlen)
--17562-- REDIR: 0x6c92800 (libc.so.6:__GI_mempcpy) redirected to 0x4c34fa0 (__GI_mempcpy)
--17562-- REDIR: 0x6d19890 (libc.so.6:__strcpy_chk) redirected to 0x4c34e10 (__strcpy_chk)
--17562-- REDIR: 0x6c90810 (libc.so.6:strncpy) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17562-- REDIR: 0x6ca9450 (libc.so.6:__strncpy_sse2_unaligned) redirected to 0x4c31570 (__strncpy_sse2_unaligned)
--17562-- REDIR: 0x6c8efc0 (libc.so.6:__GI_strncmp) redirected to 0x4c31710 (__GI_strncmp)
--17562-- REDIR: 0x6c914b0 (libc.so.6:__GI_strstr) redirected to 0x4c354d0 (__strstr_sse2)
--17562-- REDIR: 0x6c91cb0 (libc.so.6:memchr) redirected to 0x4c32170 (memchr)
--17562-- REDIR: 0x6c978c0 (libc.so.6:__GI_memcpy) redirected to 0x4c32b00 (__GI_memcpy)
--17562-- REDIR: 0x6d4f400 (libc.so.6:__strncasecmp_avx) redirected to 0x4c31940 (strncasecmp)
--17562-- REDIR: 0x6c87940 (libc.so.6:free) redirected to 0x4c2ed80 (free)
--17562-- REDIR: 0x6c8d160 (libc.so.6:__GI_strcmp) redirected to 0x4c31fe0 (__GI_strcmp)
--17562-- REDIR: 0x6c92ce0 (libc.so.6:__GI_stpcpy) redirected to 0x4c33f80 (__GI_stpcpy)
--17562-- Reading syms from /lib/x86_64-linux-gnu/libnss_files-2.23.so
--17562--   Considering /lib/x86_64-linux-gnu/libnss_files-2.23.so ..
--17562--   .. CRC mismatch (computed c650ec10 wanted d93fc4b1)
--17562--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libnss_files-2.23.so ..
--17562--   .. CRC is valid
--17562-- REDIR: 0x6c8e5f0 (libc.so.6:__GI_strcpy) redirected to 0x4c31110 (__GI_strcpy)
--17562-- REDIR: 0x6ca2970 (libc.so.6:__GI_strncpy) redirected to 0x4c31310 (__GI_strncpy)
--17562-- REDIR: 0x6c8cf00 (libc.so.6:__GI_strchr) redirected to 0x4c30a00 (__GI_strchr)
--17562-- REDIR: 0x6c999a0 (libc.so.6:rawmemchr) redirected to 0x4c34dd0 (rawmemchr)
--17562-- REDIR: 0x6d4dd90 (libc.so.6:__strcasecmp_avx) redirected to 0x4c31860 (strcasecmp)
--17562-- REDIR: 0x6d19620 (libc.so.6:__memcpy_chk) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17562-- REDIR: 0x6d512a0 (libc.so.6:__memcpy_chk_avx_unaligned) redirected to 0x4c35360 (__memcpy_chk)
--17562-- Discarding syms at 0x80f61b0-0x80fc2a1 in /lib/x86_64-linux-gnu/libnss_files-2.23.so due to munmap()
==17562== 
==17562== HEAP SUMMARY:
==17562==     in use at exit: 72,704 bytes in 1 blocks
==17562==   total heap usage: 636,977 allocs, 636,976 frees, 81,132,817 bytes allocated
==17562== 
==17562== Searching for pointers to 1 not-freed blocks
==17562== Checked 349,136 bytes
==17562== 
==17562== LEAK SUMMARY:
==17562==    definitely lost: 0 bytes in 0 blocks
==17562==    indirectly lost: 0 bytes in 0 blocks
==17562==      possibly lost: 0 bytes in 0 blocks
==17562==    still reachable: 72,704 bytes in 1 blocks
==17562==         suppressed: 0 bytes in 0 blocks
==17562== Reachable blocks (those to which a pointer was found) are not shown.
==17562== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==17562== 
==17562== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==17562== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Side note, when I set max threads to 1, it still seems that threads are being created and destroyed (instead of re-used).

theonlylawislove
Posts: 34
Joined: Thu, 2014-07-17, 09:07

Re: Memory leak with simple DcmSCPPool

#4 Post by theonlylawislove »

With max threads set to 1, I am getting new threads created, over and over. Here is the debug output from the server (with echos being spammed to it).

Code: Select all

DcmBaseSCPPool: Starting new DcmSCP worker thread
Association Received localhost: ECHOSCU -> ANY-SCP
Incoming Association Request:
====================== BEGIN A-ASSOCIATE-RQ =====================
Our Implementation Class UID:      1.2.276.0.7230010.3.0.3.6.1
Our Implementation Version Name:   OFFIS_DCMTK_361
Their Implementation Class UID:    1.2.276.0.7230010.3.0.3.6.1
Their Implementation Version Name: OFFIS_DCMTK_361
Application Context Name:    1.2.840.10008.3.1.1.1
Calling Application Name:    ECHOSCU
Called Application Name:     ANY-SCP
Responding Application Name: 
Our Max PDU Receive Size:    16384
Their Max PDU Receive Size:  16384
Presentation Contexts:
  Context ID:        1 (Proposed)
    Abstract Syntax: =VerificationSOPClass
    Proposed SCP/SCU Role: Default
    Proposed Transfer Syntax(es):
      =LittleEndianImplicit
Requested Extended Negotiation: none
Accepted Extended Negotiation:  none
Requested User Identity Negotiation: none
User Identity Negotiation Response:  none
======================= END A-ASSOCIATE-RQ ======================
Constructing Associate AC PDU
DcmSCP: Association Acknowledged
Association Acknowledged (Max Send PDV: 16372)
====================== BEGIN A-ASSOCIATE-AC =====================
Our Implementation Class UID:      1.2.276.0.7230010.3.0.3.6.1
Our Implementation Version Name:   OFFIS_DCMTK_361
Their Implementation Class UID:    1.2.276.0.7230010.3.0.3.6.1
Their Implementation Version Name: OFFIS_DCMTK_361
Application Context Name:    1.2.840.10008.3.1.1.1
Calling Application Name:    ECHOSCU
Called Application Name:     ANY-SCP
Responding Application Name: ANY-SCP
Our Max PDU Receive Size:    16384
Their Max PDU Receive Size:  16384
Presentation Contexts:
  Context ID:        1 (Accepted)
    Abstract Syntax: =VerificationSOPClass
    Proposed SCP/SCU Role: Default
    Accepted SCP/SCU Role: Default
    Accepted Transfer Syntax: =LittleEndianImplicit
Requested Extended Negotiation: none
Accepted Extended Negotiation:  none
Requested User Identity Negotiation: none
User Identity Negotiation Response:  none
======================= END A-ASSOCIATE-AC ======================
DcmDataset::read() TransferSyntax="Little Endian Implicit"
Received C-ECHO Request
===================== INCOMING DIMSE MESSAGE ====================
Message Type                  : C-ECHO RQ
Presentation Context ID       : 1
Message ID                    : 1
Data Set                      : none
======================= END DIMSE MESSAGE =======================
Sending C-ECHO Response
C-ECHO Response successfully sent
Received Association Release Request
DcmSCP: Association Terminated
+++++++++++++++++++++++++++++
DcmBaseSCPPool: Worker thread #140413259597568 returns with code: Normal
DcmBaseSCPPool: Worker thread #140413259597568 exited with error: Normal
setting network send timeout to 60 seconds
setting network receive timeout to 60 seconds
PDU Type: Associate Request, PDU Length: 205 + 6 bytes PDU header
  01  00  00  00  00  cd  00  01  00  00  41  4e  59  2d  53  43
  50  20  20  20  20  20  20  20  20  20  45  43  48  4f  53  43
  55  20  20  20  20  20  20  20  20  20  00  00  00  00  00  00
  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  00  00  00  00  00  00  00  00  00  00  10  00  00  15  31  2e
  32  2e  38  34  30  2e  31  30  30  30  38  2e  33  2e  31  2e
  31  2e  31  20  00  00  2e  01  00  ff  00  30  00  00  11  31
  2e  32  2e  38  34  30  2e  31  30  30  30  38  2e  31  2e  31
  40  00  00  11  31  2e  32  2e  38  34  30  2e  31  30  30  30
  38  2e  31  2e  32  50  00  00  3a  51  00  00  04  00  00  40
  00  52  00  00  1b  31  2e  32  2e  32  37  36  2e  30  2e  37
  32  33  30  30  31  30  2e  33  2e  30  2e  33  2e  36  2e  31
  55  00  00  0f  4f  46  46  49  53  5f  44  43  4d  54  4b  5f
  33  36  31
Parsing an A-ASSOCIATE PDU
DcmBaseSCPPool: Starting new DcmSCP worker thread
Association Received localhost: ECHOSCU -> ANY-SCP
Incoming Association Request:
====================== BEGIN A-ASSOCIATE-RQ =====================
Our Implementation Class UID:      1.2.276.0.7230010.3.0.3.6.1
Our Implementation Version Name:   OFFIS_DCMTK_361
Their Implementation Class UID:    1.2.276.0.7230010.3.0.3.6.1
Their Implementation Version Name: OFFIS_DCMTK_361
Application Context Name:    1.2.840.10008.3.1.1.1
Calling Application Name:    ECHOSCU
Called Application Name:     ANY-SCP
Responding Application Name: 
Our Max PDU Receive Size:    16384
Their Max PDU Receive Size:  16384
Presentation Contexts:
  Context ID:        1 (Proposed)
    Abstract Syntax: =VerificationSOPClass
    Proposed SCP/SCU Role: Default
    Proposed Transfer Syntax(es):
      =LittleEndianImplicit
Requested Extended Negotiation: none
Accepted Extended Negotiation:  none
Requested User Identity Negotiation: none
User Identity Negotiation Response:  none
======================= END A-ASSOCIATE-RQ ======================
Constructing Associate AC PDU
DcmSCP: Association Acknowledged
Association Acknowledged (Max Send PDV: 16372)
====================== BEGIN A-ASSOCIATE-AC =====================
Our Implementation Class UID:      1.2.276.0.7230010.3.0.3.6.1
Our Implementation Version Name:   OFFIS_DCMTK_361
Their Implementation Class UID:    1.2.276.0.7230010.3.0.3.6.1
Their Implementation Version Name: OFFIS_DCMTK_361
Application Context Name:    1.2.840.10008.3.1.1.1
Calling Application Name:    ECHOSCU
Called Application Name:     ANY-SCP
Responding Application Name: ANY-SCP
Our Max PDU Receive Size:    16384
Their Max PDU Receive Size:  16384
Presentation Contexts:
  Context ID:        1 (Accepted)
    Abstract Syntax: =VerificationSOPClass
    Proposed SCP/SCU Role: Default
    Accepted SCP/SCU Role: Default
    Accepted Transfer Syntax: =LittleEndianImplicit
Requested Extended Negotiation: none
Accepted Extended Negotiation:  none
Requested User Identity Negotiation: none
User Identity Negotiation Response:  none
======================= END A-ASSOCIATE-AC ======================
DcmDataset::read() TransferSyntax="Little Endian Implicit"
Received C-ECHO Request
===================== INCOMING DIMSE MESSAGE ====================
Message Type                  : C-ECHO RQ
Presentation Context ID       : 1
Message ID                    : 1
Data Set                      : none
======================= END DIMSE MESSAGE =======================
Sending C-ECHO Response
C-ECHO Response successfully sent
Received Association Release Request
DcmSCP: Association Terminated
+++++++++++++++++++++++++++++
DcmBaseSCPPool: Worker thread #140413251204864 returns with code: Normal
DcmBaseSCPPool: Worker thread #140413251204864 exited with error: Normal
setting network send timeout to 60 seconds
setting network receive timeout to 60 seconds
PDU Type: Associate Request, PDU Length: 205 + 6 bytes PDU header
  01  00  00  00  00  cd  00  01  00  00  41  4e  59  2d  53  43
  50  20  20  20  20  20  20  20  20  20  45  43  48  4f  53  43
  55  20  20  20  20  20  20  20  20  20  00  00  00  00  00  00
  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  00  00  00  00  00  00  00  00  00  00  10  00  00  15  31  2e
  32  2e  38  34  30  2e  31  30  30  30  38  2e  33  2e  31  2e
  31  2e  31  20  00  00  2e  01  00  ff  00  30  00  00  11  31
  2e  32  2e  38  34  30  2e  31  30  30  30  38  2e  31  2e  31
  40  00  00  11  31  2e  32  2e  38  34  30  2e  31  30  30  30
  38  2e  31  2e  32  50  00  00  3a  51  00  00  04  00  00  40
  00  52  00  00  1b  31  2e  32  2e  32  37  36  2e  30  2e  37
  32  33  30  30  31  30  2e  33  2e  30  2e  33  2e  36  2e  31
  55  00  00  0f  4f  46  46  49  53  5f  44  43  4d  54  4b  5f
  33  36  31
Parsing an A-ASSOCIATE PDU
DcmBaseSCPPool: Starting new DcmSCP worker thread
Association Received localhost: ECHOSCU -> ANY-SCP
Incoming Association Request:
====================== BEGIN A-ASSOCIATE-RQ =====================
Our Implementation Class UID:      1.2.276.0.7230010.3.0.3.6.1
Our Implementation Version Name:   OFFIS_DCMTK_361
Their Implementation Class UID:    1.2.276.0.7230010.3.0.3.6.1
Their Implementation Version Name: OFFIS_DCMTK_361
Application Context Name:    1.2.840.10008.3.1.1.1
Calling Application Name:    ECHOSCU
Called Application Name:     ANY-SCP
Responding Application Name: 
Our Max PDU Receive Size:    16384
Their Max PDU Receive Size:  16384
Presentation Contexts:
  Context ID:        1 (Proposed)
    Abstract Syntax: =VerificationSOPClass
    Proposed SCP/SCU Role: Default
    Proposed Transfer Syntax(es):
      =LittleEndianImplicit
Requested Extended Negotiation: none
Accepted Extended Negotiation:  none
Requested User Identity Negotiation: none
User Identity Negotiation Response:  none
======================= END A-ASSOCIATE-RQ ======================
Constructing Associate AC PDU
DcmSCP: Association Acknowledged
Association Acknowledged (Max Send PDV: 16372)
====================== BEGIN A-ASSOCIATE-AC =====================
Our Implementation Class UID:      1.2.276.0.7230010.3.0.3.6.1
Our Implementation Version Name:   OFFIS_DCMTK_361
Their Implementation Class UID:    1.2.276.0.7230010.3.0.3.6.1
Their Implementation Version Name: OFFIS_DCMTK_361
Application Context Name:    1.2.840.10008.3.1.1.1
Calling Application Name:    ECHOSCU
Called Application Name:     ANY-SCP
Responding Application Name: ANY-SCP
Our Max PDU Receive Size:    16384
Their Max PDU Receive Size:  16384
Presentation Contexts:
  Context ID:        1 (Accepted)
    Abstract Syntax: =VerificationSOPClass
    Proposed SCP/SCU Role: Default
    Accepted SCP/SCU Role: Default
    Accepted Transfer Syntax: =LittleEndianImplicit
Requested Extended Negotiation: none
Accepted Extended Negotiation:  none
Requested User Identity Negotiation: none
User Identity Negotiation Response:  none
======================= END A-ASSOCIATE-AC ======================
DcmDataset::read() TransferSyntax="Little Endian Implicit"
Received C-ECHO Request
===================== INCOMING DIMSE MESSAGE ====================
Message Type                  : C-ECHO RQ
Presentation Context ID       : 1
Message ID                    : 1
Data Set                      : none
======================= END DIMSE MESSAGE =======================
Sending C-ECHO Response
C-ECHO Response successfully sent
Received Association Release Request
DcmSCP: Association Terminated
+++++++++++++++++++++++++++++
DcmBaseSCPPool: Worker thread #140413242812160 returns with code: Normal
DcmBaseSCPPool: Worker thread #140413242812160 exited with error: Normal
setting network send timeout to 60 seconds
setting network receive timeout to 60 seconds
PDU Type: Associate Request, PDU Length: 205 + 6 bytes PDU header
  01  00  00  00  00  cd  00  01  00  00  41  4e  59  2d  53  43
  50  20  20  20  20  20  20  20  20  20  45  43  48  4f  53  43
  55  20  20  20  20  20  20  20  20  20  00  00  00  00  00  00
  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  00  00  00  00  00  00  00  00  00  00  10  00  00  15  31  2e
  32  2e  38  34  30  2e  31  30  30  30  38  2e  33  2e  31  2e
  31  2e  31  20  00  00  2e  01  00  ff  00  30  00  00  11  31
  2e  32  2e  38  34  30  2e  31  30  30  30  38  2e  31  2e  31
  40  00  00  11  31  2e  32  2e  38  34  30  2e  31  30  30  30
  38  2e  31  2e  32  50  00  00  3a  51  00  00  04  00  00  40
  00  52  00  00  1b  31  2e  32  2e  32  37  36  2e  30  2e  37
  32  33  30  30  31  30  2e  33  2e  30  2e  33  2e  36  2e  31
  55  00  00  0f  4f  46  46  49  53  5f  44  43  4d  54  4b  5f
  33  36  31
Parsing an A-ASSOCIATE PDU
DcmBaseSCPPool: Starting new DcmSCP worker thread
Association Received localhost: ECHOSCU -> ANY-SCP
Incoming Association Request:
====================== BEGIN A-ASSOCIATE-RQ =====================
Our Implementation Class UID:      1.2.276.0.7230010.3.0.3.6.1
Our Implementation Version Name:   OFFIS_DCMTK_361
Their Implementation Class UID:    1.2.276.0.7230010.3.0.3.6.1
Their Implementation Version Name: OFFIS_DCMTK_361
Application Context Name:    1.2.840.10008.3.1.1.1
Calling Application Name:    ECHOSCU
Called Application Name:     ANY-SCP
Responding Application Name: 
Our Max PDU Receive Size:    16384
Their Max PDU Receive Size:  16384
Presentation Contexts:
  Context ID:        1 (Proposed)
    Abstract Syntax: =VerificationSOPClass
    Proposed SCP/SCU Role: Default
    Proposed Transfer Syntax(es):
      =LittleEndianImplicit
Requested Extended Negotiation: none
Accepted Extended Negotiation:  none
Requested User Identity Negotiation: none
User Identity Negotiation Response:  none
======================= END A-ASSOCIATE-RQ ======================
Constructing Associate AC PDU
DcmSCP: Association Acknowledged
Association Acknowledged (Max Send PDV: 16372)
====================== BEGIN A-ASSOCIATE-AC =====================
Our Implementation Class UID:      1.2.276.0.7230010.3.0.3.6.1
Our Implementation Version Name:   OFFIS_DCMTK_361
Their Implementation Class UID:    1.2.276.0.7230010.3.0.3.6.1
Their Implementation Version Name: OFFIS_DCMTK_361
Application Context Name:    1.2.840.10008.3.1.1.1
Calling Application Name:    ECHOSCU
Called Application Name:     ANY-SCP
Responding Application Name: ANY-SCP
Our Max PDU Receive Size:    16384
Their Max PDU Receive Size:  16384
Presentation Contexts:
  Context ID:        1 (Accepted)
    Abstract Syntax: =VerificationSOPClass
    Proposed SCP/SCU Role: Default
    Accepted SCP/SCU Role: Default
    Accepted Transfer Syntax: =LittleEndianImplicit
Requested Extended Negotiation: none
Accepted Extended Negotiation:  none
Requested User Identity Negotiation: none
User Identity Negotiation Response:  none
======================= END A-ASSOCIATE-AC ======================
DcmDataset::read() TransferSyntax="Little Endian Implicit"
Received C-ECHO Request
===================== INCOMING DIMSE MESSAGE ====================
Message Type                  : C-ECHO RQ
Presentation Context ID       : 1
Message ID                    : 1
Data Set                      : none
======================= END DIMSE MESSAGE =======================
Sending C-ECHO Response
C-ECHO Response successfully sent
Received Association Release Request
DcmSCP: Association Terminated
+++++++++++++++++++++++++++++
DcmBaseSCPPool: Worker thread #140413234419456 returns with code: Normal
DcmBaseSCPPool: Worker thread #140413234419456 exited with error: Normal
There is a "Starting new DcmSCP worker thread" for each echo request.

This is a bug, it seems. These threads are probably also not being cleaned up.

theonlylawislove
Posts: 34
Joined: Thu, 2014-07-17, 09:07

Re: Memory leak with simple DcmSCPPool

#5 Post by theonlylawislove »

When the association stops, it doesn't seem to add the current worker thread to the list of idle threads.

https://github.com/commontk/DCMTK/blob/ ... ol.cc#L274

Michael Onken
DCMTK Developer
Posts: 2072
Joined: Fri, 2004-11-05, 13:47
Location: Oldenburg, Germany
Contact:

Re: Memory leak with simple DcmSCPPool

#6 Post by Michael Onken »

Hi,

Thanks for the report and looking into possible reasons!

From what I remember there actually should be a thread per incoming DICOM connection (association), so the number of simultanous connections is limited by the maximum number of threads you played around with. Threads are not being re-used but instead one is created when an association request is arriving. That is per design. Of course the threads should also be joined and "destroyed" after an association has been released (and what does not seem to happen in your tests).

Since you are referring to a copy of DCMTK on github: Please use the original sources not the one from the commontk project (see the "disclaimer" at their DCMTK repository page). You can find upstream DCMTK always here: http://git.dcmtk.org.

If the leak is still there, we will investigate it further.

Best regards,
Michael

theonlylawislove
Posts: 34
Joined: Thu, 2014-07-17, 09:07

Re: Memory leak with simple DcmSCPPool

#7 Post by theonlylawislove »

Code: Select all

Since you are referring to a copy of DCMTK on github: Please use the original sources not the one from the commontk project
I should have clarified.

I am using dcmtk at this location:

Code: Select all

git clone git://git.dcmtk.org/dcmtk.git
cd dcmtk
git checkout DCMTK-3.6.1_20170228
I only referenced to github, because it allowed me to link to an individual line.

The memory leak/issue is present in your main repository.

Michael Onken
DCMTK Developer
Posts: 2072
Joined: Fri, 2004-11-05, 13:47
Location: Oldenburg, Germany
Contact:

Re: Memory leak with simple DcmSCPPool

#8 Post by Michael Onken »

Ok, thanks, we'll have a look

Best,
Michael

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

Re: Memory leak with simple DcmSCPPool

#9 Post by J. Riesmeier »

theonlylawislove wrote:I only referenced to github, because it allowed me to link to an individual line.
This is also possible with DCMTK's official git repository (in case you did not know already): http://git.dcmtk.org/?p=dcmtk.git;a=blo ... =HEAD#l274

Post Reply

Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 1 guest