Bug 168703 - EDITING LibreOffice 25.8.1 keeps crashing when changing the anchor for a graphic
Summary: EDITING LibreOffice 25.8.1 keeps crashing when changing the anchor for a graphic
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
25.8.1.1 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-10-05 11:41 UTC by PeeWee
Modified: 2025-10-07 23:13 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Crash report (111.29 KB, text/plain)
2025-10-07 22:29 UTC, Patrick (volunteer)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description PeeWee 2025-10-05 11:41:19 UTC
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.
Comment 1 Regina Henschel 2025-10-05 13:49:11 UTC
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?
Comment 2 PeeWee 2025-10-06 07:52:11 UTC
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
Comment 3 Patrick (volunteer) 2025-10-07 18:12:50 UTC
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
Comment 4 Patrick (volunteer) 2025-10-07 22:28:51 UTC
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.
Comment 5 Patrick (volunteer) 2025-10-07 22:29:23 UTC
Created attachment 203187 [details]
Crash report
Comment 6 Patrick (volunteer) 2025-10-07 23:13:18 UTC
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()));