[Lazarus] Debugger stops in c dll even when no breakpoint set

[Luca Olivetti]

El 29/10/21 a les 10:15, Luca Olivetti via lazarus ha escrit:
> El 28/10/21 a les 14:46, Martin Frb via lazarus ha escrit:
>> On 28/10/2021 14:28, Christo Crause via lazarus wrote:
>>>
>>> On Thu, Oct 28, 2021 at 2:01 PM Luca Olivetti via lazarus 
>>> <lazarus at lists.lazarus-ide.org> wrote:
>>>
>>>
>>>     77045AC4 cc                       int3
>>>
>>>
>>> The Int3 instruction means break, so this is the expected behaviour. 
>>> If there is no debugger inserted break point for this location, it 
>>> must be compiled into the dll code.  This means not stopping here 
>>> will be problematic, unless you use some kind of script to step over 
>>> this break instruction automatically.  I do not think it is possible 
>>> from inside Lazarus, but haven't actually tried to work around 
>>> something similar before.
>>>
>>
>>
>> FpDebug refers unknown "int3" back to the application, and lets the 
>> application handle them itself.
>>
>> At least FpDebug does this by default. There is an option in the 
>> global settings to stop.
>> But if the dll expects the int3, and therefore wants to handle it 
>> itself.....
> 
> 
> Any hint on why it hits that int3?
> 
> Now I recompiled pascallog.c (I changed its location, no wonder lazarus 
> complained it couldn't find it), and lazarus instead of showing the 
> assembler window shows the c file stopping at the call to "free".
> 
> I checked and the pointer passed to "free" is the same that "malloc" 
> returned.
> 
> malloc -> 
> https://github.com/fluisgirardi/fpopen62541/blob/d95839c908657f58bf2fde4533625a61cbccb8c7/pascallog/pascallog.c#L59 
> 
> 
> free -> 
> https://github.com/fluisgirardi/fpopen62541/blob/d95839c908657f58bf2fde4533625a61cbccb8c7/pascallog/pascallog.c#L51 

I now tested under windows 10 64 bits (the exe is 32 bits, the previous 
test was under windows 7 32 bits), and here instead of stopping once in 
ntdll!RtlpNtMakeTemporaryKey it stops twice: in ntdll!RtlZeroHeap and in 
ntdll!RtlCaptureStackContext.
The former (RtlZeroHeap) shows what it seems a bogus call stack (i.e. 
just two levels, the RtlZeroHeap itself and 00000000).

Bye
-- 
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007