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

Luca Olivetti 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, 
d'oh!).
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 
stupid error 
https://github.com/olivluca/fpopen62541/commit/e5ec2cab8e97eeeba29e33b801de6e42a0084ca8

I don't know where that message came from, but is there a way to see it 
while debugging the application under lazarus?


Bye


> 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


More information about the lazarus mailing list