GDB: Cannot continue after attaching to process

[rgraebert]

I trying to debug a problem with my deb package, but gdb is not being helpful.

1. I can attach to the process shown by PS, but once I try to continue I get:
   Continuing.
   pthread_cond_wait@@GLIBC_2.3.2 ()
   at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
   185 in ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S
   Couldn't write debug register: Invalid argument.

2. When I ask gdb to "run" and replying yes to "the program being debugged has been started already. Start from beginning", the terminal freezes.

[benhillis]

We recently made many improvements to the ptrace system call that gdb uses. One of the next insider flights will have much better gdb support.

[rgraebert]

Great. Will you post these releases here on Github? Or what is the best way to receive notifications of bash improvements in the next buiild?

[benhillis]

Yes. I believe the current plan is to post a "what's new in build #####" type post when new flights are released.

[aseering]

Thanks! I'm looking forward to the updated GDB support :-)

I'm able to attach to some (simple) programs. I'm specifically unable to attach to any program that uses threads. Here's a minimal reproducer, which I've posted elsewhere before but am forwarding here to help keep bug reports all in the same place:

#include <pthread.h>

// Make thread spin indefinitely
void *spin(void * no_arg)
{
    while (1) ;
    return NULL;
}

int main()
{
    pthread_t spin_thread;
    pthread_create(&spin_thread, NULL, spin, NULL);
    while (1) ;
    return 0;
}

If I compile this program as a Linux binary with gcc and try to run it under gdb, I get:

(gdb) run
Starting program: /mnt/c/Users/[me]/a.out
warning: Error disabling address space randomization: Success
warning: linux_ptrace_test_ret_to_nx: PTRACE_KILL waitpid returned -1: Interrupted system call
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ff5ff600700 (LWP 414)]
Cannot find user-level thread for LWP 410: generic error
(gdb)

Anyway, one more test case for you. Not sure if you need it, but, here you go in case it's useful.

[aseering]

ping, update: The reproducer above still fails for me under build 14342. It seems that the GDB improvements above either haven't been shipped yet, or don't cover this use case.

[sunilmut]

@aseering - Yes, this specific scenario has not been enabled yet. We are currently investigating it. Stay tuned!

[aseering]

Just an update: This still doesn't work with build 14361.

Another specific use case: I was looking into PulseAudio's behavior in #486, trying to see exactly why it opens a SOCK_DGRAM socket and whether it could be avoided by a configuration option. I was able to break at the socketpair() syscall, but gdb wasn't able to print the stack at that point.

[sunilmut]

@aseering - If you are referring to AF_UNIX\SOCK_DGRAM, then that's accurate. It's not yet implemented.

[aseering]

@sunilmut -- thanks -- did you mean to post that comment to #486 ?

[bitcrazed]

@rgraebert - Could we ask you to retry this issue on build 14936+ as it may have been fixed. Thanks.

[misenesi]

I see this working on my latest build (with ptrace fix related to other issue that I should be checking in shortly).

[aseering]

@misenesi -- this is still an issue; did the fix miss Creator's?

[aseering]

Hm: I tried my simple reproducer above against the latest Insider build, and it no longer reproduces. But the application that I'm actually trying to debug (which is not public) is still failing. I'm working on a standalone reproducer but don't yet have one.

[therealkenc]

This one is dangling. The OP problem up top was almost certainly addressed in 15063 if not earlier. The CPU-bound scenario didn't make Fall Creators 16299. Also present in Fall Creators but currently addressed as of 17017 is #2333. We'll call #2333 and the CPU-bound scenario the same for the sake of argument; either way they are both addressed in this cycle. If there are other problems with gdb they can be filed under a different cover, or this issue (namely the OP) will just end up open through the Spring update coming RSN.