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.
Created attachment 175658 [details] Screenshot of the document in Writer before crash
(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.
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
(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.
(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)
(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.
(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).
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
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.
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.
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.
hope it doesn't crash any more
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.
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.
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.
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.
7.2.4 was a hotfix release, updating target in status-whiteboard
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.
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.
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?
(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).
Thank you for quick response. So let's change status to VERIFIED.