There is a painful way - trace backup through the "Real" CPU stack to find where the
OS was called from. Hopefully this is in your code.
To do this you need to turn stack frames on and rebuild all units (including VCL and
CORBA units) then you need to know the structure of the CPU stack. The hit and miss
method is to just look back in the stack recognising the calling addresses from your
programs - not too bad if you do not have large local variables in your
methods/procedures.
The CPU window does have the "Caller" function - trace back in the code window to the
caller of the current procedure using the stack, but I have found it only works for
the first level - which when you have this kind of problem is usually never enough
(has anybody got it work tracing further back up the call chain??).
Myles.
-----Original Message-----
From: Kerry Sainsbury [SMTP:[EMAIL PROTECTED]]
Sent: Tuesday, June 29, 1999 9:20 AM
To: Multiple recipients of list delphi
Subject: [DUG]: What am I waiting for?
Hi folks,
I have some code (a Delphi CORBA server) that likes to freeze up after an
hour or more of multi-threaded abuse.
The server's threads are sitting in either WaitForSingleObject or
WaitForMultipleObject.
Fine. We obviously have a deadlock. But where? Is there any way of telling
*what* we're waiting on - by looking at the registers in the CPU window, or
something?
It *can't* be any of my code (he says optimistically) because the current
version protected method calls with a shared critical section.
Thanks,
Kerry S
PS: Paul - you can stop laughing now :-)
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
application/ms-tnef
