On 20 Jun 2003, felix zaslavskiy wrote:

> Its hard figuring out what the problem with a threaded app could be.
>
> Say somebody is running mozila and it locks up because of some thread
> issue, what are they to report.  Alot of what thread to is
> non-deterministic and any thousands of conditions could have caused the
> problems.  Certainly its not practical to thift through thousands of
> likes of mozilla source code to try to figure out what may have caused
> the problem.  How would the debug log help here ? First it would
> generate thousands of lines and second it would be imposible to figure
> out what application was doing to generate the particular trace.

Depends on the issue. If it's a gross error, our pthread library will
(with default settings) give you a core dump, clearly labling what the
problem is.

If it's a race condition, you can still figure out what's going on. See
the notes I've sent out about seeing what's going on.

The general idea is that you look at the list of sleeping threads and find
a case where thread A is sleeping for something owned by thread B, which
in turn is sleeping on something owned by thread A.

So that's two common cases. The third case is hard to tell about; where
there was a timing race that's hard to deal with. Say a thread signals a
condvar before the sleeper gets to sleep on it. i.e. an inter-thread
signal gets dropped. These bugs take a lot of understanding of the app to
find.

Take care,

Bil