zotero makes firefox on openbsd lock up and freeze on startup

idoa

hello zotero people,
i'm using firefox 24 on openbsd (-current if it matters), and when installing zotero and restarting firefox i get nothing. when enabling debug i get the following messages:

zotero(3): Using data directory /home/idoa/.mozilla/firefox/emhvkmrl.default/zotero

zotero(3): IPC: Initializing pipe at /home/idoa/.mozilla/firefox/emhvkmrl.default/zotero/pipes/1380381801385

zotero(3): Loading in full mode

zotero(3): Opening database 'zotero'

---

and that's it. firefox is not dead, and can be killed gracefully, but zotero won't let it continue past this point. this happens regardless of:
1. other extensions - disabling everything else makes no difference.
2. whether or not it's a clean firefox profile or not, and whether there is already a zotero database present or not.
3. whether the zotero version is release (4.0.12) or trunk (from today).

i know zotero isn't officially supported on anything that's not windows, mac, or linux, but it did use to work deliciously for me in the past.
any ideas?

ido

dstillman

If you pass the -jsconsole flag, is there anything in the Error Console?

idoa

the console window appears, but does not get drawn and remains completely blank.

aurimas

I think you also need to set extensions.zotero.debug.log hidden preference. See http://www.zotero.org/support/debug_output#real-time_debug_output

If you can't get to about:config because Firefox freezes (though since you can see the debug log, I assume you can), you could change this preference in prefs.js in your Firefox profile directory.

idoa

oh, i did that. that's how i got the output above.
fwiw, 'top' shows that the last thing firefox tries to do is fdlock(), presumably on the db file (?)

dstillman

You might want to try unzipping the XPI, editing chrome/content/zotero/xpcom/db.js to set DB_LOCK_EXCLUSIVE to false, and then rezipping it. (Alternatively, you can run a Git installation.) You don't want to set that false if you use Standalone as well, but it's worth seeing if it fixes this problem.

idoa

sounds promising! i'll give it a try

idoa

ok, no, same thing. well, almost: now the firefox process state is 'idle' instead of 'sleep'...

idoa

unfortubately i can't build firefox with debug, due to hd space concerns on this laptop, but is there anything else i could try?

silpi

I can also confirm this on my system (5.5). Any information on getting this to work would be greatly appreciated. We are intending to roll out Zotero/Firefox/OpenBSD systems in schools in an African country. Any info on getting this to work would simply be great.

idoa

ok there's a way to make it work. you need to patch three files and rebuild the kernel, as per http://marc.info/?l=openbsd-cvs&m=139431928814340&w=2
this change was committed on march 8 but was later reverted for various reasons, so it's not in 5.5, but i've been patching my kernels with every upgrade (i follow -current so those tend to happen rather often) without any problems.

for your convenience, these are relevant revisions:
/sys/kern/kern_descrip.c 1.104 -> 1.105
/sys/kern/vfs_syscalls.c 1.202 -> 1.203
/sys/sys/filedesc: 1.25 -> 1.26

silpi

Thanks for the tip. However, I wonder if there is another way. This seems quite involved to do on an entire classroom of computers. We may just have to look at another reference manager until this gets fixed. We also tried building firefox as user idoa but ran into the same problem...the disk filled up before the compile could finish so it ended with errors.

idoa

well you can build one kernel and copy it to all the machines (assuming they're the same architecture). otherwise it'd be best to ask on the mailing list at misc@openbsd.org for the change to be committed again, or at least given more attention - although the developers don't like being told what to do, and they have a lot on their plate these days.

silpi

Its worth a try! True I guess asking the developers is a very last resort then. We will see what other options might exist for our specific use case. Thanks.