5

We have a multi-process application where debugging a specific child process is proving difficult. Due to messaging timeouts between the processes we don't have time to attach gdb to the target child, so I was wondering if I can stop a process via an systemtap probe?

A simple probe should, I think, be needed, eg.:

probe process("exeName").mark("STOP_HERE")
{
    force_sig(SIGSTOP, current);
}

Unfortunately, the above's not compiling ... any ideas?

I'm not a systemtap expert, so this isn't probably the best solution, but here's my crude solution for anyone interested:

#!/bin/stap -g

global gdbRunning = 0;

probe process(@1).mark(@2)
{
    raise(%{ SIGSTOP %});

    gdbCmd = sprintf("cgdb -- -q -ex 'thread find %d' %s %d", tid(), @1, pid());

    if (gdbRunning == 0)
    {
        gdbRunning = 1;
        printf("STOP PID %d TID %d [%s]\n", pid(), tid(), gdbCmd);
        system(gdbCmd);
    }
    else
    {
        printf("STOP PID %d TID %d\n", pid(), tid());
    }
}
mrtimdog
  • 487
  • 4
  • 13
  • I will recommend you start your process with single child process. It will be easier to start with single child instead of creating multiple then writing a handler to stop them .. – Jain Rach Dec 10 '13 at 13:30
  • Rachit Jain; thanks for the suggestion, but that's not an option unfortunately - it would have made things much easier. Another alternative I may try out of interest is lldb, which starts up and can attach much much quicker than gdb can (but I'm sticking with fche's answer for the mo). – mrtimdog Dec 11 '13 at 07:46

1 Answers1

5

See man function::raise(3stap), new as of systemtap 2.3 (2013-07-25).

stap -g -e 'probe WHATEVER { raise(%{ SIGSTOP %}) }'

You need guru mode to let your script use this function.

fche
  • 2,641
  • 20
  • 28
  • Excellent, thank you very much - this is exactly what I was after :) I was sillilly trying to set task states per thread via set_task_state(...), but oddly enough that didn't work as it doesn't really tell the kernel what I'm attempting to do. No idea why I didn't think of kill(...) alternatives, i.e. raise(...)!! Thanks! – mrtimdog Dec 11 '13 at 07:38
  • 1
    Doh! I'd read straight past raise in the docs! ... "function::raise — raise a signal in the current thread" :) – mrtimdog Dec 11 '13 at 08:01