The problem that the handshake_thread remains even after the caller thread is destroyed when handshake is cancelled
Using library version
- gstreamer 1.18.2
- libsoup 2.4
- openssl 1.1.1
- glib-networking 2.62.4
In the normal case, the "source:src"(parent) thread starts the handshake_thread and remains until handshake_thread completely processes the error string.
Thread 2.6 "source:src" hit Breakpoint 2, g_tls_connection_base_handshake (conn=0xf18121b8, cancellable=0x169a770, error=0xf21bc864)
at ../glib-networking-2.62.4/tls/base/gtlsconnection-base.c:1534
1534 ../glib-networking-2.62.4/tls/base/gtlsconnection-base.c: No such file or directory.
(gdb) bt
#0 g_tls_connection_base_handshake (conn=0xf18121b8, cancellable=0x169a770, error=0xf21bc864) at ../glib-networking-2.62.4/tls/base/gtlsconnection-base.c:1534
#1 0xf5d8ab0c in ?? () from /usr/lib/libsoup-2.4.so.1
#2 0xf5d6d646 in ?? () from /usr/lib/libsoup-2.4.so.1
#3 0xf5d87528 in ?? () from /usr/lib/libsoup-2.4.so.1
#4 0xf5d87f0e in soup_session_send () from /usr/lib/libsoup-2.4.so.1
#5 0xf21e6eb2 in gst_soup_http_src_send_message (src=0x16a81e0) at ../git/ext/soup/gstsouphttpsrc.c:1923
#6 gst_soup_http_src_do_request (src=src@entry=0x16a81e0, method=<optimized out>) at ../git/ext/soup/gstsouphttpsrc.c:1999
#7 0xf21e8532 in gst_soup_http_src_create (psrc=0x16a81e0, outbuf=0xf21bcb4c) at ../git/ext/soup/gstsouphttpsrc.c:2191
Thread 2.8 "pool-pipe-m" hit Breakpoint 4, handshake_thread (task=0x15c22e0, object=0xf18121b8, task_data=0xf1814ba0, cancellable=0x169a770)
at ../glib-networking-2.62.4/tls/base/gtlsconnection-base.c:1350
1350 in ../glib-networking-2.62.4/tls/base/gtlsconnection-base.c
(gdb) bt
#0 handshake_thread (task=0x15c22e0, object=0xf18121b8, task_data=0xf1814ba0, cancellable=0x169a770) at ../glib-networking-2.62.4/tls/base/gtlsconnection-base.c:1350
#1 0xf5e936a0 in ?? () from /usr/lib/libgio-2.0.so.0
#2 0xf78fbe48 in ?? () from /usr/lib/libglib-2.0.so.0
#3 0xf78fb8ee in ?? () from /usr/lib/libglib-2.0.so.0
#4 0xf7748898 in start_thread (arg=0x7ca98217) at pthread_create.c:477
However, there may be cases where the parent thread(source:src) that called handshake_thread is already destroyed, and in this case, a crash may occur while processing error_string inside handshake_thread as shown below.
Crash occurs in thread 14905 while trying to play streaming contents using Gstreamer's httpsoursrc. At this time, if I look at the thread info, source:src has already been pthread_joined by Gstreamer main(media-pipeline) and disappeared. Below is some information of crash dump.
Signal: 11
SignalCode: 1, SEGV_MAPERR
SignalSender: 28
FaultAddress: 0x0000001c
Register dump:
r0: 0x00000000 r1: 0xf6c69f6d r2: 0xf22fd140 r3: 0xf22fd600
r4: 0xf6d43f10 r5: 0xf22fc858 r6: 0xf22fc988 r7: 0xf22fc988
r8: 0xffffffff r9: 0x00000000 r10: 0xf3652ee0 fp: 0xf365352c
ip: 0xf6d4288c sp: 0xf22fc840 lr: 0xf6cb068b pc: 0xf79cb41c
cpsr: 0x00000030
Disassemble:
...
0xf79cb414: mrc p15, #0, r3, c13, c0, #3
0xf79cb418: sub.w r2, r3, #0x4c0
***** 0xf79cb41c: ldr r3, [r0, #0x1c]
PC: /lib/libpthread-2.31.so [0xf79cb41c]
LR: /usr/lib/libcrypto.so.1.1 [0xf6cb068b]
Backtrace: tid = 14905
/lib/libpthread-2.31.so (__pthread_rwlock_rdlock+0x7) [0xf79cb41c] // crash occurred here. is err_string_lock invalid?
/usr/lib/libcrypto.so.1.1 (CRYPTO_THREAD_read_lock+0x6) [0xf6cb068b]
/usr/lib/libcrypto.so.1.1 (ENGINE_set_RSA+0xf6) [0xf6c6a00b]
/usr/lib/libcrypto.so.1.1 (ERR_lib_error_string+0x28) [0xf6c6a32d]
/usr/lib/libcrypto.so.1.1 (ERR_error_string_n+0x18) [0xf6c6a3e1]
/usr/lib/gio/modules/libgioopenssl.so (g_io_openssl_query+0x1a26) [0xf364c55b]
g_tls_connection_openssl_handshake_thread_handshake, gtlsconnection-openssl.c:318
/usr/lib/gio/modules/libgioopenssl.so (g_io_openssl_query+0x62ac) [0xf3650de1]
handshake_thread, gtlsconnection-base.c:1414
/usr/lib/libgio-2.0.so.0.6200.6 (g_task_attach_source+0x1b0) [0xf61166a1]
/usr/lib/libglib-2.0.so.0.6200.6 (g_get_num_processors+0x188) [0xf7b7ae49]
/usr/lib/libglib-2.0.so.0.6200.6 (g_test_get_filename+0xd6) [0xf7b7a8ef]
/lib/libpthread-2.31.so (start_thread+0x90) [0xf79c7899]
/lib/libc-2.31.so (clone+0x3c) [0xf6ec4aad]
Backtrace: tid = 8112
/lib/libpthread-2.31.so (__libc_do_syscall+0x5) [0xf79d1b26]
/lib/libpthread-2.31.so (__pthread_clockjoin_ex+0x176) [0xf79c8983]
/lib/libpthread-2.31.so (pthread_join+0x10) [0xf79c8799]
/usr/lib/libsystrim.so.3.0.0 (end_watch+0xd6) [0xf7d1623f]
/lib/ld-2.31.so (_dl_fini+0x160) [0xf7d35011]
/lib/libc-2.31.so (__run_exit_handlers+0x108) [0xf6e54c19]
/lib/libc-2.31.so (exit+0xe) [0xf6e54cdb]
/lib/libc-2.31.so (__libc_start_main+0x9c) [0xf6e44be9]
/usr/sbin/media-pipeline (_start+0x34) [0xa88351]
Backtrace: tid = 14903
/lib/libc-2.31.so (syscall+0xf) [0xf6ec2730]
/usr/lib/libglib-2.0.so.0.6200.6 (g_cond_wait_until+0x8e) [0xf7b922a7]
/usr/lib/libglib-2.0.so.0.6200.6 (g_byte_array_sort_with_data+0x9e) [0xf7b3e74b]
/usr/lib/libglib-2.0.so.0.6200.6 (g_get_num_processors+0x300) [0xf7b7afc1]
/usr/lib/libglib-2.0.so.0.6200.6 (g_test_get_filename+0xd6) [0xf7b7a8ef]
/lib/libpthread-2.31.so (start_thread+0x90) [0xf79c7899]
/lib/libc-2.31.so (clone+0x3c) [0xf6ec4aad]
Backtrace: tid = 14904
/lib/libc-2.31.so (__libc_do_syscall+0x3) [0xf6e44e24]
/lib/libc-2.31.so (__poll+0x3c) [0xf6ebe535]
/usr/lib/libglib-2.0.so.0.6200.6 (g_main_context_dispatch+0x2aa) [0xf7b5f39b]
/usr/lib/libglib-2.0.so.0.6200.6 (g_main_context_iteration+0x1c) [0xf7b5f449]
/usr/lib/libglib-2.0.so.0.6200.6 (g_main_context_iteration+0x48) [0xf7b5f475]
/usr/lib/libglib-2.0.so.0.6200.6 (g_test_get_filename+0xd6) [0xf7b7a8ef]
/lib/libpthread-2.31.so (start_thread+0x90) [0xf79c7899]
/lib/libc-2.31.so (clone+0x3c) [0xf6ec4aad]
Is there any way to clean up the handshake_thread first before the parent thread is gone?