• Panke (21/21) Dec 11 2020 I have as vibe.d application that opens some websockets, reads
• Adam D. Ruppe (7/9) Dec 11 2020 The garbage collector uses sig usr1/2 to pause threads so it can
• Panke (2/11) Dec 11 2020 Thanks, good to know!
• Panke (6/15) Dec 11 2020 For lldb

Panke <tobias pankrath.net> writes:

I have as vibe.d application that opens some websockets, reads 
messages and does something with them (currently mostly writing 
them to disk).

The processing happens in background threads started with 
runWorkerTask, the websocket code runs as a normal task 
(runTask), everything is synchronized over a central circular 
buffer.

But somehow my process gets signalled with USR1 and USR2 all the 
time. If I do

   $ strace -etrace=epoll_wait

the disruptions of epoll by SIGUSR1/2 just scroll down. According 
to the strace output I got new, the source of the signals is the 
process itself. This happens if I do not install a signal handler 
myself.

While this makes debugging a pain, at least the program seems to 
work. If I install signal handlers for USR1/USR2 via eventcore 
than vibe.d never seems to be able to establish the websocket 
connection. The same happens if I do signal(SIGUSR1, SIG_IGN).

Maybe some kind of deadlock (all threads seem to be waiting on 
some condition variables or a in a spinlock). Does anyone have a 
idea what's going on here?

Adam D. Ruppe <destructionator gmail.com> writes:

On Friday, 11 December 2020 at 17:29:12 UTC, Panke wrote:
 But somehow my process gets signalled with USR1 and USR2 all 
 the time. If I do

The garbage collector uses sig usr1/2 to pause threads so it can 
do its collection work.

When debugging just ignore them. My .gdbinit has these lines:

handle SIGUSR1 noprint
handle SIGUSR2 noprint

since most D programs will have these.

Panke <tobias pankrath.net> writes:

On Friday, 11 December 2020 at 17:32:54 UTC, Adam D. Ruppe wrote:
 On Friday, 11 December 2020 at 17:29:12 UTC, Panke wrote:
 But somehow my process gets signalled with USR1 and USR2 all 
 the time. If I do

 The garbage collector uses sig usr1/2 to pause threads so it 
 can do its collection work.

 When debugging just ignore them. My .gdbinit has these lines:

 handle SIGUSR1 noprint
 handle SIGUSR2 noprint

 since most D programs will have these.

Thanks, good to know!

Panke <tobias pankrath.net> writes:

On Friday, 11 December 2020 at 17:32:54 UTC, Adam D. Ruppe wrote:
 On Friday, 11 December 2020 at 17:29:12 UTC, Panke wrote:
 But somehow my process gets signalled with USR1 and USR2 all 
 the time. If I do

 The garbage collector uses sig usr1/2 to pause threads so it 
 can do its collection work.

 When debugging just ignore them. My .gdbinit has these lines:

 handle SIGUSR1 noprint
 handle SIGUSR2 noprint

 since most D programs will have these.

For lldb

breakpoint set -n _Dmain --auto-continue true -N OnMain
breakpoint command add -o "pro hand -p true -s false -n false 
SIGUSR1 SIGUSR2" OnMain

does the trick.