I have a problem in a dll (including a COM object): when the dll is unloaded some finalization sections are executed and some are not.
in the debugger I could manage to locate the problem in System FinalizeUnits(). pseudo code of this function - for your convenience:
procedure FinalizeUnits;
var
Count: Integer;
Table: PUnitEntryTable;
P: Pointer;
begin
if InitContext.InitTable = nil then
exit;
Count := InitContext.InitCount;
Table := InitContext.InitTable^.UnitInfo;
try
while Count > 0 do
begin
Dec(Count);
InitContext.InitCount := Count;
P := Table^[Count].FInit;
if Assigned(P) and Assigned(Pointer(P^)) then
begin
// ISSUE: when this is called for item x the debugging just stops
// breakpoints in the except block or at the end of the function are not reached!
TProc(P)();
end;
end;
except
FinalizeUnits; { try to finalize the others }
raise;
end;
end;
there is one specific finalization call that causes the problem:
ie the InitContext.InitCount
is about 400 and when item x (eg 363) is executed, the debugger just stops: it does not proceed to the except block and also not to the end of the FinalizeUnits()
function (where I have set breakpoints).
BTW: how is that possible? I thought the except block (or the line after it) must be called in any case.
notes:
TProc
I end up in TCriticalSection.Enter
(then Acquire
- FSection.Enter
- EnterCriticalSection
- WSACleanup
) some more info to the WSACleanup
call: I use a 3rd party library UniDAC that opens a TCP/IP connection to a database - I think this library calls WSACleanup
in one of it's finalization sections (but I don't have this source code). The strange thing is, that when the debugger is on the WSACleanup
line:
function WSACleanup; external winsocket name 'WSACleanup';
and I want to step over it (ie F8), the debugger just stops (as if the application had exited normally) - but it should continue the loop in FinalizeUnits
: how is this possible? ie if it were a deadlock it would not stop, but hang forever, right?
The question is: how can I debug this issue? is it possible that a deadlock causes this problem (ie that the debugger just stops)?
Try switching to CPU view before stepping into the problematic TProc using F7. Sometimes this can give you a good hint.
You could also try looking up the address of "P" in the map file.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.