#1029 util.signal: Hang due to use of malloc in signal handler
Reporter
Zash
Owner
Zash
Created
Updated
Stars
★ (1)
Tags
Status-Fixed
Type-Defect
Priority-Medium
Milestone-0.10
Zash
on
What steps will reproduce the problem?
1. SIGHUP
2. ???
3. Be unlucky
What is the expected output?
Prosody reloads config and continues
What do you see instead?
Prosody hangs in __kernel_vsyscall() waiting for a lock
The signal handler in util.signal calls malloc(). This is not safe and may cause malloc() to hang later, or possibly crash.
(thanks to mniip in #lua for help figuring this out)
(gdb) bt
#0 0xb770b428 in __kernel_vsyscall ()
#1 0xb75c08b1 in __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:97
#2 0xb753dcba in _L_lock_11125 () from /lib/i386-linux-gnu/libc.so.6
#3 0xb753b9cd in __GI___libc_malloc (bytes=8) at malloc.c:2889
#4 0xb71fbe56 in ?? () from /usr/lib/prosody/util/signal.so
#5 <signal handler called>
#6 0xb753999b in _int_malloc (av=av@entry=0xb7672420 <main_arena>, bytes=bytes@entry=16) at malloc.c:3391
#7 0xb753b9d8 in __GI___libc_malloc (bytes=16) at malloc.c:2893
#8 0xb723794c in default_malloc_ex (num=16, file=0xb733f224 "bn_lib.c", line=317) at mem.c:79
#9 0xb7237f22 in CRYPTO_malloc (num=num@entry=16, file=file@entry=0xb733f224 "bn_lib.c", line=line@entry=317) at mem.c:308
(in LuaSec while rebuilding the SSL context after SIGHUP)
Zash
on
Fixed in https://hg.prosody.im/0.10/rev/7ea3311ca632
If this becomes a problem again, we could consider the approach of having a pipe that the signal handler writes into, and the socket framework keeps an eye on.
What steps will reproduce the problem? 1. SIGHUP 2. ??? 3. Be unlucky What is the expected output? Prosody reloads config and continues What do you see instead? Prosody hangs in __kernel_vsyscall() waiting for a lock The signal handler in util.signal calls malloc(). This is not safe and may cause malloc() to hang later, or possibly crash. (thanks to mniip in #lua for help figuring this out) (gdb) bt #0 0xb770b428 in __kernel_vsyscall () #1 0xb75c08b1 in __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:97 #2 0xb753dcba in _L_lock_11125 () from /lib/i386-linux-gnu/libc.so.6 #3 0xb753b9cd in __GI___libc_malloc (bytes=8) at malloc.c:2889 #4 0xb71fbe56 in ?? () from /usr/lib/prosody/util/signal.so #5 <signal handler called> #6 0xb753999b in _int_malloc (av=av@entry=0xb7672420 <main_arena>, bytes=bytes@entry=16) at malloc.c:3391 #7 0xb753b9d8 in __GI___libc_malloc (bytes=16) at malloc.c:2893 #8 0xb723794c in default_malloc_ex (num=16, file=0xb733f224 "bn_lib.c", line=317) at mem.c:79 #9 0xb7237f22 in CRYPTO_malloc (num=num@entry=16, file=file@entry=0xb733f224 "bn_lib.c", line=line@entry=317) at mem.c:308 (in LuaSec while rebuilding the SSL context after SIGHUP)
Fixed in https://hg.prosody.im/0.10/rev/7ea3311ca632 If this becomes a problem again, we could consider the approach of having a pipe that the signal handler writes into, and the socket framework keeps an eye on.
Changes