Is this a bug? lazarus / 66-Unix ---------------------------------------------------------------------- scasparz · 2025-01-09 19:56 Am Lazarus 3.6 on Linux Mint 21.1 Please consider the following simple code: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i procedure TFrmAppointments.FCmdRestoreClick(Sender: TObject); VAR  VLOC_OpenDialog          : tOpenDialog;  VLOC_BackUpFileName      : tFileName; begin  FLog('TFrmAppointments.FCmdRestoreClick: entered');   IF MessageDlg('my app', 'are you sure?', mtConfirmation, [mbYes, mbNo], 0) = mrYes THEN BEGIN  // Point (1)    VLOC_OpenDialog := tOpenDialog.Create(NIL);    VLOC_OpenDialog.DefaultExt := '.bdb'; //ATC_DefaultRescueExtension;    VLOC_OpenDialog.InitialDir := '.'; // ATV_RootDirectory;    // VLOC_OpenDialog.Options := [];     VLOC_OpenDialog.Title := 'please select backup file';     IF VLOC_OpenDialog.Execute THEN BEGIN // Point (2)      VLOC_BackupFileName := VLOC_OpenDialog.FileName;    ...  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 · 2025-01-09 20:18 Quote from: scasparz on January 09, 2025, 08:56:12 pm4. 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 · 2025-01-09 21:08 Quote from: scasparz on January 09, 2025, 08:56:12 pmAm Lazarus 3.6 on Linux Mint 21.1 Please consider the following simple code: I cannot reproduce the error here on XUbuntu 24.04 + Lazarus 3.6 + fpc 3.2.2. I used this code: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i procedure TForm1.Button1Click(Sender: TObject);var  VLOC_OpenDialog: tOpenDialog;  VLOC_BackUpFileName: tFileName;begin  if MessageDlg('my app', 'are you sure?', mtConfirmation, [mbYes, mbNo], 0) = mrYes then  begin  // Point (1)    VLOC_OpenDialog := tOpenDialog.Create(nil);    VLOC_OpenDialog.DefaultExt := '.bdb'; //ATC_DefaultRescueExtension;  VLOC_OpenDialog.InitialDir := '.'; // ATV_RootDirectory;    VLOC_OpenDialog.Title := 'please select backup file';     if VLOC_OpenDialog.Execute then    begin // Point (2)      VLOC_BackupFileName := VLOC_OpenDialog.FileName;    end;     VLOC_OpenDialog.Free;  end;end;      But maybe I miss something. ---------------------------------------------------------------------- scasparz · 2025-01-10 02:14 Many thanks to both for your help. Running app from the command prompt I took the following error message: QuoteThe 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 · 2025-01-10 03:05 Quote from: scasparz on January 10, 2025, 03:14:50 amHowever 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i   ...   application.processmessages;  // Add this   sleep(10); // And maybe this too    if VLOC_OpenDialog.Execute then    begin // Point (2) ... ---------------------------------------------------------------------- scasparz · 2025-01-10 03:23 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 · 2025-01-10 05:59 Quote from: scasparz on January 10, 2025, 03:14:50 amMany thanks to both for your help. Running app from the command prompt I took the following error message: QuoteThe 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 · 2025-01-10 10:58 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 · 2025-01-10 11:38 Quote from: ccrause on January 10, 2025, 06:59:08 amPerhaps 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 · 2025-01-10 12:55 Quote from: TRon on January 10, 2025, 12:38:02 pmQuote from: ccrause on January 10, 2025, 06:59:08 amPerhaps 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 · 2025-01-10 14:31 Quote from: ccrause on January 10, 2025, 01:55:02 pmYou 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 · 2025-01-10 15:40 Quote from: TRon on January 10, 2025, 12:38:02 pmQuote from: ccrause on January 10, 2025, 06:59:08 amPerhaps 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: QuoteFYI 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 · 2025-01-10 16:01 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 · 2025-01-10 18:33 Guys am not using wayland. Not advised on lm21.1 Quote$ 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 · 2025-01-10 19:03 Quote from: scasparz on January 10, 2025, 07:33:59 pmGuys 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). QuotePoint 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. ---------------------------------------------------------------------- Fred vS · 2025-01-10 19:39 Quote from: scasparz on January 10, 2025, 07:33:59 pmPoint is whether this should be reported as a bug, The first point would be to provide a short demo program that shows the problem. The code you gave in the first post does not help, we cannot reproduce the error. ---------------------------------------------------------------------- scasparz · 2025-01-10 23:56 Respectfully let me disagree. A short demo will be unable to replicate the problem. Will upload the entire app, besides it is not that big anyway. A few things you should know: compiled by Laz 4.0 RC2 project runs without issues on every linux platform I have it tested. Good news. standard laz directories backup and lib have been erased due to forum size restrictions. Expect Laz will have them recreated.the backup file that has to be restored is located into the guard subdirectory named appointments.bdb. It is a known bug app does not ensure this is an sqlite3 backup database. Am working on that.critical point is line 1853 in unit USZEdAppointmentssimply extract directory 08. final and go, AFAIK no need to modify anythingif needed, can provide both executables (Laz 3.6 & Laz 4) on chunks of 500kb each, stripped s ---------------------------------------------------------------------- Fred vS · 2025-01-11 00:16 Quote from: scasparz on January 11, 2025, 12:56:41 amcompiled by Laz 4.0 RC2 project runs without issues on every linux platform I have it tested. Good news. Yep!  I did test your zip demo here on  on XUbuntu 24.04 + Lazarus 3.6 + fpc 3.2.2. It was out-of-the-box, without error. See video: https://github.com/user- attachments/assets/ab197d61-1e0b-46f6-bd60-7f79dfc9e900 Anyway, I am happy it works for you too now. Fre;D ---------------------------------------------------------------------- scasparz · 2025-01-11 00:38 Thanks for trying and for the video. Have watched it. However the problem has not been in backing database but in restoring the backup. Backing db has always been working well. Will be surprised if restoring will work, been compiled by Laz 3.6. Then maybe you should give it another run. s ---------------------------------------------------------------------- Fred vS · 2025-01-11 00:54 Quote from: scasparz on January 11, 2025, 01:38:52 amHowever the problem has not been in backing database but in restoring the backup. Ooops, indeed, there is a problem there.  https://github.com/user- attachments/assets/4ff1ad43-6b89-4db9-b127-5376b48e1271 ---------------------------------------------------------------------- Fred vS · 2025-01-11 02:02 Allez, the last for tonight. @scasparz: about this post: https://forum.lazarus.freepascal.org/index.php/topic,69823.msg543088.h tml#msg543088 Did you really try it? Here, with this code it works ok: https://github.com/user- attachments/assets/82864dc4-f8d1-464c-a83a-f188eafab509 Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  IF MessageDlg(BL_DialogCaption, 'you will lose all current appointments, are you sure?', mtConfirmation, [mbYes, mbNo], 0) = mrYes THEN BEGIN  application.ProcessMessages; sleep(100);     VLOC_OpenDialog := tOpenDialog.Create(NIL); ---------------------------------------------------------------------- scasparz · 2025-01-11 07:26 Have tried ProcessMessages with Form.Refresh. Did not use Sleep though. Looks Sleep made the difference. Still IMHO Laz 4.0 RC2 seems a better approach. s ---------------------------------------------------------------------- Fred vS · 2025-01-11 11:09 Quote from: scasparz on January 11, 2025, 08:26:52 amHave tried ProcessMessages with Form.Refresh. Did not use Sleep though. Looks Sleep made the difference. Still IMHO Laz 4.0 RC2 seems a better approach. s You are the boss (but I would add it, even using Laz 4.0, for security...). ---------------------------------------------------------------------- scasparz · 2025-01-11 15:27 This is a jolly good idea. s ---------------------------------------------------------------------- Fred vS · 2025-01-11 16:24 Quote from: scasparz on January 11, 2025, 04:27:34 pmThis is a jolly good idea. In fact the problem is the conflict between 2  modal forms: MessageDlg vs VLOC_OpenDialog. In your code, there is a creation of a modal form by a modal form. It could be that in some case, the modal-MessageDlg-form is not yet completely freed before creating/show modal-VLOC_OpenDialog-form. (Your code show one of this case but I did not understand what it is, in my simple test code it works) To resume better give time to the system to completely finish his work. My 0.001 cent, of course.