Are you using the latest FireFox build, 3.0.4?

By "crash" do you mean a real crash—as in, Firefox quits unexpectedly—or is there an error message?

It might not really be hanging. If you have the PDF converter tools installed, it may just be indexing the imported PDF. Currently, this can look like a hang with a large PDF, particularly with slower computers, though you should hear disk activity. I haven't seen any conflict with Quartz.

You might want to run Zotero with debug output enabled to see if it's actually doing anything.

Cherry:

[JavaScript Error: "uncaught exception: [Exception... "Component returned failure code: 0x8052000b (NS_ERROR_FILE_CORRUPTED) [mozIStorageStatement.execute]" nsresult: "0x8052000b (NS_ERROR_FILE_CORRUPTED)" location: "JS frame :: chrome://zotero/content/xpcom/fulltext.js :: indexWords :: line 250" data: no]"]"

Use the DB Repair Tool. Assuming you originally upgraded from Firefox 2, which had database instability problems, this shouldn't happen again.

Cherry,

The phrase "DB Repair Tool" in Dan's post is a link. Click it and it takes you to a page that explains how to use it.

Hi there,
Zotero worked well for a while but started to crash again like above when I add documents (either online or from HD). Sometimes it works (i.e. usually when I have the debug output on!) but often it freezes. I can email the debug to someone because it's too big to insert here. I've included only the end of it below.
Thanks,
Emmanuel


zotero(5): SELECT creatorTypeID AS id, creatorType AS name FROM itemTypeCreatorTypes NATURAL JOIN creatorTypes WHERE itemTypeID=? ORDER BY primaryField=1 DESC, name

zotero(5): Binding parameter 1 of type int: 33

zotero(3): Notifier.trigger('add', 'item', [15934]) called [observers: 3]

zotero(4): Calling notify() on observer with hash 'J7'

zotero(4): Calling notify() on observer with hash 'Ph'

zotero(4): Calling notify() on observer with hash 'l5'

zotero(5): SELECT sourceItemID FROM itemAttachments WHERE itemID=15934

zotero(5): SELECT creatorTypeID AS id, creatorType AS name FROM itemTypeCreatorTypes NATURAL JOIN creatorTypes WHERE itemTypeID=? ORDER BY primaryField=1 DESC, name

zotero(5): Binding parameter 1 of type int: 33

zotero(5): Beginning DB transaction

zotero(3): Beginning Notifier event queue

zotero(5): SELECT linkMode, path FROM itemAttachments WHERE itemID=15934

zotero(5): SELECT mimeType FROM itemAttachments WHERE itemID=15934

zotero(5): SELECT charsetID FROM itemAttachments WHERE itemID=15934

zotero(5): SELECT linkMode FROM itemAttachments WHERE itemID=15934

zotero(3): Running pdfinfo "/Users/emmanuelfreudental/Documents/readings/zotero/storage/15934/Niermann and Patel - 1991 - HITEC a test generation package for sequential ci.pdf" "/Users/emmanuelfreudental/Documents/readings/zotero/storage/15934/.zotero-ft-info"

T

I'm experiencing this same problem after switching to a Mac: anytime I am attaching a PDF (either automatically when adding a citation, or manually by using the add attachment feature) I get the "beach ball of death" and have to force quit. Generally when I restart, the PDF is in fact attached there.

I thought it might be my "Tab Kit" or "Firefox PDF Plugin for Mac OS X" plugins given what was said above, so I disabled them, but the problem persists.

My error report is : 374519186

There was mention of PDF indexing as the problem above, but I don't know how to disable that.

I would love to get this working, since this makes using Zotero not an option for me at all.

Thanks,

Dean

I am having the same general problem. In some detail:

I only get a problem when I try to attach a PDF file (as far as I can tell) or drop it into the zotero contents window. The symptoms are that the spinning colorful wheel apperas, Firefox is thus "hung" and unresponsive, and I have to Force Quit. Otherwise, both programs are functioning fine. The interesting thing is that after I quite Firefox and restart, zotero will have attached the PDF file (only when I attach; otherwise it doesn't show up if I drop it into contents or something similar).

I am using Firefox 3.0.5 on a MacBook with Tiger 10.5.6 and zotero 10.0.9. I have very items in my library (about 10) so this is not an issue of things going slowly because of too many items to index or whatnot.

I ran firefox in debug mode (i.e. from a terminal) when trying to attach a file and the last line of output is

zotero(3): Running pdfinfo "/Users/sohrab/Documents/References and papers/LDA+U.pdf" "/Users/sohrab/Library/Application Support/Firefox/Profiles/d44fhovv.default/zotero/storage/12536/.zotero-ft-info"

I then suspended it and looked about. The only process it has spawned (seen via "ps") is a child called psinfo-MacIntel which is zombied (Z state) and thus hanging. My guess is this is the problem?

More generally, my guess is that here is some PDF indexing issue. How can I disable pdfinfo from launching?

My problems are now serious: I though reindexing would help. So I cleared index cache and tried to reindex, but now the reindexing (from Preferences) hangs (with color wheel) and restarting gives me no index. So I have no index anymore! Help!!!

It may be an issue with our modified version of pdfinfo (which, unlike the original version, saves output to disk). We'll look into it (unless someone else wants to take a look).

In the meantime, if you're having this problem, you could try deleting pdfinfo from the Zotero data directory. Zotero won't have data on the number of pages in PDFs but (I believe) should still index them.

Dan Stillman: Thanks! deleting pdfinfo from my data directory seems to have fixed the hanging problem.

Previously, Firefox would hang as described by others in this thread. PDFs do indeed still seem to be indexed (can search for and find unique terms), though Zotero is a bit confused and lists the Indexed stat as "Unknown" even after manually selecting the "Reindex" icon.

Firefox 3.0.6, Zotero 1.0.9 OSX 10.5.6

Just another datapoint:

Running zotero 2.0.3, firefox 3.5.9 on ubuntu 9.10 (karmic); pdfinfo and pdftext are 3.02pl1.

I had this (or at least a similar) problem: when I added a PDF file to zotero it (firefox+zotero) hung with the "Saving item..." popup. Then I had to manually kill firefox. On restart, the PDF file was present in zotero, but attempting to index it or to retrieve metadata for it again caused a hang.

I tried a wide variety of tests without success; but eventually, moving the pdfinfo and pdftotext binaries out of the zotero directory (in firefox profile), restarting firefox, and reinstalling the binaries (from within zotero) seemed to fix it. This was surprising, as the re-installed binaries exactly matched the ones I moved out; and the previous binaries executed fine "standalone". So the binaries themselves did not seem to be corrupt; rather, something seemed to change in the way zotero invokes them when I deleted and reinstalled.

Note that before deleting these binaries, I already checked for updates of them from within zotero, and was (correctly) told they were up to date; despite this, it seems that I needed to remove them and reinstall...

I know this all sounds very unlikely, or even impossible...; maybe there is some crazy race condition in the synchronization between parent and offspring processes such that just having pdfinfo/pdftotext physically elsewhere on the disk was enough to tweak it away... who knows (certainly not I ...).

(My route to resolution involved first trying the removal of pdfinfo and pdftotext as a workaround; that did indeed "work" in the sense that firefox+zotero no long hung, but at a cost of losing PDF indexing and retrieval of PDF metadata. I was ready to stop then - I really could not see any way that re-installing pdfinfo and pdftotext could help, since those original binaries were not corrupt and worked "standalone"; but just tried the re-install to be sure, and what do you know, everything started working again...)

Anyway, it took several hours of my time before I finally got to this resolution, so I'm posting here in case it will be helpful to somebody else...

Dan asks:

Were you actually getting it every time before?

Yes: every single action that I tested, that involved either pdfinfo or pdftotext, caused a hang. It was very consistent. As I mentioned, I first suspected some issue specific to the particular PDF file; but I tried two independent files with no change in behaviour.

[removal of pdfinfo and pdftotext is] not the recommended workaround. As I note above, the recommended workaround is removing just pdfinfo, which means you lose some metadata but indexing still works.

I did try that at one point - though not all that carefully. The problem was that I was getting a hang not just on invocation of pdfinfo but also on pdftotext - so, in my particular case, it did not seem to be possible to retain indexing. But of course, others' mileage may vary (especially if this is a subtle timing issue).

Anyway, thanks for the response. I appreciate that it is difficult to do much about when it is so hard to reproduce. Maybe there is some scope to add additional debug output in the code that invokes/syncs with pdfinfo/pdftotext? That might help shed some more light if it happens again.

Unfortunately, the proposed solution does not work on my installation (Ubuntu 10.4, Firefox 3.6.6, Zotero 2.0.3, pdfinfo 3.02pl1, pdftotext 3.02pl1). I deleted the binaries and did a re-install of pdfinfo & pdftotext, but Firefox still hangs approximately 1 of 3 times when pdf's are indexed. (I should add, maybe, that I use a custom Zotero-path.)

Thanks! But I wonder: Is your advice to remove pdfinfo _without_ reinstalling it? And does that imply that PDFs will not be indexed then?

Thanks again! I can confirm both that indexing still works and that number of pages is indeed left out. (Sorry for not reading the earlier discussion carefully enough.)