[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [eclipse.org-architecture-council] Webinars

It may be obvious, but my favorite technique for this kind of problem is to use the breakpoint suspend policy. After creating a breakpoint, right click, and under Breakpoint Properties, set Suspend Policy to "Suspend VM". Then when the breakpoint is hit, all threads are suspended and you can often see the two threads that are interacting badly. Sometimes this requires creating an extra if statement that tests for some invariant being violated, and then adding the breakpoint inside the if block.  Maybe the best way to communicate these things would be a Tips & Tricks section on the wiki where the whole community can add their favorite techniques and we can all learn from each other...

Ed Merks/Toronto/IBM@IBMCA
Sent by: eclipse.org-architecture-council-bounces@xxxxxxxxxxx

01/28/2008 08:54 AM

Please respond to
"eclipse.org-architecture-council"        <eclipse.org-architecture-council@xxxxxxxxxxx>

"Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
"eclipse.org-architecture-council" <eclipse.org-architecture-council@xxxxxxxxxxx>
RE: [eclipse.org-architecture-council] Webinars


The person had a threading problem and was not able to provide a test case
that would consistently reproduce it, as is so often the case with
threading problems that are timing dependant.  So they wrote a test case
and told me to set  a breakpoint at the point where the code creates the
other thread and a breakpoint in the starting point for that thread.  So I
run to that point, and step over the code to start the second thread which
then also starts and hits its breakpoint too.  Now both threads are stopped
at a breakpoint.  Then, for the first thread, I set a breakpoint in the
method whose thread safety is in question and run that first thread until I
get to that point.  Then I do the same thing with the second thread;
obviously it might be a different method that's accessing a common
underlying structure.  Now by stepping I can produce any kind of
interleaved thread behavior that might be possible for two threads walking
through those methods.

The gist is that it made me realize, hey, I don't need to wait patiently
for some problem to come up one in a thousand runs, I can use the debugger
itself to explore the behavior of two threads deliberately forced into the
situation that's causing problems in specific placed based on stack trace
failures.  Obviously you still need to have a theory for what's causing the
problem, but at least you don't have to wait patiently for it to just
happen by good/poor timing...

Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265  (t/l 313)

            <Martin.Oberhuber                                          To
            @windriver.com>           "eclipse.org-architecture-council"  
            01/28/2008 08:24          clipse.org>, Ed                    
            AM                        Merks/Toronto/IBM@IBMCA            

Hi Ed,

Can you help me get a light bulb go off in my head as well?
That debugging feature sounds so good I really WANT to know...

> debugger, even more effective.   For example, someone
> explained to me how
> to use the debugger to force a process into a problematic
> threading state
> to reproduce a very hard to reproduce timing dependant issue;
> a light bulb
> went off in my head where I thought, that's so simple and
> obvious, why did
> it never occur to me?


eclipse.org-architecture-council mailing list