Subject: Re: libpthread -- document libpthread debugging technique?
To: None <firstname.lastname@example.org, email@example.com>
From: None <firstname.lastname@example.org>
Date: 06/24/2003 12:19:09
On Friday 20 June 2003 16:59, Jason Thorpe wrote:
> No, I don't. While I don't expect everyone to be an expert, I do
> expect a little more effort that I seem to be seeing.
> The pthread library has a number of debugging options. There is a
> debug log that you can run a dmesg-like program on to get pretty
> detailed information on every action the library takes. There are also
> various application debugging options (note that a fair number of
> things that were blamed on libpthread at first turned out to be bugs in
> the applications!).
Okay, I have a (hopefully helpful) suggestion here.
Whenever I see a problem with a libpthread assert, or a coredump, or some
weird set of processes just sitting there unkillable, I would love nothing
more than to dive in with a debugger and try to figure out what's going on.
Unfortunately what many of us eager bucks lack is the technique to delve.
I knew there was a debugging library, attempted to use it a few times, but
never saw any log, nor any dmesg-like output.
So here's the suggestion: How do I do it? Run me (and people like me) through
a few debugging sessions and show us how *you* debug a threaded app problem
(even if it's just capturing the next problem you run through) and believe
me, more of us will jump on the bandwagon. I did list a few problems to the
mailing list, but I got the strong impression I wasn't helping matters
because I was unable to define precisely what the problem was or where it was
occurring in the software I was crashing.
Anyway, believe us, we want to help more. We just need a leg up. :) Book
recommendations would be terrific also. :)
> When people see failures, they should use the tools at their disposal
> to get as much information as possible about the failure. You don't
> have to be an expert in how the SA/pthreads system works to do this.
> I know of one person (Bill Studenmund, an expert in a number of areas,
> but whom I suspect will not claim to be an expert in how SA/pthreads
> works :-) who has had great success at getting pthreads bugs fixed by
> providing very thorough debugging information to Nathan when he has a