Finding Error in Applet.

[Lew]

More specifically, the code probably contains a bug in the interactions
between threads that depends on two or more events in the code happening
in particular time relationships to each other. In addition to any
suggestions for live debug after the problem has happened, I would
recommend a design review of the synchronization between threads.

With which we could help, Sanny, if you would

** provide a simple, self-contained, compilable example (SSCCE)! **

 

[Patricia Shanahan]

Sanny wrote:
....

There is nothing wrong with the code as When the program runs It hangs
one 1/10 times. Other 10 times it performs and give results as
expected. But sometimes for same input it hangs. But when I restart
the Applet it works 9/10 time.

Is there any debugger which downloads applet just like a browser and
then provide error details when it hangs.

In this situation I would avoid investing a lot of time and effort in
changing the environment. *Anything* you do to debug this carries the
risk of reducing the failure frequency without removing the underlying
bug. A 1-in-10 failure is far easier to debug than a 1-in-100 failure.

Instead go with desk-checking combined with inserting System.err.println
statements in potentially relevant places. The sort of thing you should
be looking for is a situation in which you have a loop in the set of
resources that can be held by a thread while waiting for another resource.

For example, suppose you have a pair of objects A and B that are both
used for wait-notify, and you have two threads such that:

Thread 1 owns the lock associated with A, and is waiting for B.

Thread 2 owns the lock associated with B, and is waiting for A.

Obviously, neither thread can make progress.

In general, you should be able to write an ordered list of lockable
resources such that a thread waiting for a resource never holds anything
that appears later in the list.

Also, check that all graphics component manipulation is in the event
dispatch thread.

See http://home.earthlink.net/~patricia_shanahan/debug/ for some more
ideas on debug.

Patricia

 

[Patricia Shanahan]

With which we could help, Sanny, if you would

** provide a simple, self-contained, compilable example (SSCCE)! **

That may be difficult to do in this situation. This type of behavior
tends to be an emergent property of the whole program. Removing
something can make the problem appear to go away, by changing timings,
without fixing it.

In any case, I would rather help Sanny learn how to debug this sort of
problem.

Patricia

 

[Lew]

That may be difficult to do in this situation. This type of behavior
tends to be an emergent property of the whole program. Removing
something can make the problem appear to go away, by changing timings,
without fixing it.

In any case, I would rather help Sanny learn how to debug this sort of
problem.

Both excellent points, Patricia.

OTOH, preparing an SSCCE, when feasible, helps debug many sorts of problems.
Failing to create one teaches much in the attempt. Having others review one
and provide hints, rather than spoon-fed answers, could also help with that
latter objective.

In any event the OP has not responded to the suggestion to provide an SSCCE,
so we do not know if that is "difficult to do in this situation" or not.