This bug was filed from the crash reporting server and is br-9ea9716f-6f3a-445a-b31c-41da42487d12 Also: https://crashreport.libreoffice.org/stats/crash_details/ea521f92-1c3a-4679-87f2-11b7a56e17f9 and https://crashreport.libreoffice.org/stats/crash_details/f700dad2-e18c-4b23-a27c-62ab3d2ebe11 ========================================= 1. Ctrl+F2->Variables->User Field (General format) 2. Put "Foo" into Name box 3. Apply 4. Input Field (select Foo), give Reference 5. Insert 6. Type something into Review Views 7. Ok 6. User Field 7. Put "Bar" into Name box 8. Put cursor into empty Value box 9. "Close" (maybe a few times?) (it doesn't close). 10. Insert Crash Additional information: 1. For the first three crashes, the progress bar in the "Documents are Being Saved" box stopped around 80-90% (after a while I shut it down). But in the latest crash the recovery process completed itself. https://crashreport.libreoffice.org/stats/crash_details/0a07b0fa-d598-4836-a229-14b14870053d0a07b0fa-d598-4836-a229-14b14870053d 2. When the document is recovered, both the Fields dialog and Review Fields dialog boxes are opened with the document (even though the Review Fields was closed at the time of the crash). 3. Not trying to make a crash, just working with bug #111888, comment 14
I can't reproduce it in Version: 6.5.0.0.alpha0+ Build ID: 838935758a5ec8e0e68f4df0cf5bfcf737e3f6f2 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ?
Cannot reproduce with: Version: 6.3.4.2 (x64) Build ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; Locale: en-US (en_DK); UI-Language: en-US Calc: threaded Cannot reproduce with: Version: 6.5.0.0.alpha0+ (x64) Build ID: 035c7717c135c66c0ec025500b73ae9c13b7c586 CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: GL; VCL: win; Locale: da-DK (en_DK); UI-Language: en-US Calc: threaded The day when I could reproduce this crash, the "Field Dialog" box would not close (but "Insert" would give a crash). Have encountered this situation several times before (not being able to "Close" the Field Dialog box) -- but have not been able to identify how to reliably produce that problem. I mention this in case it might be relevant.
Have finally found a reliable recipe -- which also crashes: Version: 6.5.0.0.alpha0+ (x64) Build ID: 035c7717c135c66c0ec025500b73ae9c13b7c586 CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: GL; VCL: win; Locale: da-DK (en_DK); UI-Language: en-US Calc: threaded 1. Make a User Field (Ctrl-F2, Variable tab, Type - User Field, Name (your choice), Apply ) 2. Insert an Input Field using the User Field. (enter some text in the field) 3. Leave the cursor inside the Input Field in the document. (now you should not be able to "Close" the Fields Dialog.) 4. Press "Insert" (with cursor still in Input Field) Crash! Additional info: 1. The Recovery process tries to save the file, but ran for a long time, so I closed it. 2. The offer to send a crash report was accepted, but no URL was given. 3. Understand now that I could not Close the Fields dialog, because the cursor was in the Input Field. 4. Have not re-tested the recipe with 6.3.4.2, but expect that it will make a crash.
I confirm it with Version: 6.5.0.0.alpha0+ (x64) Build ID: 350d25da375f221edfa37309324ce3c68cf297ef CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-GB Calc: threaded
Also reproduced in Version: 5.2.0.0.alpha0+ Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53 Threads 4; Ver: 4.19; Render: default;
Also reproducible in Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e
Not reproducible in Version: 4.1.0.0.alpha1+ Build ID: 863d38fbfa4fb4861e476828c46410602100919
Created attachment 159123 [details] bt with debug symbols (gtk3) On pc Debian x86-64 with master sources updated today, I could reproduce this by following comment 3.
Bibisected with Linux 43max to range https://git.libreoffice.org/core/+log/994362b3bd6d2a988e031828bfb36f1752042319..ed5cf167c695cbf45f3b6150eb8bd36b992963e1 This certainly jumps out: https://git.libreoffice.org/core/+/50f0bb85b7e18001886fdf8bb03eb1d138838b90%5E%21/ Resolves: #i124179# trigger update User Fields... and related Input Fields when user directly edits a User Field Input Field Btw. my Step 4. modification of the steps in comment 3 was: Press "Insert" (with cursor still in Input Field). Press Cancel Crash! This was super annoying to bibisect as I had to use this trick to get over the boring skipped commits: https://wiki.documentfoundation.org/QA/Bibisect#Unable_to_start_soffice but then I always forgot that I needed to first quit LibreOffice and start it again normally or otherwise the crash would keep the while loop going!
Name = Foo, Value = Bar -> Insert and whether I repeat this before/after the field or at any place in the document I can do Insert and Close without crash.
Unable to reproduce on Linux (Ubuntu 20.04). Tried master, bibisect 7.0 oldest, bibisect 6.2 master. I tried variations of comment 3 and comment 9's reproduction steps. But I could always close. I could always insert (getting a field with the visual output "0" regardless of what I put in the value field - which I usually left blank).
(In reply to Justin L from comment #11) > Unable to reproduce on Linux (Ubuntu 20.04). Tried master, bibisect 7.0 > oldest, bibisect 6.2 master. > > I tried variations of comment 3 and comment 9's reproduction steps. But I > could always close. I could always insert (getting a field with the visual > output "0" regardless of what I put in the value field - which I usually > left blank). I can't repro now either. Even if the field format is text, I can't type into the inserted field directly in the document canvas. Arch Linux 64-bit Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 4b41880be6894aaa2d2392554e858631278ba320 CPU threads: 8; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 13 August 2021
(In reply to Buovjaga from comment #12) > I can't repro now either. Even if the field format is text, I can't type > into the inserted field directly in the document canvas. If you have a look at summary of crash signature, you can see, that crashes are related to Windows: https://crashreport.libreoffice.org/stats/signature/SwDocUpdateField::MakeFieldList_(SwDoc%20&,int)
(In reply to Dieter from comment #13) > (In reply to Buovjaga from comment #12) > > I can't repro now either. Even if the field format is text, I can't type > > into the inserted field directly in the document canvas. > > If you have a look at summary of crash signature, you can see, that crashes > are related to Windows: > https://crashreport.libreoffice.org/stats/signature/SwDocUpdateField:: > MakeFieldList_(SwDoc%20&,int) Well, I don't have an explanation on why Linux is missing there, but as you can see from my comment 9 I could bibisect this on Linux.
(In reply to Dieter from comment #13) > If you have a look at summary of crash signature, you can see, that crashes > are related to Windows: > https://crashreport.libreoffice.org/stats/signature/SwDocUpdateField:: > MakeFieldList_(SwDoc%20&,int) On Linux, using the steps in Comment 3, it crashed too but gives a different signature: - SwTextField::ExpandTextField in 7.1 - SwTextField::ExpandTextField(bool) const in 7.2 https://crashreport.libreoffice.org/stats/crash_details/595e0da6-95d4-4dc0-b1d7-5ccf52fdefbd Only a handful of reports for that one, just on Linux. So that might be what other Linux testers here were seeing. The commit Ilmari found in his Comment 9 bibisect is consistent with that. I haven't found these signatures in existing bug reports, but I can't reproduce since 7.3 (the inserting process is a bit more erratic). About the Windows-only crash we are talking about here, I tested on Windows 10 with LO 7.4.5.1 and couldn't crash it. Version: 7.4.5.1 (x64) / LibreOffice Community Build ID: 9c0871452b3918c1019dde9bfac75448afc4b57f CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded However, I see on the crash report website that the crash has happened in 7.4.