Is this a bug?

[scasparz]

Am Lazarus 3.6 on Linux Mint 21.1

Please consider the following simple code:

Code: Pascal  [Select][+][-]

1. procedure TFrmAppointments.FCmdRestoreClick(Sender: TObject);
2.  
3. VAR
4.   VLOC_OpenDialog          : tOpenDialog;
5.   VLOC_BackUpFileName      : tFileName;
6.  
7. begin
8.   FLog('TFrmAppointments.FCmdRestoreClick: entered');
9.  
10.   IF MessageDlg('my app', 'are you sure?', mtConfirmation, [mbYes, mbNo], 0) = mrYes THEN BEGIN  // Point (1)
11.     VLOC_OpenDialog := tOpenDialog.Create(NIL);
12.     VLOC_OpenDialog.DefaultExt := '.bdb'; //ATC_DefaultRescueExtension;
13.     VLOC_OpenDialog.InitialDir := '.'; // ATV_RootDirectory;
14.     // VLOC_OpenDialog.Options := [];
15.     VLOC_OpenDialog.Title := 'please select backup file';
16.  
17.     IF VLOC_OpenDialog.Execute THEN BEGIN // Point (2)
18.       VLOC_BackupFileName := VLOC_OpenDialog.FileName;
19.     ...
20.  

Code is supposed to use an OpenDialog instance to get a file name. Nothing really serious.
Problem is application terminates unexpectedly before Point (2) is executed. Have confirmed that every intermediate sentence setting the OpenDialog is executed. However dialog is not launched by VLOC_OpenDialog.Execute and no exception is raised. App simply dies.

A few things that puzzle me, from the inspection conducted:
1. If Point (1) elementary dialog is omitted, then Point (2) is executed without issues. Seems problem appears at Point (2) but that it is Point (1) related. Have replaced MessageDlg with other elementary dialogs, problem remained.
2. Instead of creating a local instance of a tOpenDialog, have placed a tOpenDialog component directly on the tFrmAppointments, problem remained.
3. Have tested removing intermediate statements between Point (1) and Point (2) with the exception of the VLOC_OpenDialog.Create one, no improvement.
4. If I set a debugger break point at Point (2), code executes well under the debugger! Some thirty years ago, I used to have a similar issue on an application I had been writing using Visual Basic, I could not solve in the end. Turned to Delphi after this.
5. Have ported app to Windows XP (on a virutal machine I have, with Lazarus 3.6 for Windows installed), code works well without changes! Apparently this is a Linux version issue.

Does this look like a bug of either Lazarus or FPC on Linux?



regards
s


 

[TRon]

4. If I set a debugger break point at Point (2), code executes well under the debugger! Some thirty years ago, I used to have a similar issue on an application I had been writing using Visual Basic, I could not solve in the end. Turned to Delphi after this.

That usually indicates that the IDE catches the exception (silently/ignored).

To verify run your application outside the IDE (preferably from a terminal in order to catch some output in case there is any).

[Fred vS]

Am Lazarus 3.6 on Linux Mint 21.1
Please consider the following simple code: <snip>

I cannot reproduce the error here on XUbuntu 24.04 + Lazarus 3.6 + fpc 3.2.2.
I used this code:

Code: Pascal  [Select][+][-]

1. procedure TForm1.Button1Click(Sender: TObject);
2. var
3.   VLOC_OpenDialog: tOpenDialog;
4.   VLOC_BackUpFileName: tFileName;
5. begin
6.   if MessageDlg('my app', 'are you sure?', mtConfirmation, [mbYes, mbNo], 0) = mrYes then
7.   begin  // Point (1)
8.     VLOC_OpenDialog := tOpenDialog.Create(nil);
9.     VLOC_OpenDialog.DefaultExt := '.bdb'; //ATC_DefaultRescueExtension;
10.     VLOC_OpenDialog.InitialDir := '.'; // ATV_RootDirectory;
11.     VLOC_OpenDialog.Title := 'please select backup file';
12.  
13.     if VLOC_OpenDialog.Execute then
14.     begin // Point (2)
15.       VLOC_BackupFileName := VLOC_OpenDialog.FileName;
16.     end;
17.  
18.     VLOC_OpenDialog.Free;
19.   end;
20. end;    

   

But maybe I miss something.

[scasparz]

Many thanks to both for your help.

Running app from the command prompt I took the following error message:

The program 'project1' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 19264 error_code 3 request_code 12 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Running app from the terminal with the --sync option, on the first run app behaviour was not changed, app died as usual.
However running app again with --sync option for the second time, app run without issues, was able to launch the OpenDialog and select the file required. Success?. No messages on the command prompt.


regards
s

[Fred vS]

