What that means? An exception, access violation or what? It probably happens somewhere in my UI Automation implementation. The Call stack window doesn't show useful information. An F7 key tells something like "Cannot find function boundary". So curently I don't know how to debug this problem.

How did the app run before?

check the "threads" window.

you may be in the wrong thread (OS may add threads, even if your app does not have them)

did you do stepping, or did you run F9?

what OS?

what version of gdb?

http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_debug_session

provide a log (if not possible then at least  the output of the "debug output" window/ open this before the problem happens)

there should be a lines like

*stopped, reason=...

the last such line should give a clue.

OS is Windows 10, Lazarus 1.9, GDB 7.2.
How can I see thread? How can I open a debug log windows? In which menu it is? Or is it displayed somewhere? Because I am unable to "see" it with screen reader. So It may look I am asking for something obvious, sorry. Dňa 13. 11. 2017 o 13:49 Martin Frb via Lazarus napísal(a):

The thread window is in the view menu. there is a sub-menu "debug windows" and there it can be found.
It should also appear with ctrl-alt-t

The debug log window is in the same sub menu. But it is not called "log" it is called "Debug Output"
This window shows raw gdb communications.

Rather than looking at debug output, start the IDE with the following command line

lazarus.exe  --debug-log=C:\lazlog.txt
--debug-enable=DBG_CMD_ECHO,DBG_STATE,DBGMI_QUEUE_DEBUG

this will create a logfile, that you can attach to your next mail (or if to big for the mailing list, send to my email directly)

Some more info on the original questions:

The error about "not finding boundary", happens because your app is paused in code with no debug info. So the debugger does not know where the function starts or end. Nor does it know where the line starts, as there is no info on lines.

Alt F7 will step assembler instruction, but you may have to step thousands before getting anywhere. (If ever you will at all).

The missing stack means the code is not following convention of how to use stack. It is either compiled with optimization, or more likely it is not compiled by fpc. The code is probably Kernel, or some OS or 3rd party library.

Martin Frb wrote

Some more info on the original questions:

While it would still be good to know what happens (see other part of this mail thread.)

If this is caused by a 3rd party library, you may try if the following helps

go to menu Tools, options.
On the page "Debugger", "general" there is a grid (like the object inspector has).
One of the properties you can set there is called
DisableLoadSymbolsForLibraries. Change this to TRUE.

Oh, View menu, of course. I am stupid indeed. :)
I just updated a GDB to version 7.7.1 and now at least the stack trace makes more sense. It is full of Windows API calls. However, here is a part of debug output which seems to be relevant, at least I am not sure what exactly this can be:
&"warning: HEAP[project1.exe]: \n"
&"warning: HEAP: Free Heap block 105AA5B0 modified at 105AA5D0 after it was freed\n"
&"\n"
~"[Switching to Thread 4928.0x13e8]\n"
*stopped,reason="signal-received",signal-name="SIGTRAP",signal-meaning="Trace/breakpoint trap",frame={addr="0x778661e2",func="ntdll!RtlCaptureStackContext",args=[],from="C:\\WINDOWS\\SYSTEM32\\ntdll.dll"},thread-id="9",stopped-threads="all" =thread-selected,id="9"

I extracted this output immediately after the Assembler window appeared. Other things there are library loaded, thread created, etc. If you still thinks it makes sense to post the Lazarus debug output you suggested, I can of course do it.

Dňa 13. 11. 2017 o 17:18 Martin Frb via Lazarus napísal(a):

The info is enough for explaining what happens.

Before I go to the reason: It is strange the debugger does not indicate that your app was killed by a signal SigTrap. (That should be reported as bug)

The signal is actually caused by FPC (more below), and it looks like this causes windows to create an additional thread in your app. That explains the stacktrace. You may need to select the other thread, to see where in your app the issue occurred. (missing auto selecting the correct thread, is a bug too, but may not always be possible) But even the other stack trace may not be of use, see below.

So what happened is:
You have code that writes to memory that was already freed. Most likely you freed an object, and then accessed the no longer existing object. You may have a 2nd variable holding a pointer to it.

Of course it can be any other memory access, not necessarily a freed object. Maybe you used GetMem/FreeMem. Or you used a pchar to a no longer existing string. Or you incorrectly used a const param. Or something else...

Your app is compiled with -gh (that is HeapTRC). and this checks (to a limited extend) if freed memory is later modified. The message "HEAP: Free Heap block 105AA5B0 modified at 105AA5D0 after it was freed" is from HeapTRC. It normally is printed to stderr. You can see that, if you compile with console window -WC (there is also an option in project options, but it uses a different switch)

Those errors are often very hard to trace.
AFAIK Heaptrc checks for the modification when you allocate/free memory. But by that time the code that incorrectly wrote to it has long been executed. So the stacktrace will help very little.

You can try to inspect the memory at this address. Not sure maybe a watch like PByte($105AA5D0)^
Maybe this will show some data you can identify. From my experience though, this is unlikely.

Not sure if HeapTRC can get you better info.

The best way I know to get results are:
Either inspecting code to find the  issue without debug.

Or use valgrind on linux (If you can reproduce on linux)

Or use watchpoints (data break points). You need a reproducible test case that always gets you the same address for the error. You need to use a PByte as above to set the watchpoint (I haven't done it in a while, you may have to play around). But that will give a lot of false positives. Too many.

There is the environment variable HEAPTRC which you can set to keepreleased Then the memory will be used only once.
Find the address of the error with keepreleased, then track this address with a watchpoint, and you find the object that uses the memory. Then - once the object is freed - the watchpoint will trigger, when the memory is incorrectly accessed.

That is the theory. The praxis can be a long and painful search.