#1029 util.signal: Hang due to use of malloc in signal handler

Reporter Zash
Owner Zash
Stars ★ (1)  
  • Milestone-0.10
  • Status-Fixed
  • Type-Defect
  • Priority-Medium
  1. 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)

  2. 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.

    • tags Milestone-0.10 Status-Fixed
    • owner Zash

New comment