@dstillman - thanks

From terminal:

Missing chrome or resource URL: chrome://zotero/skin/16/white/loading.svg
/home/research/Zotero_linux-x86_64/zotero: line 20: 59120 Segmentation fault (core dumped) "$CALLDIR/zotero-bin" -app "$CALLDIR/app/application.ini" "$@"

zotero-debug.txt is 36,249 lines.

@qallunaat: Was it working on this computer previously? What version? What happened between then and now?

Does the same thing happen with the Zotero beta?

I've been experiencing this for a long time, too, starting sometime around 7.0.10, however that was too long ago to be sure (many months at least). I did not have time to properly debug this, so even had to switch to using a Windows version in the meanwhile, hoping it will resolve itself over time. It didn't, so I spent some time debugging and below are the points, hopefully helpful. I can do further troubleshooting if needed.

Here's how it looks like:

1) The crash is very consistent and 100% repeatable, happens at the same address in libxul.so. It's enough to just start Zotero and wait for a bit (order of 10 to 30 seconds), clicking collection names or entries in collections seems to speed it up a bit. Zotero seems to do some initialization at the beginning, with some CPU activity, and then crashes with SIGSEGV: "Thread 1 "zotero-bin" received signal SIGSEGV, Segmentation fault.".

2) It seems like my particular Zotero data directory contents triggers this, and only on Linux (Fedora 41 and 42, XFCE, to be specific). Windows works fine and never exhibited this problem.

3) The data dir is synchronized using simple file copy. Database integrity checks always pass.

4) Creating new profile and attaching the same data dir doesn't help. Using Safe Mode doesn't help. Creating new profile, with empty storage dir, and populating it with randomly collected items does not reproduce the problem.

5) Using the current 7.1 beta does help in my case too - no issue observed. Moreover, opening the same data dir with 7.0.22 afterwards seems to not exhibit the problem any more. EDIT: the second sentence is not really true, that was a sporadic "no crash" that I also observed once under the GDB but considered a fluke. So while 7.1 beta reproducibly does not crash, the 7.0.22 reproducibly crashes even on that same data/profile afterwards.

6) I managed to get some relatively meaningful stack trace (I can send the full one as needed, let me know, small snippet below, though it seems to be mangled by the website's input sanitizationTIL it's DokuWiki!), and the crash seems to be related to a known signature [1], and there is some non-trivial underlying issue covered in the following BZ entries: [2], [3], [4], with the latter two still open.

What else can I do to help debugging and fixing this?


Thread 1 (Thread 0x7ffff7e89780 (LWP 14619) "zotero-bin"):
#0 mozilla::CycleCollectedJSContext::CleanupIDBTransactions (this=0x7fffe9d3e000, aRecursionDepth=<optimized out>) at /builds/worker/checkouts/gecko/xpcom/base/CycleCollectedJSContext.cpp:452
localQueue = {<nsTArray_Impl<mozilla::CycleCollectedJSContext::PendingIDBTransactionData, nsTArrayInfallibleAllocator>> = {<nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_RelocateUsingMemutils>> = {mHdr = 0x7ffff6fe2900 <_pt_root>}, <nsTArray_TypedBase<mozilla::CycleCollectedJSContext::PendingIDBTransactionData, nsTArray_Impl<mozilla::CycleCollectedJSContext::PendingIDBTransactionData, nsTArrayInfallibleAllocator> >> = {<nsTArray_SafeElementAtHelper<mozilla::CycleCollectedJSContext::PendingIDBTransactionData, nsTArray_Impl<mozilla::CycleCollectedJSContext::PendingIDBTransactionData, nsTArrayInfallibleAllocator> >> = {<detail::nsTArray_CopyDisabler> = {<No data fields>}, <No data fields>}, <No data fields>}, static NoIndex = 18446744073709551615}, <No data fields>}

#1 mozilla::CycleCollectedJSContext::AfterProcessMicrotasks (this=0x7fffe9d3e000) at /builds/worker/checkouts/gecko/xpcom/base/CycleCollectedJSContext.cpp:523
runnable = {mRawPtr = <optimized out>}

#2 mozilla::CycleCollectedJSContext::PerformMicroTaskCheckPoint (this=0x7fffe9d3e000, aForce=<optimized out>) at /builds/worker/checkouts/gecko/xpcom/base/CycleCollectedJSContext.cpp:649
raiiObject677 = {mCategoryString = 0x5555555a69c3 <malloc+355> "M\205\344\017\204\263\032", mMarkerName = 0x60 <error: Cannot access memory at address 0x60>, mCategoryPair = {mCategoryPair = 3287885568}, mInnerWindowID = {<mozilla::detail::MaybeStorage<unsigned long, true>> = {<mozilla::detail::MaybeStorageBase<unsigned long, true>> = {mStorage = {val = 15087974807078774528, dummy = 0 '\000'}}, mIsSome = 56 '8'}, <mozilla::detail::Maybe_CopyMove_Enabler<unsigned long, true, true, true>> = {<No data fields>}, <No data fields>}}
aso = {mIsMainThread = 101, mScriptActivity = {<mozilla::detail::MaybeStorage<xpc::AutoScriptActivity, false>> = {<mozilla::detail::MaybeStorageBase<xpc::AutoScriptActivity, false>> = {mStorage = {val = {mActive = 149, mOldValue = 90}}}, mIsSome = 85 'U'}, <mozilla::detail::Maybe_CopyMove_Enabler<xpc::AutoScriptActivity, false, true, true>> = {<No data fields>}, <No data fields>}}
restore = {mLocation = <optimized out>, mValue = <optimized out>}
didProcess = <optimized out>
currentDepth = <optimized out>

#3 0x00007fffefa395d7 in mozilla::CycleCollectedJSContext::BeforeProcessTask (this=0x7fffe9d3e000, aMightBlock=<optimized out>) at /builds/worker/checkouts/gecko/xpcom/base/CycleCollectedJSContext.cpp:486

#4 XPCJSContext::BeforeProcessTask (this=0x7fffe9d3e000, aMightBlock=<optimized out>) at /builds/worker/checkouts/gecko/js/xpconnect/src/XPCJSContext.cpp:1444

#5 nsThread::ProcessNextEvent (this=0x7ffff7893200, aMayWait=true, aResult=0x7fffffffb79f) at /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:1145

<...>


[1] https://crash-stats.mozilla.org/signature/?signature=mozilla::CycleCollectedJSContext::CleanupIDBTransactions&amp;date=>=2025-01-26T22:14:00.000Z&amp;date=<2025-07-26T22:14:00.000Z&amp;_columns=date&amp;_columns=product&amp;_columns=version&amp;_columns=build_id&amp;_columns=platform&amp;_columns=reason&amp;_columns=address&amp;_columns=install_time&amp;_columns=startup_crash&amp;_sort=-date&amp;page=1

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1443429

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1509341

[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1513582

Thanks for following up. Fair enough, I wonder if it *is* fixed, though. Given no root cause and the plausible upstream bug not yet fixed, it may simply be that it's not triggering, just yet. However I also understand that with limited resources and in these circumstances it's more reasonable to wait and see if it resurfaces in 7.1.

What's the plan for getting it out of beta? I unfortunately can't switch to beta as a daily driver just yet.