https://bugs.documentfoundation.org/show_bug.cgi?id=172631
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from [email protected] --- Final update: I've now fully isolated the cause. After resetting my LibreOffice profile, I reinstalled every extension that was present in the crashing profile, one at a time, retesting the original trigger (Writer document with footnotes containing a Zotero citation → Zotero "refresh" → wait for AutoRecovery background save) after each one: 1. Zotero LibreOffice Integration — no crash 2. WritingTool (LanguageTool, Java-based) — no crash (this rules out the JVM/Java angle; the JVM signal handler in the original backtrace was only the messenger that turned a native fault into abort(), not the cause) None of the extensions present in the original crashing profile reproduce the issue on a clean profile. Comparing the old (crashing) profile against the fresh one, I found clear evidence of prior corruption: an extensions/bak/ directory dated the morning of 2026-06-30 (LibreOffice creates this when it rebuilds an out-of-sync extension registry), plus 5 backups of registrymodifications.xcu created within 27 minutes that same morning — consistent with a crash loop that left the extension registry/configuration in an inconsistent state. Conclusion: apparently, this was caused by local profile corruption (likely in the extension registry / uno_packages cache), not a reproducible bug in LibreOffice, Zotero's integration, or any of my extensions. I don't think this is actionable upstream as-is — feel free to close as WORKSFORME. Sorry for the noise, and thanks for reading this far in case the crash signature (exportTextFootnote + JVM signal handler catching abort during AutoRecovery) helps someone else triage a similar report. -- You are receiving this mail because: You are the assignee for the bug.
