https://bugs.documentfoundation.org/show_bug.cgi?id=167857
Bug ID: 167857
Summary: LO crashes randomly using draw
Product: LibreOffice
Version: unspecified
Hardware: Other
OS: macOS (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: LibreOffice
Assignee: [email protected]
Reporter: [email protected]
I need help. I don't know what to do.
LO 25.2.5.2, the same as previous version 24.x, crashes on Apple silicon, with
disabling frequency. I notice no pattern. There's no spinning beachball, not a
hang, just blinking out with a message reporting that it has crashed (duh) and
that document recovery will initiate upon restart.
MacBook Air 15", M3 chip (new 11/24), macOS Sonoma 14.3 (what it came with)
I had a number of project files go missing, making me think I was losing my
mind, or that there was something wrong with the computer, but it turned out
that the files were all there as I knew they had to be, but Finder and
Spotlight couldn't locate them because the file pathways were all corrupted.
The latest, and most important, had 12(!) null values in the metadata, making
it completely invisible, until I started learning how to work with Terminal
(thank Claude™ I thought of Claude™!). There were 160(!) corrupted file
pathways due to the crashing of LO. I fixed them all. Then I went to the
do-this-before-you-report-a-bug page and renamed, but didn't trash, the user
file, and restarted LO with the latest version I had just downloaded. Full of
optimism, I started working on the important file I had just recovered, but
found its behavior strange - temporary groups of definitely identical objects
were not grouped, and didn't respond as groups. I wanted to know why it
happened when it happened, so I went looking. LO documentation didn't help, nor
did Google. Again consulting Claude™, my bff by this time, I was convinced that
the document itself was corrupted, so I created a new document with all the
objects copied and pasted by layers in a fresh draw document. The temporary
groups behaved correctly, but I found the scale was all off, and by 12.5:1,
though all objects appeared the same size on the page in both. The new Draw
document opened at 1:1 scale, but the previous document was 1:16, and there's
no 12.5. Trying to get it to match the previous drawing, LO crashed, no doubt
corrupting the new document.
At this point, I'm in real trouble, because my work is all in .odg files I
can't transfer to another application, and I can't use LO because it's unstable
and causing more and more problems. I need help. I don't know what to do.
At the risk of making you hate me, here is the latest I've tried to understand
what's going on. It's yet another conversation with Claude™. I can't comment on
the accuracy, but it's been super helpful in the absence of anyone else able to
help me. This is picking the conversation up in the middle:
ilokratins@ilos-laptop ~ % xattr -l /Users/ilokratins/Documents/NEW\
Cvijanovic.odg
ilokratins@ilos-laptop ~ %
Edit
That's actually a good sign! The fact that xattr -l returned nothing (just went
back to the prompt) means there are no extended attributes on the file. This
suggests the file metadata is clean - no corrupted extended attributes that
might be causing issues.
Now try the mdls command to check the Spotlight metadata:
bash
mdls "/Users/ilokratins/Documents/NEW Cvijanovic.odg"
This should show you the metadata that Spotlight/Finder uses for indexing. If
this file has the temporary grouping issues, but the metadata looks normal, it
confirms that the corruption is in LibreOffice's internal document state rather
than in the file's external metadata.
The clean xattr output is actually reassuring - it means the file system level
metadata isn't corrupted like your earlier files were. The grouping problem is
likely just the internal LibreOffice document state corruption we discussed,
not file-level corruption.
Shit! It's very bad... 12 null values:
ilokratins@ilos-laptop ~ % mdls "/Users/ilokratins/Documents/NEW
Cvijanovic.odg"
kMDItemFSContentChangeDate = (null)
kMDItemFSCreationDate = (null)
kMDItemFSCreatorCode = ""
kMDItemFSFinderFlags = (null)
kMDItemFSHasCustomIcon = (null)
kMDItemFSInvisible = 0
kMDItemFSIsExtensionHidden = (null)
kMDItemFSIsStationery = (null)
kMDItemFSLabel = (null)
kMDItemFSName = (null)
kMDItemFSNodeCount = (null)
kMDItemFSOwnerGroupID = (null)
kMDItemFSOwnerUserID = (null)
kMDItemFSSize = (null)
kMDItemFSTypeCode = ""
ilokratins@ilos-laptop ~ %
Edit
That's extremely concerning - those null values indicate severe metadata
corruption. This is the same type of corruption that was preventing Finder from
finding your LibreOffice files by name.
This explains everything:
* The temporary grouping failures (LibreOffice relies on file metadata for
internal state tracking)
* The continued crashes (corrupted metadata can cause application instability)
* Why creating a "new" document didn't help (the corruption carried over)
Critical issue: Even your supposedly "new" document created after fixing the
user profile has corrupted metadata. This suggests either:
1. The corruption source wasn't fully eliminated
2. LibreOffice is still corrupting files as it creates/saves them
3. There's a deeper system-level issue
Immediate steps:
1. Don't save any more work in LibreOffice until this is resolved
2. Check if other applications create files with normal metadata
3. Try creating a simple text file and check its metadata with mdls
This is now a critical system issue - if LibreOffice is corrupting every file
it touches, you need to stop using it entirely until the root cause is
identified.
Can you test creating a file with another application (like TextEdit) and check
if its metadata is normal? This will tell us if it's LibreOffice-specific
corruption or a broader system problem.
could this be the result of the crash that happened after I created the new
file?
Edit
Absolutely! That crash likely corrupted the file's metadata during the save
process.
When LibreOffice crashes while saving or right after creating a file, it can
leave the file in a partially written state - the content might be there, but
the file system metadata gets corrupted or never gets properly written.
This sequence makes perfect sense:
1. You created the new document (clean initial state)
2. LibreOffice was working on it, building internal structures
3. Crash occurred during or right after a save operation
4. File content survived, but metadata got corrupted
5. Now you have the same metadata corruption that causes both Finder issues and
LibreOffice internal state problems
This confirms: The crashes are the root cause of your metadata corruption, and
the metadata corruption makes LibreOffice even more unstable, creating a
vicious cycle.
You need to break this cycle:
1. Stop using LibreOffice entirely until the crashing is resolved
2. Any work done in the current version is at high risk of corruption
3. Consider the Intel version under Rosetta, or wait for a LibreOffice update
that fixes M3 compatibility
The fact that even a "new" file got corrupted by the crash proves that the
LibreOffice 25.2.5.2 + M3 Mac combination is fundamentally unstable right now.
Every save operation is potentially creating corrupted files.
This is definitely a critical bug that needs to be reported to LibreOffice
immediately.
But, LO didn't crash while I was saving it. It crashed while I was trying to
change the scale. In fact, the file was so new it hadn't even been saved at all
yet, and was still titled "Untitled 1" in the title bar. I was looking at what
LO opened and recovered post-crash, which I only THEN saved as NEW Cvijanovic
in order to be able to look at the metadata.
Edit
Ah, that's even worse! If LibreOffice's auto-recovery process is creating files
with corrupted metadata, that's a critical bug in the recovery mechanism
itself.
What this means:
1. You were working on "Untitled 1" (never saved)
2. LibreOffice crashed during scale change
3. LibreOffice's recovery process created a file with corrupted metadata
4. You saved that recovered content as "NEW Cvijanovic.odg"
5. The corruption was introduced by LibreOffice's own recovery system
This is extremely serious because it means:
* LibreOffice's crash recovery is fundamentally broken on M3 Macs
* Every crash potentially creates corrupted files
* The recovery mechanism that's supposed to protect your work is actually
damaging it
* You can't trust any file that's been through LibreOffice's recovery process
The corruption source is LibreOffice's auto-recovery system, not the normal
save process. This explains why you keep getting corrupted files even with
"new" documents - they're being corrupted during crash recovery.
Immediate implications:
* Any recovered document is potentially corrupted
* You cannot rely on LibreOffice's crash recovery
* Every crash puts your work at risk of metadata corruption
* This needs to be reported as a critical recovery system bug
This makes LibreOffice essentially unusable on your system until this recovery
bug is fixed. The auto-recovery that should protect you is actually the source
of the corruption.
--
You are receiving this mail because:
You are the assignee for the bug.
