Description: I have a main form comprising a subform which is connected to a mysql database. The main form provides 4 controls pulling data from a first table : The main form also provides a subform which is a grid control connected using a SQL query to provide data from a second table. The subform and main form are linked via an ID field which is common to both tables (foreign key). I open the form in Form Design mode and select the grid control. As soon as I try to expand, or shrink, the size of the grid control with the mouse, I get an immediate crash. A crash trace is attached. This is a regression, as I could easily resize my grid control without hanging/force kill in a previous, older version of LO (but the exact version at which this behavior started remains to be identified). Steps to Reproduce: See description. Actual Results: Hangs indefinitely, requiring force kill of the soffice process. Expected Results: Should not hang/crash, and should allow the grid control to be resized. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.6.2.1 (AARCH64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 8; OS: Mac OS X 13.4; UI render: Skia/Raster; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded
Further information: The hang/crash does not occur when the dimensions of the control are changed via the Properties dialog of the grid control. The crash only occurs when dragging the handles of the grid control when selected.
Created attachment 190039 [details] Apple Crash Trace
Further testing reveals that the cause is Skia rendering related. Turning off "Use Skia for all rendering", allows the grid control to be resized. As Skia raster rendering is on by default in the 7.6.x releases, this is yet another example of why it wasn't a good idea to force Skia rendering to on...
I can reproduce the crash with a Firebird linked Form document containing just a grid control. Attached is a sample Form odt file, the database binding isn't particularly relevant, any attempt to change the size of the grid control via mouse leads to the crash.
Created attachment 190041 [details] Test form with grid control
Created attachment 190042 [details] Test embedded Firebird DB
(In reply to Alex Thurgood from comment #6) > Created attachment 190042 [details] > Test embedded Firebird DB The form in the attached Firebird DB has only a MainForm without any subform and there aren't any grid control in it. The *Test form with grid control* attachment is an independent form with a grid linked to a table, but also hasn't any subform and has only a grid in which I can't reproduce the bug. Could you please provide a better test examples according with you description in the steps to reproduce?
(In reply to jcsanz from comment #7) > > The form in the attached Firebird DB has only a MainForm without any subform > and there aren't any grid control in it. > Which is particularly strange, since, when I download the posted form document, and open it in LibreOffice, the enclosed screenshot shows that it contains a grid control. > The *Test form with grid control* attachment is an independent form with a > grid linked to a table, but also hasn't any subform and has only a grid in > which I can't reproduce the bug. > > Could you please provide a better test examples according with you > description in the steps to reproduce? The point is that I don't need a subform having a grid control to reproduce the problem, it is reproducible just having an independent ODT form document with a grid control in it.
Created attachment 190119 [details] Screenshot of downloaded form showing grid control
Steps to reproduce on macOS Sonoma 14.0 (23A344): 1) Download form document. 2) Open form document in Form Design Mode. 3) Select grid control with mouse. 4) Using any of the handles, try and drag extend, or drag reduce, the grid control with the mouse.
I can *not* reproduce it in Windows nor in Linux --------------------------- Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Jumbo --------------------------- Version: 7.3.7.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 2; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: es-ES (es_ES.UTF-8); UI: es-ES Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.3 Calc: threaded ---------------------------
The crash log shows the crash occurring while drawing a native button or other native control. As soon as I am able, I will build the libreoffice-7-6 branch and, if I can reproduce this bug, I will see if backporting the following patch has any effect: https://gerrit.libreoffice.org/c/core/+/157333
(In reply to Patrick Luby from comment #12) > The crash log shows the crash occurring while drawing a native button or > other native control. As soon as I am able, I will build the libreoffice-7-6 > branch and, if I can reproduce this bug, I will see if backporting the > following patch has any effect: > > https://gerrit.libreoffice.org/c/core/+/157333 That would be excellent news if it did!
It was an even simpler bug than I initially thought. It was a null Skia pointer so I added code to check the Skia pointer and initialize it if it is null. I have a patch that fixes this bug in the master branch. Once it passes the build tests, I will commit it and then backport to libreoffice-7-6 and libreoffice-7-5: https://gerrit.libreoffice.org/c/core/+/157848
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/82ed49b81eb0a45c25f3808a7d12efffffd5161a tdf#157613 make sure surface is not a null pointer It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/0224f024424c76a05e0c20b6ee1b4490fde11607 tdf#157613 make sure surface is not a null pointer It will be available in 7.6.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/e65162fcd7091ee315637301fcc1a3480325f918 tdf#157613 make sure surface is not a null pointer It will be available in 7.5.9. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-5-8": https://git.libreoffice.org/core/commit/3325b080e36afc2660c2f045842901ac7a781972 tdf#157613 make sure surface is not a null pointer It will be available in 7.5.8. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified Fixed in Version: 7.6.3.0.0+ (X86_64) / LibreOffice Community Build ID: 9395171aa8641341316f87e2537dcdfa3df4ef78 CPU threads: 8; OS: Mac OS X 14.0; UI render: Skia/Metal; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded Thanks Patrick ! I've noticed that you no longer get the dynamic arrowed outline of the control when dragging/resizing, so there is a loss of a visual aid here for positioning the control on the page. This would be a separate, but possibly linked, regression (a similar one was fixed a while back for another Form control, but I don't remember which one).
(In reply to Alex Thurgood from comment #19) > I've noticed that you no longer get the dynamic arrowed outline of the > control when dragging/resizing, so there is a loss of a visual aid here for > positioning the control on the page. > > This would be a separate, but possibly linked, regression (a similar one was > fixed a while back for another Form control, but I don't remember which one). FWIW, it works correctly in NeoOffice which is based on LibreOffice 4.4.7.2. But, in LibreOffice 7.5.7.1, it doesn't work with Skia enabled or disabled. I am guessing that the regression functionality was removed from the form code quite some time ago so maybe someone would be able to bibisect this regression?
*** Bug 158199 has been marked as a duplicate of this bug. ***