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

[Luca Olivetti]

El 29/10/21 a les 12:48, Christo Crause ha escrit:
> 
> On Fri, Oct 29, 2021 at 10:41 AM Luca Olivetti via lazarus 
> <lazarus at lists.lazarus-ide.org <mailto:lazarus at lists.lazarus-ide.org>> 
> wrote:
> 
> 
>     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).
> 
> 
> Searching around seems to suggest that RtlpNtMakeTemporaryKey is 
> typically part of a stack trace involving memory/stack corruption or 
> freeing an invalid reference or already freed pointer.  See this 
> example: 
> https://stackoverflow.com/questions/45162248/calling-free-in-c-triggers-ntdlldbgbreakpoint-in-debug-but-crashes-in-rel/45247035 
> <https://stackoverflow.com/questions/45162248/calling-free-in-c-triggers-ntdlldbgbreakpoint-in-debug-but-crashes-in-rel/45247035>
> 
> Since the code writes something to memory in the int3 branch, check 
> errno to see if that reveals something.

OK, I added a

    printf("Error clear %d: %s\n", errno, strerror(errno));

after the call to free.
When run outside the debugger, it prints "Error clear 0: no error", when 
run from lazarus "Error clear 22: Invalid argument".

I then found this document
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/free?view=msvc-160
it says that "when the application is linked with a debug version of the 
C run-time libraries, free resolves to _free_dbg", but I don't think it 
does that dynamically based on how the app is been called (directly or 
through a debugger), or does it?

In any case I checked the documentation for the "CRT Debug Heap"

https://docs.microsoft.com/en-us/visualstudio/debugger/crt-debug-heap-details?view=vs-2019

and the bytes surrounding my allocated data aren't the same as explained 
in that article and they are the same before calling free as they were 
after calling malloc.


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