1. Insert a shape. 2. Select shape, right-click, choose "Insert Caption" 3. insert a caption, then select caption and cut (Ctrl+X) Actual: Crash (also when tested in Safe Mode) tested with: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5607e88d5f2f2eb7a6b0c9c329728589761c3431 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: da-DK (da_DK); UI: en-US Calc: CL threaded Did not crash with LO 7.2.7.2
Not reproduced on: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1b463f697405e64a03378fb38a32172c4d3c25e6 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Could be Windows-only.
No crash for me Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c4a58634753a84b09f20f7271d6525a6656522d3 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 threaded To only difference: Skia/Raster versus Vulkan. However this shouldn't matter.. as the crash was seen in GDI mode as well (safe-mode)
Skia/Vulkan reflects disabling "Force Skia software rendering" in Tools - Options - Libreoffice - View, while Skia/Raster reflects enabling that option. Just reproduced the crash again with both versions (and same LO version as named in OP), and with Safe Mode. Maybe I need to add a step 4 to the STR: 1. Insert a shape. 2. Select shape, right-click, choose "Insert Caption" 3. insert a caption, then select caption and cut (Ctrl+X) 4. (the caption and shape should not be visible now), click in the canvas, outside of the frame. (but I also get a crash sometimes without this step.) Additional information: 1. The shape is anchored "to paragraph". But I tried to anchor it as "character", and that gave a crash after cutting the caption, without having to click in the document. 2. After the crash, I can see (in the Windows Task Manager) that the processes (soffice.bin and soffice.exe) are still running as background processes, but the application (window) is not visible and does not appear in the taskbar.
(In reply to sdc.blanco from comment #3) Hmm. Still not able to repro the exact steps, however I got a crash in same area 1. Insert a shape. 2. Select shape, right-click, choose "Insert Caption" 3. Press with the caption frame selected CTRL+X (or select the caption within the frame) 4. Press CTRL+F4 or Red Close LibreOffice button 5. Don't save on warning -> Crash
(In reply to Telesto from comment #4) > however I got a crash in same area Thanks. New (simpler) STR (also in Safe Mode). 1. Insert - Frame 2. (with frame still selected) Insert - Caption (add caption text and finish dialog). 3. (with frame still selected) Ctrl+X Crash. Additional information: 1. Does not crash if step 2 is skipped. 2. Not exactly the same STR as the OP, because now the frame is being deleted, not the caption. 3. Have also tested now with: 1. Insert - Image 2. Add caption 3. enter frame with image and caption, and select caption 4. Ctrl+X, Crash. (does not crash if image is deleted without deleting caption) 4. I thought this effect might be related to the recent patch (bug 154040) for not being able to make interactive frames, but my version of LO is prior to that patch, while your version is after.
Another kind of (related?) crash. 1. Open attachment 163998 [details] (has two frames, each with an image and a caption) 2. Crtl+A 3. Ctrl+C wait a little, then crash Tested in Safe Mode with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1e9f4de320f67d1218c710bcee1969a2324c6888 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: default; VCL: win Locale: da-DK (da_DK); UI: en-US Calc: threaded No problems with LO 7.2.7.2
(In reply to sdc.blanco from comment #5) > (In reply to Telesto from comment #4) > > however I got a crash in same area > Thanks. New (simpler) STR (also in Safe Mode). > > 1. Insert - Frame > 2. (with frame still selected) Insert - Caption (add caption text and finish > dialog). > 3. (with frame still selected) Ctrl+X No crash Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 23bd3bd10e74b0c23c2654d02d7d830e7693adac CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: en-US (en_FI); UI: en-US Calc: threaded Arch Linux 64-bit, X11 Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 79e60bb93f69370f23010adb078b5a5de5a1e7b2 CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 6 April 2023
(In reply to Buovjaga from comment #7) > No crash repro (also in Safe Mode) with another version Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1e9f4de320f67d1218c710bcee1969a2324c6888 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: da-DK (da_DK); UI: en-US Calc: CL threaded Additional information. 0. Does not crash when deleting an empty frame. 1. Using STR in comment 5. (sometimes have to wait a few seconds) 2. In this case "crash" means: a. window (Untitled 1) with deleted frame and caption disappears from desktop. b. No indication of window in (Windows) Taskbar and not shown as a running App in (Windows) Task Manager. c. but the (background) processes (soffice.exe and soffice.bin) are still running (as seen in Task Manager) d. Start LO again (from Windows menu). A new (empty) document (Untitled 2) is shown (but looking in Window in LO menubar only shows Untitled 2). e. Close Untitled 2, then close/quit LO, and then suddenly the "crashed?" Untitled 1 window is visible, and asking if it should be saved. It is even possible to "paste" back the deleted frame and caption. f. Close the "resurrected" Untitled 1 and close/quit LO again. g. Start LO (from Windows menu), now the Crash reporter dialog appears. Similar kind of situation in the STR in comment 6. In short, the (background) processes are not crashing, but the window disappears, and after quitting and restarting LO, the crash reporter appears. Does that help to clarify?
(In reply to Telesto from comment #4) > (In reply to sdc.blanco from comment #3) > Hmm. Still not able to repro the exact steps, however I got a crash in same > area > > 1. Insert a shape. > 2. Select shape, right-click, choose "Insert Caption" > 3. Press with the caption frame selected CTRL+X (or select the caption > within the frame) > 4. Press CTRL+F4 or Red Close LibreOffice button > 5. Don't save on warning -> Crash @Buovjaga Would you mind to try these steps too..
Tried the alternative crash proposals now. (In reply to Telesto from comment #4) > (In reply to sdc.blanco from comment #3) > Hmm. Still not able to repro the exact steps, however I got a crash in same > area > > 1. Insert a shape. > 2. Select shape, right-click, choose "Insert Caption" > 3. Press with the caption frame selected CTRL+X (or select the caption > within the frame) > 4. Press CTRL+F4 or Red Close LibreOffice button > 5. Don't save on warning -> Crash (In reply to sdc.blanco from comment #6) > Another kind of (related?) crash. > 1. Open attachment 163998 [details] (has two frames, each with an image > and a caption) > 2. Crtl+A > 3. Ctrl+C > wait a little, then crash No repro Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 79e60bb93f69370f23010adb078b5a5de5a1e7b2 CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 23bd3bd10e74b0c23c2654d02d7d830e7693adac CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: en-US (en_FI); UI: en-US Calc: threaded
(In reply to Buovjaga from comment #10) > CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: ^^^^^^^^^^^^ Win 11? vs. my Win 10 Build 19044 ? vs. Telesto's Win 7 (?) Build 9600 Retested (and crashed) with: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 375f85f8518f49ce4381b6663f1e94fc02bacf93 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Simpler STR 1. Insert "number range" variable field (e.g. Ctrl+F2, select type "Number range", use any "Select" (e.g., Drawing), give a value (e.g., "4"), select any Format, Insert, Close). Alternative: Use a document that already has an inserted "number range" variable field (e.g., from a caption). 2. Select the inserted "number range" field. 3. Crtl+C (or Ctrl+X) crash (sometimes after a short delay) Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 375f85f8518f49ce4381b6663f1e94fc02bacf93 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: da-DK (da_DK); UI: en-US Calc: CL threaded changing bug summary -- because frame is not needed.
Extending the OP STR 1. New document 2. Insert variable (e.g., Ctrl+F2 - Variable tab - select "Set variable", General format, give any "name", a numerical "value", press "Insert", then "Close") 3. Select the inserted field and Ctrl+X Crash Same problem if type: "user field" is used. => more general than "number range" In short: it appears that inserting and then copying/cutting any type of variable field results in crash (now tested with 3 different versions of 7.6) Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: fc6806c4be8585ce0d35a6b581bf8b3dbf858500 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: af-ZA (da_DK); UI: en-US Calc: CL threaded
Still no repro for me, tried comment 13 steps on Ubuntu 20.04 and macOS 13 with a master build from today. We asked for more Windows testers in the chat.
I can reproduce Comment#1 and Comment#4. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f22f7159ec1bd28d19f4a8b431893436419ecd64 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Jumbo Works fine for me with Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
*** Bug 154678 has been marked as a duplicate of this bug. ***
This seems to have begun at the below commit in bibisect repository/OS win64-7.6. Adding Cc: to Paris Oplopoios; Could you possibly take a look at this one? Thanks fe420d4fcd358840a2e45b4985a69f92794b9b55 is the first bad commit commit fe420d4fcd358840a2e45b4985a69f92794b9b55 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Thu Mar 16 03:26:24 2023 -0700 source 1916d161902bdd52b8cfa5b29153c8f8c39fce52 148481: De-static-izing colors in SwViewOption | https://gerrit.libreoffice.org/c/core/+/148481
(In reply to sdc.blanco from comment #13) > Extending the OP > > STR > 1. New document > 2. Insert variable (e.g., Ctrl+F2 - Variable tab - select "Set variable", > General format, give any "name", a numerical "value", press "Insert", then > "Close") > 3. Select the inserted field and Ctrl+X > Crash > > Same problem if type: "user field" is used. > > => more general than "number range" > > In short: it appears that inserting and then copying/cutting any type of > variable field results in crash (now tested with 3 different versions of 7.6) > > Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: fc6806c4be8585ce0d35a6b581bf8b3dbf858500 > CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: > win > Locale: af-ZA (da_DK); UI: en-US > Calc: CL threaded I can repro this crash on two computers with debug builds but not on another running a non debug build. Here is a patch that makes the debug build computers not crash: https://gerrit.libreoffice.org/c/core/+/151300 I confirm with raal's bibisect to the commit that causes this crash.
I’ll look at this during the weekend. I’ll need to build on Windows. If anyone can repro on linux that’d be great
(In reply to Paris Oplopoios from comment #19) > I’ll look at this during the weekend. I’ll need to build on Windows. If > anyone can repro on linux that’d be great I repro on Linux using debug builds. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7e74f2260b7d093c1b3bb6e362de1c52b5068cc6 CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Backtrace: 1 std::__uniq_ptr_impl<SwWrtShell, std::default_delete<SwWrtShell>>::_M_ptr unique_ptr.h 173 0x7fffc0684c76 2 std::unique_ptr<SwWrtShell, std::default_delete<SwWrtShell>>::get unique_ptr.h 422 0x7fffc06833e6 3 std::unique_ptr<SwWrtShell, std::default_delete<SwWrtShell>>::operator * unique_ptr.h 408 0x7fffc06833c7 4 SwView::GetWrtShell view.hxx 423 0x7fffc06824c2 5 OutHTML_SwFormatField htmlfldw.cxx 547 0x7fffc11dba48 6 Out wrt_fn.cxx 37 0x7fffc12b2588 7 OutHTML_SwTextNode htmlatr.cxx 2433 0x7fffc11ab9c1 8 SwHTMLWriter::Out_SwDoc wrthtml.cxx 927 0x7fffc12a5627 9 SwHTMLWriter::WriteStream wrthtml.cxx 576 0x7fffc12a367a 10 Writer::Write writer.cxx 234 0x7fffc12adebd 11 SwWriter::Write shellio.cxx 870 0x7fffc118d68f 12 SwTransferable::WriteObject swdtflvr.cxx 824 0x7fffc141ef4b 13 TransferableHelper::SetObject transfer.cxx 840 0x7ffff0e17a9d 14 SwTransferable::GetData swdtflvr.cxx 628 0x7fffc141dfcd 15 TransferableHelper::getTransferData2 transfer.cxx 385 0x7ffff0e15b7f 16 TransferableHelper::getTransferData transfer.cxx 281 0x7ffff0e152b5 17 VclToGtkHelper::setSelectionData gtkinst.cxx 1316 0x7fffe754069b 18 (anonymous namespace)::VclGtkClipboard::ClipboardGet gtkinst.cxx 1037 0x7fffe753fe45 19 (anonymous namespace)::ClipboardGetFunc gtkinst.cxx 1062 0x7fffe7540014 20 ?? 0x7fffe6fc754a 21 g_signal_emit_valist 0x7fffec27b700 22 g_signal_emit_by_name 0x7fffec27ba8e 23 ?? 0x7fffe6eb072b 24 ?? 0x7fffe6eb590a 25 ?? 0x7fffe6fbceb8 26 g_signal_emit_valist 0x7fffec27b700 27 g_signal_emit 0x7fffec27b863 28 ?? 0x7fffe6f84724 29 gtk_main_do_event 0x7fffe6e28001 30 ?? 0x7fffe6b08743 31 ?? 0x7fffe6b3ff56 32 g_main_context_dispatch 0x7fffec164d3b 33 ?? 0x7fffec1b96c8 34 g_main_context_iteration 0x7fffec1623e3 35 GtkSalData::Yield gtkdata.cxx 405 0x7fffe753af5a 36 GtkInstance::DoYield gtkinst.cxx 433 0x7fffe753eb98 37 ImplYield svapp.cxx 385 0x7ffff11e954e 38 Application::Yield svapp.cxx 469 0x7ffff11ea230 39 Application::Execute svapp.cxx 363 0x7ffff11e9253 40 desktop::Desktop::Main app.cxx 1593 0x7ffff7cb7d38 41 ImplSVMain svmain.cxx 203 0x7ffff11fddf6 42 SVMain svmain.cxx 235 0x7ffff11fdf1f 43 soffice_main sofficemain.cxx 94 0x7ffff7d17065 44 sal_main main.c 51 0x555555554930 45 main main.c 49 0x555555554912
The patch by Jim would've been the solution I'd go for, looks good to me
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/20bf9f2b31343e17c14a3091d59b40a71eeb3e26 tdf#154551 check pointer before use It will be available in 7.6.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.
Jim, after your patch can you reproduce the crash?
(In reply to Paris Oplopoios from comment #23) > Jim, after your patch can you reproduce the crash? No crash repro'd with patched build: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 00f8f75f36dfb4394d43b10510ea08049752a1a7 CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (C); UI: en-US Calc: threaded
Should this be closed then?
Raal and Seth, can you please test with a recent master build?
no crashes when deleting variable fields using: Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: f3aab159f1c1e00c25e6b4ca1e50813bc343f4f3 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: da-DK (da_DK); UI: en-US Calc: CL threaded Thanks Jim!
Setting to resolved then.