← Back to index

Attaching to a stopped process.

Santtu Keskinen
#21942
Hi!

I'm trying to get a setup where I can write to tracee's stdin from a 3rd process while debugging.
I thought that the best way to get this is to start both the debugger and the tracee from a common parent.

Here's what I have (the interesting part are the PTRACE_DETACH lines): 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <wait.h>
#include <sys/ptrace.h>

int main(int argc, char** argv) {
    int wait_status;
    if (argc != 2) {
        printf("Argument: Binary to debug.");
        exit(1);
    }

    int fd[2];
    pipe(fd);
    pid_t pid_to_debug = fork();
    if (pid_to_debug == 0) {
        close(fd[1]);
        close(0);
        dup(fd[0]);
        ptrace(PTRACE_TRACEME, 0, 0, 0);
        execl(argv[1], argv[1], (char*)0);
    }
    close(fd[0]);
    printf("Child pid %d\n", pid_to_debug);
    waitpid(pid_to_debug, &wait_status, 0);

    //ptrace(PTRACE_DETACH, pid_to_debug, 0, SIGSTOP); // Codeclap hangs, gdb works
    ptrace(PTRACE_DETACH, pid_to_debug, 0, 0); // Lets pid_to_debug run = not good

    dprintf(fd[1], "payload");
    close(fd[1]);

    int use_gdb = 0;
    int use_codeclap = 1;

    if(use_gdb ^ use_codeclap) {
        printf("Start debugger\n");
        pid_t pid_debugger = fork();
        if (pid_debugger == 0) {
            char buffer[100];
            sprintf(buffer, "%d", pid_to_debug);
            if (use_gdb) {
                execlp("gdb", "gdb", argv[1], buffer,
                        (char*)0);
            }
            if (use_codeclap) {
                execlp("codeclap", "codeclap", buffer,
                        (char*)0);
            }
        }
    }
    do {
        waitpid(pid_to_debug, &wait_status, 0);
    } while (WIFSTOPPED(wait_status));
}


Unfortunately when I try to attach to a SIGSTOPped process with codeclap it just hangs.
Codeclap backtrace: 
1
2
3
4
5
#0  0x00007fdffb6c2c45 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#1  0x00000000004e2feb in DebuggerStart ()
#2  0x00000000005281b3 in DebuggerFrontendProcess ()
#3  0x000000000053b7e3 in xcbFrontendThread.constprop.221 ()
#4  0x0000000000460d4e in main ()



I had quite a few other problems as well when playing with attaching so maybe it's just alpha. I'll list some additional UX things I saw just in case:
* Even normal attach of a running process throught the ui hangs maybe 20% of the time. Same pthread_cond_wait@@GLIBC_2.3.2.
* Pressing continue/step/etc. after attaching just detaches. It's quite confusing. Things normalize if I repeatedly hit run+pause all threads until I hit debuggable code. Also stacktrace doesn't show anything before "getting out of limbo".
* I think it would be better to automatically open the first thread in debug view after attaching. Now you have to first select a thread to do anything which is annoying.

Overall Codeclap seems very promising! Looking forward to having an awesome debugger on Linux.
Edited by Santtu Keskinen on Reason: Initial post
spx
#21944
Hi,

I will take a look at this, thanks for the example. Unfortunately, at the moment, the attach code is probably the least mature part of the whole debugger because it isn't well tested and from what I can assume is also less commonly used compared to the "normal" startup.
Edited by spx on
Santtu Keskinen
#21945
Totally understandable. I agree that attaching is not the most critical function.
← Back to index