Bug 145062 - Crash when inserting hidden field over input field
Summary: Crash when inserting hidden field over input field
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.0.3 release
Hardware: All Windows (All)
: medium normal
Assignee: Michael Stahl (allotropia)
URL:
Whiteboard: target:7.4.0 target:7.3.0.0.beta2 tar...
Keywords:
Depends on:
Blocks: Fields Fields-Dialog
  Show dependency treegraph
 
Reported: 2021-10-11 09:29 UTC by Gabor Kelemen (allotropia)
Modified: 2021-12-31 08:25 UTC (History)
6 users (show)

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


Attachments
Example file from Writer with two input fields (8.13 KB, application/vnd.oasis.opendocument.text)
2021-10-11 09:29 UTC, Gabor Kelemen (allotropia)
Details
Screenshot of the document in Writer before crash (53.08 KB, image/png)
2021-10-11 09:29 UTC, Gabor Kelemen (allotropia)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gabor Kelemen (allotropia) 2021-10-11 09:29:15 UTC
Created attachment 175657 [details]
Example file from Writer with two input fields

Steps to reproduce:
    1. In a new Writer document select Insert – Field – More Fields
    2. On the Functions tab, select the Input field type
    3. Enter some text in the Reference box and press Insert
    4. Enter some text in the Review Fields dialog that pops up, press OK
    5. Click in the document after fhe newly inserted field
    6. In the Fields dialog insert another input field 
    7. Position the cursor before the second field so that the little highlight square is on the second field (if the first is highlighted, this works)
    8. In the Fields dialog select the Hidden text type and press Insert

Actual results:
Crash.

Expected results:
No crash, hidden text field gets inserted.

LibreOffice details:
Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: b1488cd6f008049a9aaff7350deeb73cbbd535b6
CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: hu-HU (en_US); UI: en-US
Calc: threaded

