Re: [Lazarus] Masks: the naming of ...
On Wed, Oct 27, 2021 at 11:56 PM Maxim Ganetsky via lazarus wrote: > > Opinions please. > > Looks good to me. Done. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Debugger stops in c dll even when no breakpoint set
On Fri, Oct 29, 2021 at 10:41 AM Luca Olivetti via lazarus < lazarus@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 ). > 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 Since the code writes something to memory in the int3 branch, check errno to see if that reveals something. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Debugger stops in c dll even when no breakpoint set
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 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 ). Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Debugger stops in c dll even when no breakpoint set
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 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 Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
