Fun with LD_PRELOAD

Fun with LD_PRELOAD

[Doug Evans]

Hi.
Here's my system-call wrapping module for gdb+guile.
At this point it's just a prototype, and an initial one at that.

It's kinda useful to see the system call tracing amongst gdb's own
debug output, but my real goal is to explore ways of exercising gdb
that are otherwise harder to do.
With this I can script what happens when gdb does ptrace,waitpid,tkill,etc.
Whether this exploration yields anything useful ... TBD.

git clone git@github.com:xdje42/wrap-syscall.git

To run the example:

GDB=/path/to/gdb-with-guile ./configure
make
make run
-->
...

waitpid (-1, 140736922396708, -2147483647) -> (42816 . 0), 1407
LNW: waitpid(-1, ...) returned 42816, ERRNO-OK
LLW: waitpid 42816 received Trace/breakpoint trap (stopped)
ptrace (3 (PTRACE_PEEKUSER), 42816, 896, 0) -> (16384 . 0)
syscall (200 (tkill), 42816, 0) -> (0 . 0)
LLTA: KILL(SIG0) Thread 0x7f03c7d4a700 (LWP 42816) (OK)
LLW: Candidate event Trace/breakpoint trap (stopped) in Thread
0x7f03c7d4a700 (LWP 42816).
SC:  kill Thread 0x7f03c74f9700 (LWP 42817) **<SIGSTOP>**
Injecting SIGUSR1 to 42817 ...
syscall (200 (tkill), 42817, 19 (SIGSTOP)) -> (0 . 0)
SC:  lwp kill 0 ERRNO-OK
SC:  kill Thread 0x7f03c6ca8700 (LWP 42818) **<SIGSTOP>**
syscall (200 (tkill), 42818, 19 (SIGSTOP)) -> (0 . 0)
SC:  lwp kill 0 ERRNO-OK
SC:  kill Thread 0x7f03c6457700 (LWP 42819) **<SIGSTOP>**
syscall (200 (tkill), 42819, 19 (SIGSTOP)) -> (0 . 0)
SC:  lwp kill 0 ERRNO-OK
SC:  kill Thread 0x7f03c5c06700 (LWP 42820) **<SIGSTOP>**
syscall (200 (tkill), 42820, 19 (SIGSTOP)) -> (0 . 0)
SC:  lwp kill 0 ERRNO-OK
SC:  kill Thread 0x7f03c8533740 (LWP 42813) **<SIGSTOP>**
syscall (200 (tkill), 42813, 19 (SIGSTOP)) -> (0 . 0)
SC:  lwp kill 0 ERRNO-OK
waitpid (42817, 140736922396252, 1) -> (-1 . 10), 0
waitpid (42817, 140736922396252, -2147483647) -> (42817 . 0), 2687
WL: waitpid Thread 0x7f03c74f9700 (LWP 42817) received User defined
signal 1 (stopped)
ptrace (3 (PTRACE_PEEKUSER), 42817, 896, 0) -> (0 . 0)
SWC: Pending event User defined signal 1 (stopped) in Thread
0x7f03c74f9700 (LWP 42817)
...

Re: Fun with LD_PRELOAD

[Ludovic Courtès]

Hi, Doug,

Doug Evans <xdje42@gmail.com> skribis:

> It's kinda useful to see the system call tracing amongst gdb's own
> debug output, but my real goal is to explore ways of exercising gdb
> that are otherwise harder to do.
> With this I can script what happens when gdb does ptrace,waitpid,tkill,etc.
> Whether this exploration yields anything useful ... TBD.

Looks fun.  So the main application would be to stress-test GDB and see
if it misses signals sent to application threads right when GDB is about
to stop them, for example, right?

Cheers,
Ludo’.

Re: Fun with LD_PRELOAD

[Doug Evans]

On Tue, Feb 4, 2014 at 3:21 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> Hi, Doug,
>
> Doug Evans <xdje42@gmail.com> skribis:
>
>> It's kinda useful to see the system call tracing amongst gdb's own
>> debug output, but my real goal is to explore ways of exercising gdb
>> that are otherwise harder to do.
>> With this I can script what happens when gdb does ptrace,waitpid,tkill,etc.
>> Whether this exploration yields anything useful ... TBD.
>
> Looks fun.  So the main application would be to stress-test GDB and see
> if it misses signals sent to application threads right when GDB is about
> to stop them, for example, right?

Something like that.

For example, a colleague at Google tripped over a bug that requires a
specific timing to replicate.  I don't have all the details at hand,
but I think I'm hitting the same assert.

infrun.c:1948: internal-error: resume: Assertion
`pc_in_thread_step_range (pc, tp)' failed.

AIUI, It happens, for example, when the user does a "next", and a
signal arrives on another thread while the thread being next'd has
stepped into a subroutine (thus requiring gdb to step out to implement
the semantics of "next").  I now have a simple repro (at least for the
assert I'm seeing), and it was very straightforward to write.  It
involves tracking the PTRACE_SINGLESTEP being issued to one thread
(that implement "next") and at the right time send a signal to another
thread.

I've made it very easy to add more syscalls, and the wrapping
machinery itself is not gdb specific.  Maybe it would be useful in
either apps, I don't know.

Re: Fun with LD_PRELOAD

[Pedro Alves]

(removed guile)

As we're talking about it,

On 02/05/2014 06:21 PM, Doug Evans wrote:

> For example, a colleague at Google tripped over a bug that requires a
> specific timing to replicate.  I don't have all the details at hand,
> but I think I'm hitting the same assert.
> 
> infrun.c:1948: internal-error: resume: Assertion
> `pc_in_thread_step_range (pc, tp)' failed.
> 
> AIUI, It happens, for example, when the user does a "next", and a
> signal arrives on another thread while the thread being next'd has
> stepped into a subroutine (thus requiring gdb to step out to implement
> the semantics of "next").  I now have a simple repro (at least for the
> assert I'm seeing), and it was very straightforward to write.  It
> involves tracking the PTRACE_SINGLESTEP being issued to one thread
> (that implement "next") and at the right time send a signal to another
> thread.

perhaps you could check whether the patch at

  https://sourceware.org/ml/gdb-patches/2014-01/msg00910.html

also fixes your reproducer?

-- 
Pedro Alves

Re: Fun with LD_PRELOAD

[Doug Evans]

Pedro Alves <palves@redhat.com> writes:
> (removed guile)
>
> As we're talking about it,
>
> On 02/05/2014 06:21 PM, Doug Evans wrote:
>
>> For example, a colleague at Google tripped over a bug that requires a
>> specific timing to replicate.  I don't have all the details at hand,
>> but I think I'm hitting the same assert.
>> 
>> infrun.c:1948: internal-error: resume: Assertion
>> `pc_in_thread_step_range (pc, tp)' failed.
>> 
>> AIUI, It happens, for example, when the user does a "next", and a
>> signal arrives on another thread while the thread being next'd has
>> stepped into a subroutine (thus requiring gdb to step out to implement
>> the semantics of "next").  I now have a simple repro (at least for the
>> assert I'm seeing), and it was very straightforward to write.  It
>> involves tracking the PTRACE_SINGLESTEP being issued to one thread
>> (that implement "next") and at the right time send a signal to another
>> thread.
>
> perhaps you could check whether the patch at
>
>   https://sourceware.org/ml/gdb-patches/2014-01/msg00910.html
>
> also fixes your reproducer?

Yes it does, thanks.