Also in 7.0, 6.0.
Comment 1 Gabor Kelemen (allotropia) 2021-10-11 09:29:40 UTC
Created attachment 175658 [details]
Screenshot of the document in Writer before crash
Comment 2 Dieter 2021-10-30 03:47:29 UTC
(In reply to Gabor Kelemen (allotropia) from comment #0)
>     7. Position the cursor before the second field so that the little
> highlight square is on the second field (if the first is highlighted, this
> works)

I can' reproduce, because all options in Insert -> Fields are greyed out (Expected). It's also not possible to open Filed Dialog with Strg+2.
Comment 3 Dieter 2021-10-30 03:49:05 UTC
Tested with

Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 273a25c796fca9afa0dfadac57dc3f336831221c
CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL
Comment 4 Gabor Kelemen (allotropia) 2021-10-31 07:58:50 UTC
(In reply to Dieter from comment #2)
> (In reply to Gabor Kelemen (allotropia) from comment #0)
> >     7. Position the cursor before the second field so that the little
> > highlight square is on the second field (if the first is highlighted, this
> > works)
> 
> I can' reproduce, because all options in Insert -> Fields are greyed out
> (Expected). It's also not possible to open Filed Dialog with Strg+2.

You should NOT close the Fields dialog after step 6.
After inserting the second field, switch back to the document and reposition the cursor to highlight it, then go back to the Fields dialog and try to insert another field on top of the highlighted one. Then the crash happens.
Comment 5 Dieter 2021-11-02 16:32:16 UTC
(In reply to Gabor Kelemen (allotropia) from comment #4)
> You should NOT close the Fields dialog after step 6.

Thank you for this hint. Now I could reproduce it with
Version: 7.2.2.2 (x64) / LibreOffice Community
Build ID: 02b2acce88a210515b4a5bb2e46cbfb63fe97d56
CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL

https://crashreport.libreoffice.org/stats/crash_details/645e72fb-52f8-4f9d-baf2-f63d0f5179e2

All crashes with that signature are Windows related, see: https://crashreport.libreoffice.org/stats/signature/SwDocUpdateField::MakeFieldList_(SwDoc%20&,int)
Comment 6 Gabor Kelemen (allotropia) 2021-11-02 16:53:33 UTC
(In reply to Dieter from comment #5)
> All crashes with that signature are Windows related, see:
> https://crashreport.libreoffice.org/stats/signature/SwDocUpdateField::
> MakeFieldList_(SwDoc%20&,int)

Sure but the crashreporter is enabled only for Windows builds, so that's not indicative.
I can make it crash on Linux as well.
Comment 7 Dieter 2021-11-02 16:56:57 UTC
(In reply to Gabor Kelemen (allotropia) from comment #6)
> Sure but the crashreporter is enabled only for Windows builds, so that's not
> indicative.
> I can make it crash on Linux as well.

Thank you for that information, that is new to me. But there are other summaries of crash signatures that also shows crashes with Linux (but I don't have to understand everything).
Comment 8 Samuel Mehrbrodt (allotropia) 2021-11-22 10:39:14 UTC
Backtrace excerpt:

#5  0x00007ffff7aa06db in __assert_fail_base
    (fmt=0x7ffff7c54770 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7fff52a043c4 "m_pTextNode", file=0x7fff52a043a0 "sw/inc/txtfld.hxx", line=55, function=<optimized out>)
    at assert.c:92
#6  0x00007ffff7ab1e26 in __GI___assert_fail
    (assertion=0x7fff52a043c4 "m_pTextNode", file=0x7fff52a043a0 "sw/inc/txtfld.hxx", line=55, function=0x7fff52a04370 "SwTextNode& SwTextField::GetTextNode() const") at assert.c:101
#7  0x00007fff519484e1 in SwTextField::GetTextNode() const (this=0x55555ca92d80) at sw/inc/txtfld.hxx:55
#8  0x00007fff51a1dfa1 in SwDocUpdateField::MakeFieldList_(SwDoc&, int) (this=0x55555b884fd0, rDoc=..., eGetMode=3) at sw/source/core/doc/docfld.cxx:918
#9  0x00007fff51a1d868 in SwDocUpdateField::MakeFieldList(SwDoc&, bool, int) (this=0x55555b884fd0, rDoc=..., bAll=true, eGetMode=3) at sw/source/core/doc/docfld.cxx:821
#10 0x00007fff51b39ac3 in sw::DocumentFieldsManager::UpdateExpFields(SwTextField*, bool) (this=0x55555b96e140, pUpdateField=0x0, bUpdRefFields=true)
    at sw/source/core/doc/DocumentFieldsManager.cxx:853
#11 0x00007fff51cd08b7 in SwEditShell::UpdateExpFields(bool) (this=0x55555b9405f0, bCloseDB=true) at sw/source/core/edit/edfld.cxx:317
#12 0x00007fff526e51fd in SwFieldMgr::InsertField(SwInsertField_Data const&) (this=0x55555cc6c090, rData=...) at sw/source/uibase/fldui/fldmgr.cxx:1505
#13 0x00007fff60272196 in SwFieldPage::InsertField(SwFieldTypesEnum, unsigned short, rtl::OUString const&, rtl::OUString const&, unsigned int, char16_t, bool) (this=
    0x55555cc6c030, nTypeId=SwFieldTypesEnum::HiddenText, nSubType=0, rPar1="", rPar2="", nFormatId=0, cSeparator=32 u' ', bIsAutomaticLanguage=true)
    at sw/source/ui/fldui/fldpage.cxx:127
#14 0x00007fff60270cfe in SwFieldFuncPage::FillItemSet(SfxItemSet*) (this=0x55555cc6c030) at sw/source/ui/fldui/fldfunc.cxx:565
#15 0x00007fff6027e721 in SwFieldDlg::OKHdl(weld::Button&) (this=0x55555ca79360) at sw/source/ui/fldui/fldtdlg.cxx:164
#16 0x00007fff6027e625 in SwFieldDlg::LinkStubOKHdl(void*, weld::Button&) (instance=0x55555ca79360, data=...) at sw/source/ui/fldui/fldtdlg.cxx:158
#17 0x00007fffe8c54249 in Link<weld::Button&, void>::Call(weld::Button&) const (this=0x55555b5774f8, data=...) at include/tools/link.hxx:111
#18 0x00007fffe8c4c535 in weld::Button::signal_clicked() (this=0x55555b5774f0) at include/vcl/weld.hxx:1406
#19 0x00007fffe8bfde55 in (anonymous namespace)::GtkInstanceButton::signalClicked(GtkButton*, gpointer) (widget=0x55555b577310) at vcl/unx/gtk3/gtkinst.cxx:9316
Comment 9 Vasily Melenchuk (CIB) 2021-11-22 11:44:06 UTC
As far as I see problem came from practical attempt to insert one field inside another field. And Writer UI does not prohibit this.

I can propose even simpler scenario to trigger this assert/crash: 
1. Into empty document insert input field with some content.
2. Put cursor somewhere in the middle of this content (again without closing "Fields" dialog!)
3. Try to insert any other field, not input field.

In my case I see exactly same assert/crash with same backtrace.

In my opinion Writer UI should not allow to do this: either "Fields" dialog should disappear, like it does in some cases (for example, when cursor is placed into text box). Or "Insert" button should be disabled.
Comment 10 Commit Notification 2021-12-03 09:17:57 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/89eb90ceea414974289b57f15e769d08b80fe9a3

tdf#145062 sw: really destroy text attribute when insertion fails

It will be available in 7.4.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.
Comment 11 Commit Notification 2021-12-03 09:19:09 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/e58583e70b3434a158a3902cc7ae81d0b3bdfc49

tdf#145062 sw: deal with failing insertion of field in SwWrtShell

It will be available in 7.4.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.
Comment 12 Michael Stahl (allotropia) 2021-12-03 09:30:01 UTC
hope it doesn't crash any more
Comment 13 Commit Notification 2021-12-03 15:57:20 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-7-3":

https://git.libreoffice.org/core/commit/68a76917a89a816648a00c6e8463ca2df497c0a7

tdf#145062 sw: really destroy text attribute when insertion fails

It will be available in 7.3.0.0.beta2.

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.
Comment 14 Commit Notification 2021-12-03 15:58:33 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-7-3":

https://git.libreoffice.org/core/commit/f9ea114171cb422dac60100aa4d51502563f37a1

tdf#145062 sw: deal with failing insertion of field in SwWrtShell

It will be available in 7.3.0.0.beta2.

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.
Comment 15 Commit Notification 2021-12-04 10:53:55 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-7-2":

https://git.libreoffice.org/core/commit/5c66c41e52b111ed9ad41b2c057f5c1346888e79

tdf#145062 sw: really destroy text attribute when insertion fails

It will be available in 7.2.4.

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.
Comment 16 Commit Notification 2021-12-06 07:26:01 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-7-2":

https://git.libreoffice.org/core/commit/7d3d19ab76ff0acb948431c1792561a466bcd2d9

tdf#145062 sw: deal with failing insertion of field in SwWrtShell

It will be available in 7.2.4.

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.
Comment 17 Christian Lohmaier 2021-12-06 13:30:12 UTC
7.2.4 was a hotfix release, updating target in status-whiteboard
Comment 18 Commit Notification 2021-12-15 23:31:12 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/deea3b7471c3dab0220eca6146c225a2d47681a2

tdf#145062: sw: Add UItest

It will be available in 7.4.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.
Comment 19 Commit Notification 2021-12-20 10:45:40 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/40487d9c81c69c4e5ee1621e53c8162ae33c80b2

tdf#145062 sw: try to fix UBSan crash in UITest

It will be available in 7.4.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.
Comment 20 Dieter 2021-12-27 11:36:08 UTC
No crash in

Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 9c95415de877af1430ab5b7123e11dedd0ea622c
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL

but nothing happens after step 8(no hiden tex is inserted). Is this expected?
Comment 21 Gabor Kelemen (allotropia) 2021-12-28 13:30:47 UTC
(In reply to Dieter from comment #20)
> but nothing happens after step 8(no hiden tex is inserted). Is this expected?

I think yes, similarly to the case when you close the Fields dialog after inserting a field, move the cursor inside the field and try to open the Fields dialog again - it does not happen either, so you can't insert another field inside an existing field (see also your earlier comment #2).
Comment 22 Dieter 2021-12-31 08:25:28 UTC
Thank you for quick response. So let's change status to VERIFIED.