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.