Description: LibreOffice crashes when attempting to create an auto-id of type BigInt in LibreOffice. The database file cannot be launched again after the crash, resulting in LO repeating attempting (and failing) to launch. LO is left in memory, meaning the file cannot be deleted, but there's no entry in Task Manager to kill. Hard reboot required. Steps to Reproduce: 1. Launch LO 2. Select Base Database, bringing up the Database Wizard 3. Select Create a new Database (HSQLDB is the only option) 4. Hit Next. 5. Leave all defaults on the "Decide How to Proceed" wizard page 6. Hit Next, bringing up the Save As dialog box 7. Name the database and click Save, bringing up the tasks window in Base 8. Click Create Table In Design View, bring up a new table design grid 9. Under Field Name, type AutoID 10 Under Field Type, select BigInt[BIGINT] 11.Under Field properties at the bottom of the window, set AutoValue to Yes 12. Click to the next row in the database table Actual Results: LibreOffice will immediately freeze or crash. If it freezes, you'll get a Windows spinning timer and be forced to close LO manually via task manager. Expected Results: Should do one of the following: 1. Allow the user to continue to the next row and continue working 2. Warn the user not to select BigInt as an autovalue type (and prevent it) 3. Fail more gracefully than it did here. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.0.0.alpha0+ (x64) Build ID: 561e5559bb68242c7f785f0ca3bee3eb12b58963 CPU threads: 8; OS: Windows 10.0 Build 20270; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Also failed exactly the same way when attempting to set the autovalue property to Yes for: Number [NUMERIC] Integer [INTEGER] I gave up at that point to know what other type to set for an auto value.
On pc Debian x86-64 with master sources updated today, I don't reproduce this. (Windows only bug?) Could you indicate what Java version do you have? (vendor, JRE or JDK, 32 or 64 bits) Could you also give a try at https://wiki.documentfoundation.org/QA/FirstSteps ?
(In reply to Julien Nabet from comment #2) > On pc Debian x86-64 with master sources updated today, I don't reproduce > this. > (Windows only bug?) > > Could you indicate what Java version do you have? (vendor, JRE or JDK, 32 or > 64 bits) > Could you also give a try at > https://wiki.documentfoundation.org/QA/FirstSteps ? Often times when I clearly indicate that I find a bug in Windows, someone comes along and says that they cannot reproduce the bug in Linux. This is typical. Many of the bugs I come across, especially in Draw, are Windows-specific, and I must ask people to test for the reported bug in the environment in which the bug was first identified. I'm using Java jre1.8.0_271 64-bit, and I checked for updates, there were none.
Still occurring in today's build Version: 7.2.0.0.alpha0+ (x64) Build ID: ecb916667b633f8647790e040226b093760e6cfe CPU threads: 8; OS: Windows 10.0 Build 20270; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
I re-tested without setting the auto-value to Yes and was able to flip between rows in the table creation window. Soon as I went back and set a variable to auto-value, LO hangs as described above.
(In reply to mwtjunkmail from comment #5) > I re-tested without setting the auto-value to Yes and was able to flip > between rows in the table creation window. Soon as I went back and set a > variable to auto-value, LO hangs as described above. Still happening in Version: 7.2.0.0.alpha0+ (x64) Build ID: e97a81e94511b52987a50b7bdb72c922899da588 CPU threads: 8; OS: Windows 10.0 Build 21277; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
No problem with this buggy behavior in LO 7.0.4.2. Also no problem with LO 7.1.0.0beta1 on OpenSUSE 15.1 64bit rpm Linux. Autovalue with BigInt works.
(In reply to Robert Großkopf from comment #7) > No problem with this buggy behavior in LO 7.0.4.2. Also no problem with LO > 7.1.0.0beta1 on OpenSUSE 15.1 64bit rpm Linux. Autovalue with BigInt works. You're the second person on this bug to test on Linux when I reported the problem in Windows. I'm not surprised you didn't find the bug on Linux. Do you have any way to test on Windows?
(In reply to mwtjunkmail from comment #8) > (In reply to Robert Großkopf from comment #7) > > No problem with this buggy behavior in LO 7.0.4.2. Also no problem with LO > > 7.1.0.0beta1 on OpenSUSE 15.1 64bit rpm Linux. Autovalue with BigInt works. > > You're the second person on this bug to test on Linux when I reported the > problem in Windows. I'm not surprised you didn't find the bug on Linux. > > Do you have any way to test on Windows? and using the latest 7.2.xx daily build?
(In reply to mwtjunkmail from comment #8) > (In reply to Robert Großkopf from comment #7) > > No problem with this buggy behavior in LO 7.0.4.2. Also no problem with LO > > 7.1.0.0beta1 on OpenSUSE 15.1 64bit rpm Linux. Autovalue with BigInt works. > > You're the second person on this bug to test on Linux when I reported the > problem in Windows. I'm not surprised you didn't find the bug on Linux. > > Do you have any way to test on Windows? No, there is no way for me to test it in Windows. If you report a bug: Do you know it is only Windows-specific? If you have tested it with different Linux-versions and MAC also write it down here. We are looking if this is a special Windows bug. And we could only test the same under different Linux-versions (Julien on *.deb and me on *.rpm). After this tests (I have downloaded the daily build from 2020-12-19 and tested again) it seems to be a bug, which doesn't appear in Linux. The database you are using is the same as it has been used under all LO-versions. So I don't think it is a special bug of LO 7.2.*. Could be a bug together with JRE.
(In reply to Robert Großkopf from comment #10) > (In reply to mwtjunkmail from comment #8) > > (In reply to Robert Großkopf from comment #7) > > > No problem with this buggy behavior in LO 7.0.4.2. Also no problem with LO > > > 7.1.0.0beta1 on OpenSUSE 15.1 64bit rpm Linux. Autovalue with BigInt works. > > > > You're the second person on this bug to test on Linux when I reported the > > problem in Windows. I'm not surprised you didn't find the bug on Linux. > > > > Do you have any way to test on Windows? > > No, there is no way for me to test it in Windows. > > If you report a bug: Do you know it is only Windows-specific? If you have > tested it with different Linux-versions and MAC also write it down here. We > are looking if this is a special Windows bug. And we could only test the > same under different Linux-versions (Julien on *.deb and me on *.rpm). After > this tests (I have downloaded the daily build from 2020-12-19 and tested > again) it seems to be a bug, which doesn't appear in Linux. > > The database you are using is the same as it has been used under all > LO-versions. So I don't think it is a special bug of LO 7.2.*. Could be a > bug together with JRE. I always identify that I found the bug in Windows. It would make the most natural sense for testers to start there. And I have the latest JRE for Windows.
? If you have > tested it with different Linux-versions and MAC also write it down here. I'm not a tester set up with multiple environments to test. I'm a Windows 10 end user encountering issues, and I report them.
Still occurs under a new user profile when rendering is set to hardware only.
Created attachment 168363 [details] screen cap I'm able to create an autoID (I used BigInt) and save the table. Upon clicking the next row down, Windows LO crashes and I must use Task Manager to kill the process. Version: 7.2.0.0.alpha0+ (x64) Build ID: 315c7570c4a72f4c834086082825533b1e50d1bf CPU threads: 8; OS: Windows 10.0 Build 21277; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
@mwtjunkmail : is there a difference in behaviour if you turn off Skia/Vulkan rendering ? There are a few instances of where this has caused crashing bugs in Windows versions of LO. Unfortunately, whilst there are probably a fair number of Windows Base users out there, there aren't many that do testing / QA / bug reporting. I'm afraid I can't help you there, as I'm on Mac, but the Skia/Vulkan thing might be one direction to try.
(In reply to Alex Thurgood from comment #15) > @mwtjunkmail : > > is there a difference in behaviour if you turn off Skia/Vulkan rendering ? > > There are a few instances of where this has caused crashing bugs in Windows > versions of LO. > > Unfortunately, whilst there are probably a fair number of Windows Base users > out there, there aren't many that do testing / QA / bug reporting. I'm > afraid I can't help you there, as I'm on Mac, but the Skia/Vulkan thing > might be one direction to try. See comment #13.
The crash occurs when clicking between rows of a table during design view, regardless of the row's content.
still happening in Version: 7.2.0.0.alpha0+ (x64) Build ID: 8e691505d4675b878b30bd00cd2e4fb4f794f0ef CPU threads: 8; OS: Windows 10.0 Build 21277; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
Confirm Version: 7.2.0.0.alpha0+ (x64) Build ID: 4e3ce9dd6ace0b22f7b3f45cf2338b201f4dc305 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Still fine with Version: 7.0.0.0.beta1+ (x64) Build ID: 2891e91a513520d68ea2b8c59c14335861a15253 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Created attachment 168724 [details] Bibisect log Bisected to: author Caolán McNamara <caolanm@redhat.com> 2020-08-28 10:29:55 +0100 committer Caolán McNamara <caolanm@redhat.com> 2020-08-28 20:15:45 +0200 commit 3fc63a7463149685b04c676968a82bc00a48a9af (patch) tree 730a8219e3617b3fd6773dab0a961265945cf9b7 parent bde1637b30570ee82fd8f3f72d1f6f4012914fc0 (diff) weld OTableBorderWindow https://cgit.freedesktop.org/libreoffice/core/commit/?id=3fc63a7463149685b04c676968a82bc00a48a9af
Adding CC: to Caolán McNamara
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ef597c30f60d83545c249e3cf02feeca1c9c8a8a Resolves: tdf#138675 crash on checking if focus is in OFieldDescControl It will be available in 7.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.
fixed in master, backport to 7-1 in gerrit
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/c2ea190a0ef9a9eb4f66ea6b708f9a1735d5e0c4 Resolves: tdf#138675 crash on checking if focus is in OFieldDescControl It will be available in 7.1.0.2. 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.
Initially, adding a row with an auto-id, and then clicking the next row worked. Then I went to the help menu at the top to get the information to paste here about the version, and it crashed, leaving instances in memory (seen via Task Manager). After recovering: Going to the help window first did not produce a crash. Selecting the 2nd row after creating an auto number field, no crash. Selecting the 3rd row after selecting the 2nd row, crash. Version: 7.2.0.0.alpha0+ (x64) Build ID: 94f6765d6ecc3145fa2d266231124003cf953118 CPU threads: 8; OS: Windows 10.0 Build 21286; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
(In reply to mwtjunkmail from comment #26) > Initially, adding a row with an auto-id, and then clicking the next row > worked. > Then I went to the help menu at the top to get the information to paste here > about the version, and it crashed, leaving instances in memory (seen via > Task Manager). > > > > > After recovering: > Going to the help window first did not produce a crash. > Selecting the 2nd row after creating an auto number field, no crash. > Selecting the 3rd row after selecting the 2nd row, crash. > > > > Version: 7.2.0.0.alpha0+ (x64) > Build ID: 94f6765d6ecc3145fa2d266231124003cf953118 > CPU threads: 8; OS: Windows 10.0 Build 21286; UI render: Skia/Vulkan; VCL: > win > Locale: en-US (en_US); UI: en-US > Calc: CL Your build doesn't contain the fix. Please, try with a more recent build from https://dev-builds.libreoffice.org/daily/master/current.html
I just grab the current daily build, which was marked the 14th. I've never played with a master copy but I'll see.
What you directed me to is exactly the build I tested on just now. 2021-01-14 12:15:52
(In reply to mwtjunkmail from comment #29) > What you directed me to is exactly the build I tested on just now. > > 2021-01-14 12:15:52 https://ci.libreoffice.org/job/lo_daily_tb_win/ https://ci.libreoffice.org/job/lo_daily_tb_win/486/ https://gerrit.libreoffice.org/q/status:merged+branch:master+project:core,25 https://gerrit.libreoffice.org/q/status:merged+branch:master+project:core
(In reply to himajin100000 from comment #30) > (In reply to mwtjunkmail from comment #29) > > What you directed me to is exactly the build I tested on just now. > > > > 2021-01-14 12:15:52 > > https://ci.libreoffice.org/job/lo_daily_tb_win/ > https://ci.libreoffice.org/job/lo_daily_tb_win/486/ > https://gerrit.libreoffice.org/q/status:merged+branch:master+project:core,25 > https://gerrit.libreoffice.org/q/status:merged+branch:master+project:core My apologizes, but as an end user who is trying to help you guys out by reporting bugs the best I know how, the above means zero to me. I looked at the tb_win/ link changes, didn't see anything I recognized as having to do with Base, but that doesn't mean it's not listed. If you're trying to make a point, please speak End User.
(In reply to mwtjunkmail from comment #31) The commit got pushed today. The buildbot produces or packages master build installer once a day (normally at night). So fix here will appear in build of the 15th Xisco/Buovjaga building themselves. So can confirm something fixed earlier in the process. People relying on builtbot have to wait a day.. And sometimes longer (if the builtbot producing master got stuck somehow). But that is easy to notice. If you're still downloading the 14-01 release on 15th (except if you're really early in the morning)
(In reply to Commit Notification from comment #25) > Caolán McNamara committed a patch related to this issue. > It has been pushed to "libreoffice-7-1": > > https://git.libreoffice.org/core/commit/ > c2ea190a0ef9a9eb4f66ea6b708f9a1735d5e0c4 > > Resolves: tdf#138675 crash on checking if focus is in OFieldDescControl > > It will be available in 7.1.0.2. > > 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. Works for me in: Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 1a167625314bf36b735176ed488e6ba9b5e9b675 CPU threads: 8; OS: Windows 10.0 Build 21292; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL