Blank form, program hanging in debug

[hakelm]

I have the following little annoying problem:
When I start my application in the IDE-debugger a blank form is opened up and the program (debugger?) hangs and can only be stopped with ctrl-F2
If I however single step to
Application.Run;
in the project file and then press F9 everything seems to work.
What can I do?
H
Ps
I am using Lazarus 1.6+dfsg-1 on Ubuntu 16.04

[Martin_fr]

Strange...

Does "Pause" work?

You can try (far fetched) http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#On_Windows_Open.2FSave.2FFile_or_System_Dialog_cause_gdb_to_crash

------------------
Which version of gdb?

anything above gdb 7.7 may have issues with stabs. (afaik default by fpc)

Setting is in Project options / debug
AND fore EACH package in the package options.

(or use "Additions and overrides)
Either way, try changing ALL debug info to dwarf (with sets) / (But not dwarf 3)

---------
If still no success, go to the bottom of the page I linked above, and provide a log file.

--
Btw always use F9 to start your app (or "Run" from the menu, or the run button).
Do not start your app with F7 or F8, only use those if the app is already running/paused.

[hakelm]

Thanks
Synaptic tells me I have GDB 7.11.1-0ubuntu1~16.04, which I assume Lazarus uses.
I tested the different choices for debugger info and it is only Dwarf3(beta) (-gw3) that seems to work but Pause does not work:

The file "../sysdeps/unix/syscall-template.S" was not found.
Do you want to locate it yourself?

There is no file syscall-template.S on my system. What can I do about that?
Pls note my system has worked flawlessly earlier but in order to get anchordockingdsgn to work having tried some different Lazaruses but now I have reverted to 1.6+dfsg-1.
H

[Sieben]

Sorry for reviving an old thread, but it describes exactly what's happening here now. Unfortunately the origininal OP didn't leave a solution. It seems to happen only with new projects, my older and more complex projects all seem to work.

With new projects the main form seems to start ok with first compile, but on second ord third start comes up blank and cannot be closed other than Ctrl+F2. Sometimes it additionally freezes and produces a SIGKILL when halted.

Starting with F8 and slowly stepping to Application.Run isn't reliable as well, as though it seems to work more often than pure F9. Toggling between F9 and Start via Toolbar gives similar results - it starts more often, but not reliably.

I have recompiled the IDE, rebooted several times, started new projects from scratch to no avail. Tried to compare project settings but can't find a difference. No recent changes to IDE or other settings.

GDB reports:

Code: Bash  [Select][+][-]

1. GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
2. Copyright (C) 2016 Free Software Foundation, Inc.
3. ...
4. This GDB was configured as "i686-linux-gnu".
5. ...
6. This GDB was configured as follows:
7.    configure --host=i686-linux-gnu --target=i686-linux-gnu
8.              --with-auto-load-dir=$debugdir:$datadir/auto-load
9.              --with-auto-load-safe-path=$debugdir:$datadir/auto-load
10.              --with-expat
11.              --with-gdb-datadir=/usr/share/gdb (relocatable)
12.              --with-jit-reader-dir=/usr/lib/gdb (relocatable)
13.              --without-libunwind-ia64
14.              --with-lzma
15.              --with-python=/usr (relocatable)
16.              --without-guile
17.              --with-separate-debug-dir=/usr/lib/debug (relocatable)
18.              --with-system-gdbinit=/etc/gdb/gdbinit
19.              --with-babeltrace

Ubuntu 16.04.7 32Bit (up to date), Lazarus 2.0.10 with FPC 3.2.0 deb install. Second install Lazarus trunk seems to work ok.

It's annoying and i'm stuck...

[Thaddy]

"i686-linux-gnu" is not "i386-linux-gnu"....  There is another reference that it is configured for 64 bit (the usually unusual IA-64).
See https://en.wikipedia.org/wiki/IA-64
See also https://packages.ubuntu.com/bionic/devel/gcc-6-i686-linux-gnu where you can also find a reference to the proper GDB....

You state that you have a 32 bit OS. That is not a problem, but your GDB configuration is completely configured for 64 bit and probably even with the wrong processor except maybe for cross compilation if you are REALLY using an IA-64 which is usually unlikely. I would expect X64 in that case.

Can you type:

Code: Bash  [Select][+][-]

1. uname -a

and report back?
Then we know what we are dealing with.

[Sieben]

Code: Bash  [Select][+][-]

1. $ uname -a
2. Linux 4.15.0-122-generic #124~16.04.1-Ubuntu SMP Thu Oct 15 16:14:02 UTC 2020 i686 i686 i686 GNU/Linux

And uname -m states i686 as well. Ancient Intel Core 2 Duo.

[Martin_fr]

If the first run usually works, then in tools > options, set under debugger "reset after each run".

Also try changing the "internal start break" in the property grid.

Or use FpDebug.

--------------
I am away. If you create a log
https://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_debug_session

and ping me in about 10 days, I can check if I can spot anything else....

[Sieben]

If the first run usually works, then in tools > options, set under debugger "reset after each run".

Tried that already (and resetting via Tools menu) to no avail. And it might happen on first run as well.

Also try changing the "internal start break" in the property grid.

Tried all available options now, also to no avail.

Or use FpDebug.

Installed package LazDebuggerFp from ../components/lazdebuggers now, set debugger info to 'dwarf 2 with sets' as IDE suggested and it seems to work for now, with a strange effect remaining however. I have a very simple test project with an event handler that crashes on application terminate (which I think should not happen) - but only when running inside IDE and with debugger. Running outside or without debugger (Ctrl+Shift+F9) it does not crash. And if memory serves all this troubles seem to have started after this happened for the first time. And every project created prior to that still runs happily with gdb...

[Martin_fr]

Can you sent me the crashing example ?

I am away though, so only going to look at it in 1 or 2 weeks....

[Sieben]

It's this one, originally meant to demonstrate an issue with TShellTreeView here. Crash happens on the Collapsed/Expanded handler (and can be prevented with if not Application.Terminated of course).

Created and published with 2.0.10/3.2.0.

[bytebites]

Missing package rkUtil

[Sieben]

Sorry, tried to be fast... just remove it.

Edit: removed dependency above.

[Sieben]

Sorry, forgot to create a log like you suggested, but since you seem to be back did you possibly have a look...?

[Martin_fr]

Sorry, forgot to create a log like you suggested, but since you seem to be back did you possibly have a look...?

I meant "I can have a look at the log file". This is in case gdb reports any error, but the error is hidden by the IDE.
If there is a detect-able error, then there may be a way to deal with it. At least make sure it is reported to the user. If not, then this is more complicated. (I do not have Ubuntu, and the problem does not happen on my (older) Fedora).

The gdb based debugger also has an option to skip loading library symbols => worth a try....

Btw, not sure if any relationship at all, but there is another thread mentioning issues on Ubuntu: https://forum.lazarus.freepascal.org/index.php/topic,51407.0.html.

About the crash during app-closing: label gets destroyed first (at least for me), so accessing it crashes. However this crash does not manifest always. ( It can be forced by -gh ).
Crashes during app-close are not always (visible) reported. On windows, I can see the crash outside the debugger, if I run with a console, as it is printed out. The app closes however before it can report it via gui.
IMHO it is "unfortunate" that the collapse/expand event is called during destroy, maybe that should be changed, but that is a diff topic.

[Sieben]

Thank for coming back on this issue. I created a log file now as suggested, started Lazarus with said parameters und it did me the favour of starting the project blank and dead on first try. App was then killed via Linux Task Manager, not Lazarus Halt (Ctrl+F2). File attached. Odd thing is still that projects that have been created earlier still run without problems, still no blank forms, no hanging.

As for crash on app closing I mentioned it mainly because trouble seems(!) to have started after this happened for the first time. But as I said this 'unfortunate' behaviour can be prevented by just adding if not Application.Terminated. Changing creation/destruction order seems not to be possible, and switching positions of objects in *.lfm also didn't help. It's not he only 'unfortunate' issue with TTreeView/TShellTreeView but that is indeed a different topic. The debug trouble seems to have no connection with them either. It also happens with the most simple projects with just a TButton on the form.