search

parcio / julea

A Flexible Storage Framework for HPC
GNU Lesser General Public License v3.0
33 stars 31 forks source link

fixing shutdown hang #75

Closed Qualenritter closed 4 years ago

Qualenritter commented 4 years ago

fix #74

michaelkuhn commented 4 years ago

Now we get a double free:

==58667==ERROR: AddressSanitizer: heap-use-after-free on address 0x603000004ca0 at pc 0x7f18ebc2f8a7 bp 0x7ffc83da0b00 sp 0x7ffc83da0af0
READ of size 8 at 0x603000004ca0 thread T0
    #0 0x7f18ebc2f8a6 in _thread_variables_fini ../backend/db/sql-generic.c:116
    #1 0x7f18ebc3da9a in sql_generic_fini ../backend/db/sql-generic.c:147
    #2 0x7f18ebc3db75 in backend_fini ../backend/db/sqlite.c:413
    #3 0x7f18ef27531b in j_backend_db_fini ../lib/core/jbackend.c:680
    #4 0x4072cc in main ../server/server.c:303
    #5 0x7f18eebf41a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
    #6 0x4038bd in _start (.../build/server/julea-server+0x4038bd)

0x603000004ca0 is located 16 bytes inside of 24-byte region [0x603000004c90,0x603000004ca8)
freed by thread T0 here:
    #0 0x7f18ef3ab85f in __interceptor_free (/lib64/libasan.so.5+0x10d85f)
    #1 0x7f18ebc2f7fa in _thread_variables_fini ../backend/db/sql-generic.c:121

previously allocated by thread T2 (pool) here:
    #0 0x7f18ef3abe56 in __interceptor_calloc (/lib64/libasan.so.5+0x10de56)
    #1 0x7f18ef04d750 in g_malloc0 .../glib/gmem.c:129
    #2 0x7f18ebc3e0ff  (.../build/backend/db/libsqlite.so+0x150ff)

Thread T2 (pool) created by T0 here:
    #0 0x7f18ef2d8955 in pthread_create (/lib64/libasan.so.5+0x3a955)
    #1 0x7f18ef08be71 in g_system_thread_new .../glib/gthread-posix.c:1177
Qualenritter commented 4 years ago

This should now be fixed in the commit.

The problem is, that glib calls the thread-local variable finalization function for some, but not all threads. As a result, there are some not null, but invalid pointers - for each thread finalized by glib. To avoid any memory leak, the backend tracks the existing pointers in an additional array. This allows to free every pointer, but has the danger of double free.

The only clean solution to this problem would be a memory-leak free glib implementation ...

michaelkuhn commented 4 years ago

74 has been fixed by another commit (2edb60a896df8e56bf56f539d49c2f05a99f0837), so this PR is not needed anymore.