However running app again with --sync option for the second time, app run without issues, was able to launch the OpenDialog and select the file required. Success?. No messages on the command prompt.

Good news.
Maybe try adding a application.processmessages... 

Code: Pascal  [Select][+][-]

1.   ...
2.    application.processmessages;  // Add this
3.    sleep(10); // And maybe this too
4.     if VLOC_OpenDialog.Execute then
5.     begin // Point (2)
6.  ...

[scasparz]

I did mate, but it did not work. Was among the countless attempts I made before the first post here. Had not been just the five of them I have listed on.

Thanks again guys.
s

[ccrause]

Many thanks to both for your help.

Running app from the command prompt I took the following error message:

The program 'project1' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 19264 error_code 3 request_code 12 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Running app from the terminal with the --sync option, on the first run app behaviour was not changed, app died as usual.
However running app again with --sync option for the second time, app run without issues, was able to launch the OpenDialog and select the file required. Success?. No messages on the command prompt.

Possibly related - I get infrequent crashes of Lazarus 4RC1 on Linux Mint  21.3 Mate with a somewhat similar error.  Perhaps the problem is specific to the X system configuration of Mint?

[scasparz]

I do not know.

FYI have tested app on Linux MX, a Debian fork with XFCE. Unlike lm21.1 no Mint, no Ubuntu. Problem persisted.
Then again I could cope by running app with the --sync clause.

The only difference has been that on lm21.1, app would execute well on the second run (it terminated on the first run, even with --sync). On MX would execute well (with --sync of course) on the first run. A minor improvement. Seems Mars is retrograding in my sign.

Actually solution found is not a solution, more likely its a patch. Will keep developing app in the hope in the end problem will take care of itself as I add new code. Not promising however.


s

[TRon]

Perhaps the problem is specific to the X system configuration of Mint?

Please correct me when wrong but isn't that running wayland ? That might explain some of the weirdness happening.

[ccrause]

Perhaps the problem is specific to the X system configuration of Mint?

Please correct me when wrong but isn't that running wayland ? That might explain some of the weirdness happening.

You may very well be correct.

[TRon]

You may very well be correct.

In case you both are using wayland with gtk you could try changing the widgetset to either gtk3 or qt and see if that yields better results. Wayland is far from finished (despite some who firm believe/tell otherwise) and it shows especially with gtk(2). For example raspios recently changed to another window manager because they know but that is also very unstable (and makes even Lazarus and Lazarus produced applications crash on a regular base because of incompatibilities).

It will eventually settle but till that time you really can't rely on anything. To make matters worse every distro seems to address things differently and that is difficult for a project such as Lazarus to deal with (although the Lazarus developers do try their best).

[Fred vS]

Perhaps the problem is specific to the X system configuration of Mint?

Please correct me when wrong but isn't that running wayland ? That might explain some of the weirdness happening.

Wayland still doesn't (ever?) work well but OP said:

FYI have tested app on Linux MX, a Debian fork with XFCE. Unlike lm21.1 no Mint, no Ubuntu. Problem persisted.

And those distros still use Xorg.

Strange that I cannot reproduce the error on my PC.
What machine do you use and what memory do you have? I have a i5 + 16 gigas ram.

[TRon]

You are right fred, thank you for noticing. I overlooked that part of the message.

I am also unable to recreate the issue with any linux desktop that I've tested which is /not/ using wayland. That said, there are so many combinations and configurations possible that this doesn't really mean anything.

Because changes were made wrt similar issue since the release of 3.6 I am leaning towards advising to try Lazarus 4.0RC2 (or even RC1) in order to verify if the issue persists. If it does perhaps even test trunk. If things do not get better then it would be advisable to create a bug-report. I suspect it might be addressed because in case not we should have seen a lot of other reports (unless the XFCE setup mentioned is so unique that nobody else uses it). fwiw: I have tested XFCE just not with MX linux and that worked ok for me.

[scasparz]

Guys am not using wayland. Not advised on lm21.1

$ echo $XDG_SESSION_TYPE
x11

This seems an X issue to me.

Point is whether this should be reported as a bug, and if so how on earth should it be done (never filed a bug before). Is there some documentation available?


s

[TRon]

Guys am not using wayland. Not advised on lm21.1

How are we suppose to know from your first post ? Default edition cinnamon comes shipped with Wayland.

Besides that, beating a dead horse as I already admitted to have mis-read that you verified on linux MX with XFCE (but also note that there is a KDE version).

Point is whether this should be reported as a bug, and if so how on earth should it be done (never filed a bug before). Is there some documentation available?

Point is, have you verified with Lazarus 4.0 RC2 and trunk ? As I already wrote there where some changes that might impact the issue you mentioned.