Description: LibreOffice 25.8.1 crashes when the anchor setting for a graphic is changed in Writer Steps to Reproduce: 1. Copy a PNG file. 2. Paste into a Writer document. 3. Insert a caption below the graphic. 4. Right click on the graphic and select an aching style from the drop-down list. 5. LibreOffice immediately crashes. 6. Recover the document and check the graphic anchoring. Anchoring style has changed to the selected anchoring in Step 4. Actual Results: 1. Create a Writer document. 2. Copy a PNG file. 3. Go to the paragraph marker where the graphic is going to be inserted. 5. Paste the copied PNG graphic into position. 6. Right-click on the graphic to open the options for anchoring types. 7. Select an anchoring type and LibreOffice immediately. Expected Results: Anchoring type is changed and can continue editing the and updating the Writer document. Reproducible: Always User Profile Reset: No Additional Info: LibreOffice stays open so editing can continue.
I cannot reproduce the problem. Tested with Version: 25.8.1.1 (X86_64) Build ID: 54047653041915e595ad4e45cccea684809c77b5 CPU threads: 32; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded What kind of object do you get? Does the caption has category "Figure" or "Drawing"? Do you change the anchor of the frame or of the image? From what anchor to what anchor do you change it?
LibreOffice 25.8.1 only crashes when changing anchor type on an a graphic when using LibreOffice on macOS. Windows and Linux (Ubuntu OS) versions of LibreOffice 25.8.1 do not crash. Document recovery when using macOS works perfectly when the LibreOffice documents are recovered. The anchor type on the graphic has changed to the selected anchor type before crashing. Regards PeeWee
I cannot reproduce this bug in either of the following versions on my Mac. After adding a caption, I select each of the anchoring options one after the other and none caused a crash: Version: 25.8.1.1 (AARCH64) Build ID: 54047653041915e595ad4e45cccea684809c77b5 CPU threads: 8; OS: macOS 26.0.1; UI render: Skia/Metal; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded Version: 26.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 5777aa1af83a395dc86542012e465c30619d5a15 CPU threads: 8; OS: macOS 26.0.1; UI render: Skia/Metal; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded
OK. I can now reproduce the crash on both LibreOffice 25.8.1.1 and in my local master build. The key was that I had to select "As Character" for the anchor first. I had been selecting "To Paragraph". I will post a copy of the macOS Problem Report that contains the stack at the time of crash.
Created attachment 203187 [details] Crash report
Found the line of source code that causes the crash. In the code below, GetView() is garbage memory (sometimes null, sometimes not). I would guess that whatever GetView() returns has already been deleted and its memory reallocated. I am not familiar with the Writer code so we would definitely need one of the Writer developers to debug this: frame #2: 0x00000003e7c325bc libswlo.dylib`SwBaseShell::Execute(this=0x0000000ba7003d40, rReq=0x000000016fdfc310) at basesh.cxx:1434:60 1431 if (bDoMathBaselineAlignment) 1432 rSh.AlignFormulaToBaseline( xObj ); 1433 -> 1434 sal_uInt16 nHtmlMode = ::GetHtmlMode(GetView().GetDocShell()); 1435 if( nHtmlMode ) 1436 { 1437 SfxItemSet aSet(SfxItemSet::makeFixedSfxItemSet<RES_SURROUND, RES_HORI_ORIENT>(GetPool()));
*** Bug 169071 has been marked as a duplicate of this bug. ***
*** Bug 169294 has been marked as a duplicate of this bug. ***
I can't reproduce it with Version: 25.8.2.2 (AARCH64) Build ID: d401f2107ccab8f924a8e2df40f573aab7605b6f CPU threads: 8; OS: macOS 15.6; UI render: Skia/Metal; VCL: osx Locale: en-US (en_ES.UTF-8); UI: en-US Calc: threaded
I tried with the steps described here and with the document from bug 169071 but I can't reproduce the crash. @Patrick, do you still reproduce this issue on your side ? Could you please attach the document you are using ?
PeeWee: are you on macOS 26?
Created attachment 203773 [details] File that crashes when changing anchor of image I can reproduce the crash with the attached file: Version: 25.8.2.2 (AARCH64) Build ID: d401f2107ccab8f924a8e2df40f573aab7605b6f CPU threads: 8; OS: macOS 26.0.1; UI render: Skia/Metal; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded Here are the steps I use to reproduce the crash: 1. Open attached Writer file 2. Right-click on the image in the document 3. Select Anchor > As Character from the context menu
(In reply to Patrick (volunteer) from comment #12) > Created attachment 203773 [details] > File that crashes when changing anchor of image > > I can reproduce the crash with the attached file: > > Version: 25.8.2.2 (AARCH64) > Build ID: d401f2107ccab8f924a8e2df40f573aab7605b6f > CPU threads: 8; OS: macOS 26.0.1; UI render: Skia/Metal; VCL: osx > Locale: en-CA (en_CA.UTF-8); UI: en-US > Calc: threaded > > Here are the steps I use to reproduce the crash: > > 1. Open attached Writer file > 2. Right-click on the image in the document > 3. Select Anchor > As Character from the context menu Not reproduced in Version: 25.8.2.2 (AARCH64) Build ID: d401f2107ccab8f924a8e2df40f573aab7605b6f CPU threads: 8; OS: macOS 15.6; UI render: Skia/Metal; VCL: osx Locale: en-US (en_ES.UTF-8); UI: en-US Calc: threaded macOS 26 only ?
Yes, I am on macOS 26, but the LO crash started before I updated to 26. There is no crash if you use the properties dialog when changing anchor settings. Peter Schofield
(In reply to Xisco Faulí from comment #13) > macOS 26 only ? I have a wild theory: macOS Tahoe reuses deleted memory more aggressively than previous macOS versions. I don't have any good data, but from my crash log in attachment #203187 [details], this bug looks like a "use after free" bug to me. I saw the same "use after free" on macOS Tahoe in tdf#168526 as well. My theory is that macOS Tahoe is reallocating deleted memory much faster than before and so deleted pointers in Writer get overwritten by whatever code that gets allocated the deleted memory very soon after deletion. Not sure how the Writer developers can prevent this other than implementing some sort of "is this pointer still alive" code so that a pointer can be checked before use.
Confirming also with Version: 25.8.1.1 (AARCH64) Build ID: 54047653041915e595ad4e45cccea684809c77b5 CPU threads: 8; OS: macOS 26.1; UI render: Skia/Metal; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded I have to switch a few times between the anchoring types for the crash to occur.
*** Bug 169427 has been marked as a duplicate of this bug. ***
Just started seeing this on 25.8.2. One workaround I have is to set default value for LO/preferences/Anchor Image to "As Character" which is my preference. This