Why does the program hang in WSL?

Question

I have the following code in my program.

Thread* t = arg->thread;
//at this point, the new thread is being executed.
t->myId = TGetId();
void* (*functor)(void*) = t->functor;
void* fArg = arg->arg;
nfree(arg);
_INFO_PRINTF(1, "Launching thread with ID: %d", t->myId);
sigset_t mask;
sigfillset(&mask);         //fill mask with all signals
sigdelset(&mask, SIGUSR1); // allow SIGUSR1 to get to the thread.
sigdelset(&mask, SIGUSR2); // allow SIGUSR2 to get to the thread.
pthread_sigmask(SIG_SETMASK, &mask, NULL); //block some sigs

struct sigaction act;
memset(&act, 0, sizeof(act));
act.sa_handler = TSignalHandler;
act.sa_mask = mask;
if(sigaction(SIGUSR1, &act, NULL))
{
    _ERROR_PRINT(1, "Could not set signal action.");
    return NULL;
}
if(sigaction(SIGUSR2, &act, NULL))
{
    _ERROR_PRINT(1, "Could not set signal action.");
    return NULL;
}
void* ret = functor(fArg);
t->hasReturned = true;
return ret;

The thread that executes this code will properly call the signal handler when on native linux. The problem is that on Windows Subsystem for Linux, the program hangs with the SIGUSR1 or SIGUSR2 is sent via pthread_kill which sends signals to a thread. Why does this work on native ubuntu (via VMWARE WORKSTATION 14) and debian and fedora, but NOT WSL?

Answer 1

When you have a hanging bug that you cannot reproduce when running within the debugger, you can attach the debugger to the running process after you reproduce the hang. This won't let you observe the variables changing as you lead to the hang, but at least you get the stack trace of exactly where the hang is occurring.

Once you know the process id of the hung process (assume it's 12345), you can use:

 $ gdb -p 12345

Or, you can kill the process with a signal that will cause a core to be generated. I like to use SIGTRAP , since it is easy to distinguish from a SIGSEGV .

 $ kill -SIGTRAP 12345

And then you can use gdb to discover what the process was hanging on.

The advantage of attaching to the running process is that the process is still live. This allows you to call functions from the debugger, which may provide easier access to diagnostics built into your program. The core file preserves the error, which is beneficial if the hanging bug is difficult to reproduce.