I installed Lazarus 2.0.6 a few hours ago into a fully updated Raspbian Buster on an RPi4B 4GB system. Interfacing to it using RealVNC to my Windows7 laptop.

I opened the current project and checked that it would build etc. No problems.

Then I started write a section of description comments at the top of a source file and when I was almost done and clicked in the editor window a few lines down to move the cursor, Lazarus suddenly just unloaded on me!!!
Desktop still there and all seemingly working OK except Lazarus had disappeared.

All edits lost when I restarted Lazarus. :-(

I have never before encountered a crash like this, could it be because the IDE is so "fresh out of the presses"?

Good question "why". That can't be answered easily. And the issue could be new or old.

Unfortunately more info would be needed. So it depends how reproducible the issue is.
It could easily be something related to RP (and then may happen again).  Or Gtk (2 or 3 ?).

Is there a core file? If yes, try to get a trace with gdb.

If it can be reproduced, try getting a stacktrace. If the IDE is build with debug info, and run from console (or with --debug-log=file) then it will in most cases print a trace of the crash.
If it does not print a trace, then running the IDE (still with debug info) under gdb can help.

Well and a "autosave" feature might be nice, but needs to be written...

Martin Frb wrote

Well and a "autosave" feature might be nice, but needs to be written...

The project is always automatically saved when you compile it.

Ondrej

Yes, I know that and it works fine.

But this happened while I was busy writing a description of the application data file usage and where what goes where. I put this into the comment section I always have at the top of the file (below the unit name line).
Luckily I did not have any actual code changes at the time so only my comments were lost and had to be re-created.
It was my first code editing after installing the needed packages into Lazarus 2.0.6

Now it happened again!
I was compiling the program then executing it inside a terminal (external to Lazarus) and then repeating this to find my bug.

When I found it I doubleclicked the name of my logging component to copy its name, but instead instanly Lazarus disappeared!

I will now revert back to Lazarus 2.0.4 instead.

It would be really helpful if you could try to get a trace. (see my last reply)
Otherwise this issue may be present for a lot of future versions.

I've been away from this for a while doing circuit board design for the RPi plug-in card I will need for the functionality of my project. Now back to coding and I am doing it on the target system since it is not possible for me to cross-compile for RPi on my Windows system. I never managed to understand how to make it work....

So I am on a VNC connection using RealVNC on my Win7 laptop towards the RPi4 system running a fully updated Raspbian Buster.

And I have been bitten several times the last days by the suddenly disappearing Lazarus application....

So I switched to Lazarus 2.0.4 in order to use that instead of the 2.0.6 I thought was the culprit.
Turns out I was wrong! I get these crashes also on 2.0.4...

So now I need to get into a situation where I can safely develop the code on my Windows 7 machine instead (there I have NEVER seen this happen). It is no fun when code worked on for an hour suddenly just disappears.

But there are several places in the code where Linux specific constructs are used, for example I use the PiGpio unit which is RPi specific and I have no way to redirect that to the Windows environment. On test compilations I get a large number of errors relating to unix etc.

So is there some way I can enable cross-compiling for Linux (i.e. Raspbian on RPi4) on my Windows7 installation?

Unlike on Raspbian I have not built fpc/lazarus from sources but rather used the official installer found here:
https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2064%20bits/Lazarus%202.0.4/

There is also a cross-compiler on that page but probably not what I need since it only mentions the Intel architecture...

Bo Berglund wrote

And I have been bitten several times the last days by the suddenly disappearing Lazarus application....

If you can.... Run your Lazarus in gdb.
   gdb path/to/lazarus

and then in gdb hit r and return.

I know you want to get away from more crashes. And this will mean at least one more of them.

It is highly likely that gdb will report some sort of sigsegv or the like. And then allow for a backtrace to be made.
Of course that assumes, that your lazarus is compiled with debug info.

You can also look into your home dir (or where you start lazarus from), or maybe the lazarus dir, or ~/.lazarus.
Maybe there is a lazarus.core file. Then you already have what you need. Or well, only if it has debug info.
   gdb path/to/lazarus path/to/lazarus.core
  bt
according to
https://stackoverflow.com/questions/5115613/core-dump-file-analysis

I always start lazarus in the GUI using the menu command. During installation I create a version dependent .lazarus_2.0.x dir so I can use different versions on the same system. So the command to start lazarus in the desktop file is:

Exec=/home/pi/dev/lazarus/2.0.6/startlazarus
--pcp=/home/pi/.lazarus_2.0.6 %f

What should I do in order to make this work through gdb?

I believe it has because:
- I have not stripped lazarus or startlazarus after ide rebuilds
- The size of lazarus is 260,249,068 bytes
- The size of startlazarus is 29,995,584 bytes

You can also look into your home dir (or where you start lazarus from), or maybe the lazarus dir, or ~/.lazarus. Maybe there is a lazarus.core file. Then you already have what you need.

pi at rpi4-gui:~ $ sudo find ./ -name *.core
pi at rpi4-gui:~ $

So at least below home there is no such file...

El 24/11/19 a les 10:22, Bo Berglund via lazarus ha escrit:

gdb /home/pi/dev/lazarus/2.0.6/lazarus
r --pcp=/home/pi/.lazarus_2.0.6

I don't know much about gdb (I always use it through the ide) but "man gdb" would have told you that (r is an abbreviation for run):

"
Here are some of the most frequently needed GDB commands:

break [file:]function
Set a breakpoint at function (in file).

---> run [arglist]
Start your program (with arglist, if specified).

bt Backtrace: display the program stack.
"

Bye

gdb path/to/lazarus
r  --pcp=/home/pi/.lazarus_2.0.6

path/to would be either
- if writeable: /home/pi/dev/lazarus/2.0.6/
- otherwise /home/user/.lazarus_2.0.6/
(startlazarus is only needed for: restart and if your laz-install dir is write-protected (admin install for all users). In the latter case the rebuild IDE goes into the config path, so each user can have its own rebuild.)

The %f is missing, so you cant double click the file. But you need to run gdb from a terminal (so you can execute bt later), so you need to open the file once the IDE runs.

Check the size of the lazarus executable. It should be over 100MB (probably over 200). If not you first need to recompile the IDE with debug settings.
Menu Tools > Configure build lazarus
in the "options" memo enter: -gw
and check "clean all" radio button.

I believe it has because: - I have not stripped lazarus or startlazarus after ide rebuilds - The size of lazarus is 260,249,068 bytes

Yes that look good

Bo Berglund wrote

Exec=/home/pi/dev/lazarus/2.0.6/startlazarus --pcp=/home/pi/.lazarus_2.0.6 %f

Off topic, if you use this as a single user system, you can put the pcp into a file called lazarus.cfg
https://wiki.lazarus.freepascal.org/Multiple_Lazarus#Using_lazarus.cfg_file

I tried but....
pi at rpi4-gui:~ $ gdb /home/pi/dev/lazarus/2.0.6/lazarus r --pcp=/home/pi/.lazarus_2.0.6
gdb: unrecognized option '--pcp=/home/pi/.lazarus_2.0.6' Use `gdb --help' for a complete list of options.

So now the --pcp... argument to lazarus becomes an argument to gdb???

(startlazarus is only needed for: restart and if your laz-install dir is write-protected (admin install for all users). In the latter case the rebuild IDE goes into the config path, so each user can have its own rebuild.)

Does this mean that I should change the Exec in the desktop file should be changed from startlazarus to simply lazarus?

The %f is missing, so you cant double click the file. But you need to run gdb from a terminal (so you can execute bt later), so you need to open the file once the IDE runs.

Normally the previously open project is loaded as soon as the Lazarus IDE runs, is this not going to happen now (provided one can get rid of the error message above)? I assume you mean open the project?

the "r --pcp=/home/pi/.lazarus_2.0.6" is only entered once gdb runs.

Gdb has an interactive console interface of its own. Enter (in a terminal) "gdb /home/pi/dev/lazarus/2.0.6/lazarus " and you get a "(gdb)" prompt.
At this prompt you do enter the "r..."

In this case you can.
The entire lazarus is in your home directory. So
- no one else is using it, and if they were they would use your build, and your config (rather than one install for many users, with a diff config for each user (and diff installed packages)
- the directory is (I assume) writeable to the IDE, when it rebuilds. (I.e. the IDE runs as the user, who has write access).   Therefore the IDE should (for all I know) place its new build into this dir.

I generally do the same, and always start lazarus, never startlazarus. (the latter is still be called, if I restart the IDE from the menu)

-----
*nix is multi user. So the root user could install a lazarus accessible to all users. But users could not write to this directory. Each user then has its config in their home dir. And if they install a package it affects only the one user. The rebuild (which anyway can not be written to the main dir by this user) will then be placed in the personal config dir.
Calling startlazarus in the main install dir, startlazarus will find the pcp, and check for a newer lazarus. If none found, it uses the lazarus from the install dir.

-------
If your install is for one user only, you can put the --pcp argument into the lazarus.cfg file (in the main install dir). This does not support multiple configs for multiple users.
But if you have several installs in your home folder, then each of them can have such a lazarus.cfg file.
The advantage is, that the config path will be found, even if you start lazarus or startlazarus (from that install folder in your home) without specifying an pcp argument.

All my installs have that, and I just open the folder and click the lazarus executable

On Sun, 24 Nov 2019 18:27:40 +0100, Bo Berglund via lazarus

After reading the gdb --help screen:

pi at rpi4-gui:~ $ gdb --args /home/pi/dev/lazarus/2.0.6/lazarus --pcp=/home/pi/.lazarus_2.0.6
GNU gdb (Raspbian 8.2.1-2) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details. For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"... Reading symbols from /home/pi/dev/lazarus/2.0.6/lazarus...done. (gdb) quit
pi at rpi4-gui:~ $

--args needed to send the last arguments to the application Still Lazarus does not show up on screen...

Bo Berglund wrote

After reading the gdb --help screen: pi at rpi4-gui:~ $ gdb --args /home/pi/dev/lazarus/2.0.6/lazarus

No --args

In the terminal enter

gdb /home/pi/dev/lazarus/2.0.6/lazarus

then wait for the gdb output. It will end with a "(gdb)" prompt. Now enter

r --pcp=/home/pi/.lazarus_2.0.6

Then when the IDE encounters the issue that closes it, the IDE will probably freeze. (paused by gdb)
Gdb will probably print something about SigSegv (or similar), and gdb will show a prompt again.
At that prompt, you can now type
bt

and gdb will print the stack for the issue.

OK, This worked!
Now I have a Lazarus IDE running after starting via gdb. Lets see how long it will take before the next crash...

I really do want to work via VNC because then I can use my Win7 PC for researching stuff and copy code into Lazarus when done. If I run directly from the RPi hardware I cannot do that..

Bo Berglund wrote

OK, This worked! Now I have a Lazarus IDE running after starting via gdb. Lets see how long it will take before the next crash...

So it has been running fine now for 72 hours while I have coded a lot. No crashes that plagued me last week. :)

Two possibilities:
1) GDB itself makes the Lazarus application behave better?
2) Not using startlazarus when starting lazarus?

I did use the lazarus program for gdb and not startlazarus...

If it is the second item then I could well create another desktop file that starts lazarus directly instead of using startlazarus in the exec command in the desktop file.

OTOH, if I want to add a package to Lazarus it is my understanding that it needs startlazarus in order to recompile itself properly. So is that only possible if I have started lazarus by startlazarus or will it be able to do the same also if it runs from lazarus only?

Note that here I am talking about running in Linux (Raspbian) and NOT on Windows...

It can be started either way.
The restart uses startlazarus.
Of course you can just close and start it manually as well.

Note that here I am talking about running in Linux (Raspbian) and NOT on Windows...

Mattias

Yes, it is important to use "lazarus" not "startlazarus" in gdb. gdb only debugs the program it started. By default it will not do anything to sub  processes. That also means restarting the IDE will stop it from being debugged.

gdb should not have much effect. So there a slight changes in timing (eg when libraries are loaded). This could change race-conditions.

It could be something different in the remote connection....

There could be a bug in startlazarus, and maybe it started an old/buggy lazarus from some other place... (not sure, but....)

Or it could be, that when launching in GDB (and with that in a terminal) there is a console.
That means, if someone put an unprotected "writeln" somewhere in the IDE code, it could write to console. Otherwise stdout would be a closed handle.

You could try running lazarus, without gdb, but with output redirection to a file.
Lazarus has some logging that checks for an open console. So there will be content in that file, that does not confirm anything about a rogue writeln. But if there were no crash, it could be a hint.

you could try

lazarus --debug-log=/home/NAME/good-log.txt  > /home/NAME/bad-log.txt

The first part redirects any proper logging. So anything that goes into the 2nd file, would need to be checked.

So I shut down the gdb session and edited the desktop file to not use startlazarus, but lazarus directly.

Then started Lazarus IDE and continued writing code. Seemed to work fine until just a couple of minutes ago when the crash happened again. So it was not the fact I was using startlazarus that made it vulnerable...
The crash happened as I doubleclicked an identifier in the code in order to replace the name with the clipboard content.

I will now go back to starting lazarus with gdb again like I did before so I can get a longer crash-free session.

I also wonder exactly what you meant for me to do above concerning the debug-log?
Do you mean for me to use that command inside gdb to start lazarus? In that case I also need to set the --pcp option, right?

Or did you mean it as an alternative test to what I tried just before with a *regular* start but with lazarus rather than startlazarus?

I.e. in terminal:
/home/pi/dev/lazarus/2.6.0/lazarus --pcp=/home/pi/.lazarus_2.0.6 --debug-log=/home/pi/log/good-log.txt  > /home/pi/log/bad-log.txt

I am now running via gdb again exactly as I did before the test without gdb.

As an alternative test, with a command line as you wrote above.

Background (not sure if it applies on all OS....):
- If you start a GUI app from your desktop it usually has no stdout/stdin. Those handles are closed.
- If you use write/read on such a closed handle, then that usually leads to a crash.
- Most code in Lazarus uses the debug logger, which only writes to stdout if it is open

When you start from gdb, gdb has stdin/out => and lazarus inherits those handles. "write" will therefore be fine.

In the above "--debug-log" you redirect all the safe output to one file (which you can periodically clean), and leave any other "writeln" output to go to the other file.

If you check "bad-log" for any content, then we will know if (and even what) was written in a maybe un-safe way (the code could still be governed by appropriate checks, but that could be verified). Also knowing where such text is written, it could be asserted if it might be related to mouse clicks (or other actions)  in the source editor.

Of course this is just a guess. But it may be worth following it through.

The only odd part is, that if there was such a writeln, I would expect a lot more people having problems.... But one never knows. Maybe something particular in your code causes this "write". Or a package added to the IDE....

Martin Frb wrote

The only odd part is, that if there was such a writeln, I would expect a lot more people having problems.... But one never knows. Maybe something particular in your code causes this "write". Or a package added to the IDE....

Well, my code does not really get involved in this because it is just a bunch of text files the IDE is showing for editing, right? Because the crash happens when I am editing and typically when I click on something in the editor window.

I never ever run my code in the IDE, I just compile and then I run it from a command window.

Concerning packages I have added a few to the IDE (and rebuilt it afterwards):
Indylaz, UniqueInstance (via OLPM) and PasLibVlc (for video editing) via a package file I downloaded.

But the editor has stuff like codetools and highlighters, and those parse your code. So they behave according to what they find.