Firefox freeze when attaching/opening pdfs (round 2)

There is another forum topic dealing with Firefox freezes that have been linked to pdfinfo/pdftotext. See

This discussion is about Firefox freezes which do not involve pdfinfo and seem to be related to locking code either in Firefox or Zotero.

I was able to reproduce a freeze 100% of the time with a new installation on an Ubuntu box. Details:
Ubuntu 9.10 Karmic
2.6.31-22-generic #65-Ubuntu SMP Thu Sep 16 16:21:34 UTC 2010 x86_64 GNU/Linux
Zotero 2.0.9
Zotero OpenOffice Plugin 3.0.a8
OpenOffice 3.2.0

I created a dummy user, disabled the Ubuntu branding extension, and then installed Zotero and the Zotero OpenOffice Plugins. They are the only extensions installed.

Sequence to reproduce:
1) Attach pdf from local disk to a reference
2) Start OpenOffice Writer. Insert any citation from Zotero
3) Attach new pdf from local disk to a reference.

At this point Firefox hangs. It was reproducible 3/3 times. If I did not use the OpenOffice Plugin then I could reliably add/delete pdfs ad infinitum. I used strace to attach to Firefox and it is stuck waiting for a lock:
joe@tesseract:~$ strace -p17440
Process 17440 attached - interrupt to quit
futex(0x7f267153e60c, FUTEX_WAIT_PRIVATE, 1, NULL

I tried turning on the debug log in the advanced tab of Zotero preferences but was never able to capture a log. Each time I killed Firefox to resolve the freeze the log seems not to have been written.

pdfinfo and pdftotext were not installed. I tried installing them, but the problem persists. I removed both, and the frequency of freezes is no longer 100%. However, now I get a freeze if I try to read a pdf from within Zotero using "view file". I am not using a plugin to handle pdf files, so Firefox needs to call an external viewer each time to read the file.

I will try and capture and entire session under strace next and post to

Are there other simple things I could do to provide the correct debugging data to developers?
  • I can't generate a report ID for this bug, because I am required to kill the firefox process every time. I ran the entire firefox process under strace, but the resulting log is 13 MB. I can provide this to any developer who wants, but attaching it as a forum post is unreasonable.

    I have a slightly simpler way to reproduce the error.

    Steps to Reproduce:
    1) Start Firefox
    2) From a running OpenOffice Writer document insert a footnote. (I used the Zotero Quick Reference Guide)
    3) From Zotero, click "view file" on a citation with a pdf.

    The process is stopped at a FUTEX_WAIT as before.

    This seems to be something of a timing issue. When I ran the these steps under strace it did not fail the first time, but only the second time that I clicked on "view file".
  • I tried changing the hidden preference zotero.launchNonNativeFiles from false to true to have the O/S determine how to handle viewing a pdf. The results were the same freeze.
  • You can e-mail the strace to, as I noted in the other thread.
  • The end of real-time debug output may also be helpful—it might show at what point it's actually hanging.
  • Dan,

    Thanks for the suggestion about real-time console output. I've collected that log and will forward it to support along with the strace log.

    The last lines of that file may be interesting in that they reveal a deprecated function used by Zotero:

    zotero(3): Setting value!

    zotero(3): No editor yet

    zotero(3): Loading jar:file:///home/joe/.mozilla/firefox/5swhm5vt.default/extensions/!/content/zotero/tinymce/note.html

    zotero(3): getAttachmentMIMEType() deprecated -- use .attachmentMIMEType

    zotero(3): MIME type application/pdf can be handled by plugins
  • Additional configurations attempted:
    firefox-3.6.11, latest stable version, same result
  • All Zotero really does at that point is pass the file off to Firefox or the OS.

    Try the top section here:
  • I tried tho two solutions posted on the file_handling_issues page, but without success.

    I believe this issue is different from the one posted there. On that page, users were having trouble opening pdf files at all, or were getting them in the wrong viewer. I can open pdf files without problem from either the browser or Zotero. It is only after using the OpenOffice Plugin that the freeze occurs.
  • WORKAROUND #1: research style change

    This is a human workaround, rather than a code fix. Divide the writing process into two stages. In stage 1, research the Web, collect citations, read and review pdfs. In stage 2, write and add footnotes, but do not read any attached pdfs.

    This is actually not too cumbersome, although sometimes it might be useful after citing a paper to go and check that the quotation or number cited was right. Still, that can be done on a final review of the paper after all of the footnotes have been inserted.
  • I believe this issue is different from the one posted there.
    It is. But nobody has ever reported your issue, so this is just troubleshooting.
  • I've spent quite a bit of time trying to find and isolate a version that works, to no avail. All of the following still exhibit the freeze.

    Firefox: 3.5.14, 3.6.11, 3.6.12
    Kubuntu: 9.10, 10.04
    Zotero: 2.0, 2.03, 2.08, 2.09, 2.1b1
    Java: 6 update 20, 6 update 22

    My machine uses an x86_64 kernel. I also tried an i386 kernel on a different computer, although still running Kubuntu 9.04.
  • I've found an even simpler way to trigger the freeze.

    1) Start the Java VM, by visiting
    2) "View Snapshot" for a reference which contains an attached PDF.

    This fails 100% of the time for me.
  • I can't reproduce this—and, clearly, neither can most/all of the many other Zotero users on Linux—so I'm afraid you're likely going to need to debug this yourself.

    What version of the Java plugin do you have in Firefox? What are you using to view PDFs? Have you tried using a different viewer? (With launchNonNativeFiles set to true, all Zotero does is launch the PDF via the OS, so the PDF viewer in Firefox shouldn't really be relevant.)

    Can you reproduce this in a new Firefox profile?
  • Also, what's the output of this:

    cat /etc/mailcap | grep application/pdf
  • edited November 4, 2010
    Moreover, if you run the Java test and then run the command displayed by the above command manually in a terminal window (substituting the filename as necessary), does it freeze?
  • Hi zotnomad,
    I just wanted to make sure that this isn't due to the pdfinfo and pdftotext. These are not actually plugins in the way that Firefox normally handles them - they are installed by Zotero and live in the Zotero directory in your Firefox profile. They will not be listed in the Tools->Add-ons list.

    To check if they are there, go to your your Zotero library folder (it looks like it would be in /home/joe/.mozilla/firefox/5swhm5vt.default/zotero/ based on your posts) and see if there are two executables named pdfinfo and pdftotext there. If there are, delete them, restart Firefox, and re-test.

    I was having the same problem as you and discovered that this was my issue - the "plugins" were travelling around with my Zotero library.
  • sethmg: Opening PDFs, which this thread is about, doesn't have anything to do with pdfinfo and pdftotext. The other thread is about saving PDFs.
  • I tried a whole matrix of different versions of the OS, Firefox, Java, and Zotero which I wrote up in my note on Nov. 1st. Since none of the tests worked, I have reverted to the latest stable versions of everything:
    Firefox 3.6.12
    Zotero 2.0.9
    Java 6.22 from Sun
    Java Plugin 1.6.0_22 from Sun
    Kubuntu 9.04 on x86_64
    Kernel 2.6.31-22-generic #68-Ubuntu SMP

    I have also tried a number of different viewers including okular, Adobe Reader plugin, Adobe Reader standalone (acroread), and the text editor gvim. It opens in all of them correctly, unless I have started the Java VM by visiting the Java test page. I have tried toggling the launchNonNativeFiles setting between true and false, but it made no difference. The only odd thing was that the debug log on console had the following with the option set to true:
    --- Log Start ---
    zotero(3): getAttachmentMIMEType() deprecated -- use .attachmentMIMEType

    zotero(3): MIME type application/pdf cannot be handled natively
    --- Log End ---
    This is incorrect because the OS can launch a pdf viewer and does from a file browser such as Konqueror or Dolphin. In this case, Zotero fell back to launching the application through Firefox and I got the reader specified there rather than the one specified for the OS.

    This bug is reproducible with a new profile. I have also created a brand new user and the bug is still there. I have removed the entire ~/.mozilla directory several times and each time I can re-install Zotero and reproduce the bug.

    The only entry in /etc/mailcap for application/pdf is:
    application/pdf; okular '%s'; nametemplate=%s.pdf; test=test "$DISPLAY" != ""

    I do not keep a ~/.mailcap file so there are no overrides to the system file. I have deleted mimetypes.rdf several times. I also installed a file at ~/.local/share/applications/defaults.list per kb:file_handling_issues but it seems to be ignored.

    sethmg: Thank you for your concern. I'm certain this issue is separate from the pdfinfo one. I've deleted the entire firefox directory several times which kills everything in Zotero's storage area. Also, when starting Zotero I get the following on the debug console:

    zotero(3): pdftotext-Linux-x86_64 not found -- PDF indexing disabled

    I'm rather at a loss as to what to test next. Perhaps it's a Debian or Ubuntu library issue, which means a different distro might work. It's a stretch but maybe KDE is a problem, since firefox is using the GTK widget set. The only thing that seems slightly out-of-the-ordinary was the NonNative file launching not working.
  • it's not an Ubuntu issue. Many of us run Zotero on Ubuntu and I cannot reproduce your error (on Ubuntu 10.04, but I've never experienced that error on earlier versions either) and it doesn't look like many others can. Kubuntu is rarer, so there is a small chance it's KDE.
  • zotero(3): MIME type application/pdf cannot be handled natively
    --- Log End ---
    This is incorrect because the OS can launch a pdf viewer and does from a file browser such as Konqueror or Dolphin.
    That's just a Zotero message meaning the file can't be handled by Firefox itself and there's no plugin installed.
    The only entry in /etc/mailcap for application/pdf is:
    application/pdf; okular '%s'; nametemplate=%s.pdf; test=test "$DISPLAY" != ""
    OK, and did you try running that manually after starting the JVM, as I suggested?

    It occurs to me that we may have gotten overly sidetracked by the viewing issue, since you reported that this happens attaching a file as well. So the hang may be from something before the launch attempt (which would explain why it happens for a plugin view too). What're the last couple lines of debug output before a freeze when you try to attach a PDF?
  • Unbelievable, but this is tied to the difference between Kubuntu and Ubuntu. I downloaded Ubuntu 10.04 onto a USB stick and ran that as a LiveCD and it worked every time. The issue is not with Zotero, but with Firefox and how it handles mimetypes. At least on GNOME-based systems, Firefox seems to check the files defaults.list, mailcap, and mimeinfo.cache to find a suitable helper application. On Kubuntu 9.04, at a minimum, it behaves differently. The KDE Desktop uses mimeapps.list instead of defaults.list, but Firefox checks neither defaults.list or mimeapps.list. And if there is an entry in one of the mailcap files (/etc/mailcap, ~/.mailcap) for mimetype application/pdf then the bug is triggered.

    1) Delete all references to 'application/pdf' in /etc/mimecap, ~/.mimecap
    2) Use Edit->Preferences->Applications in Firefox to choose a new helper application for PDF files. Do not select one of the options, but enter the direct path to the application you desire such as /usr/bin/acroread or /usr/bin/okular.
Sign In or Register to comment.