Bug 129824 - Crash in: SwDocUpdateField::MakeFieldList_(SwDoc &,int) after "Insert" of a "User Field" with cursor in value field of dialog box ( steps in comment 3 )
Summary: Crash in: SwDocUpdateField::MakeFieldList_(SwDoc &,int) after "Insert" of a...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
4.3 all versions
Hardware: All All
: medium critical
Assignee: Not Assigned
Keywords: bibisected, haveBacktrace, regression
Depends on:
Blocks: Fields-Dialog Crash
  Show dependency treegraph
Reported: 2020-01-06 01:24 UTC by sdc.blanco
Modified: 2020-06-10 12:04 UTC (History)
4 users (show)

See Also:
Crash report or crash signature: ["SwDocUpdateField::MakeFieldList_(SwDoc &,int)"]

bt with debug symbols (gtk3) (11.77 KB, text/plain)
2020-03-29 14:38 UTC, Julien Nabet

Note You need to log in before you can comment on or make changes to this bug.
Description sdc.blanco 2020-01-06 01:24:29 UTC
This bug was filed from the crash reporting server and is br-9ea9716f-6f3a-445a-b31c-41da42487d12 



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


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. 


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
Comment 1 Xisco Faulí 2020-01-10 11:01:04 UTC
I can't reproduce it in

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/ ?
Comment 2 sdc.blanco 2020-01-11 12:15:20 UTC
Cannot reproduce with:

Version: (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: (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.
Comment 3 sdc.blanco 2020-01-12 17:42:14 UTC
Have finally found a reliable recipe -- which also crashes:

Version: (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)

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, but expect that it will make a crash.
Comment 4 Dieter 2020-01-16 20:02:13 UTC
I confirm it with

Version: (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
Comment 5 Xisco Faulí 2020-01-20 09:20:23 UTC
Also reproduced in

Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53
Threads 4; Ver: 4.19; Render: default;
Comment 6 Xisco Faulí 2020-01-21 08:52:24 UTC
Also reproducible in

Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e
Comment 7 Xisco Faulí 2020-01-21 08:54:33 UTC
Not reproducible in

Build ID: 863d38fbfa4fb4861e476828c46410602100919
Comment 8 Julien Nabet 2020-03-29 14:38:54 UTC
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.
Comment 9 Buovjaga 2020-06-10 12:03:22 UTC
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

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!