[Lazarus] Debugger stops in c dll even when no breakpoint set
luca at wetron.es
Wed Nov 3 15:56:34 CET 2021
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>>
> 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
> 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
> 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
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"
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.
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007
More information about the lazarus