digitalmars.D.learn - SIGUSR1 in clock_nanosleep()? how to isolate this issue?
- mw (54/54) Aug 20 2020 Hi,
- Steven Schveighoffer (4/7) Aug 20 2020 The GC uses SIGUSR1 (and SIGUSR2). Maybe that's the issue?
- Sebastiaan Koppe (3/9) Aug 20 2020 Try "handle SIGUSR1 nostop noprint" and "handle SIGUSR2 nostop
Hi, I run into an issue: it's SIGUSR1 in clock_nanosleep() --------------------------- ... [New Thread 0x7ffff0ae0700 (LWP 36860)] [New Thread 0x7fffcbfff700 (LWP 36861)] [Detaching after fork from child process 36862] [New Thread 0x7fffd2eff700 (LWP 36863)] [New Thread 0x7fffd26fe700 (LWP 36864)] [New Thread 0x7fffd1efd700 (LWP 36865)] [New Thread 0x7fffd16fc700 (LWP 36866)] Thread 10 "lt" received signal SIGUSR1, User defined signal 1. [Switching to Thread 0x7ffff0ae0700 (LWP 36860)] 0x00007ffff5d99361 in clock_nanosleep () from /usr/lib/x86_64-linux-gnu/libc.so.6 (gdb) where /usr/lib/x86_64-linux-gnu/libc.so.6 /usr/lib/x86_64-linux-gnu/libc.so.6 _D4core6thread8osthread6Thread5sleepFNbNiSQBo4time8DurationZv () at ttt.d:1368 _D3std11concurrency__T6_spawnTPFZvZQnFbQjZ4execMFZv () at .../ldc2-1.23.0-linux-x86_64/bin/../import/std/concurrency.d:556 pthread_create.c:477 /usr/lib/x86_64-linux-gnu/libc.so.6 --------------------------- I tried some simple example which is similar to my app structure, e.g. ---------------------- void threadFunc() { foreach (i; 0..10) { auto stats = core.memory.GC.stats(); writeln(stats); Thread.sleep( dur!("msecs")( 50 ) ); } } void main() { spawn(&threadFunc); spawn(&threadFunc); thread_joinAll(); } ---------------------- however, it runs fine. Anyone has some suggestions on how to isolate this issue? Thanks.
Aug 20 2020
On 8/20/20 2:58 PM, mw wrote:Hi, I run into an issue: it's SIGUSR1 in clock_nanosleep()The GC uses SIGUSR1 (and SIGUSR2). Maybe that's the issue? https://github.com/dlang/druntime/blob/e1fb19829ebef0419782de43ce4b0e2a1ba140be/src/core/thread/osthread.d#L1946 -Steve
Aug 20 2020
On Thursday, 20 August 2020 at 18:58:43 UTC, mw wrote:Hi, I run into an issue: it's SIGUSR1 in clock_nanosleep() [...] Anyone has some suggestions on how to isolate this issue? Thanks.Try "handle SIGUSR1 nostop noprint" and "handle SIGUSR2 nostop noprint" in gdb.
Aug 20 2020