RE: [eclipse.org-architecture-council] Webinars

[Ed Merks <merks@xxxxxxxxxx>]

Martin,

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)




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




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?

Thanks,
Martin