[Lazarus] Debugger stops in c dll even when no breakpoint set
luca at wetron.es
Wed Nov 24 13:41:21 CET 2021
El 3/11/21 a les 15:56, Luca Olivetti via lazarus ha escrit:
A quick follow up: I used the wrong size when mallocing data (size of
the pointer variable instead of the size of the struct it pointed to,
I found it by running the program under windbg and there I saw a message
saying that I wrote to a memory area beyond the 4 bytes allocated. I
wondered why 4 bytes when my struct is bigger and then I found the
I don't know where that message came from, but is there a way to see it
while debugging the application under lazarus?
> 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
>> 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