[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fun with LD_PRELOAD
From: |
Doug Evans |
Subject: |
Re: Fun with LD_PRELOAD |
Date: |
Wed, 5 Feb 2014 10:21:19 -0800 |
On Tue, Feb 4, 2014 at 3:21 AM, Ludovic Courtès <address@hidden> wrote:
> Hi, Doug,
>
> Doug Evans <address@hidden> 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.