Zotero makes Firefox hang on some pages

nalimilan
Since I've upgraded a few packages on my Fedora 20 64-bit system yesterday, Firefox hangs when going to some sites. One of them is http://www.springerlink.com/content/k02227tgg457h1x6/

I've noticed that disabling Zotero (version 4.0.17.1) fixes the problem. And indeed all the problematic sites are scientific articles, most likely exporting meta-data.

I have taken a stack trace of Firefox during the hang:
https://bugzilla.mozilla.org/attachment.cgi?id=8377200

Any idea where the problem may come from? I can post the list of the packages I've upgraded if you think it may help to find the culprit. I can also do testing. Thanks!


https://bugzilla.mozilla.org/show_bug.cgi?id=973654
  • dstillman
    We'll take a look, but just as a note, Zotero issues should never be reported to Mozilla — they should only be reported here. When Zotero issues are caused by actual bugs in Mozilla, Zotero developers will post to Bugzilla with the relevant technical details.

    In any case, you should generate real-time debug output for such a hang, if you can, to see if Zotero is actually doing something, and either post the output somewhere (e.g., a gist) and link to it or email it to support@zotero.org with a link to this thread.
  • nalimilan
    Thanks. The problem is, while two days ago I was suffering from this hang all the time, now that I need to debug it it's gone. I'll tell you when/if I'm able to reproduce it.
  • nalimilan
    Ah, I finally managed to reproduce the hang with the debug logs enabled:
    http://pastebin.com/ssZdCB3d
  • dstillman
    What kind of hanging are you seeing, exactly? There's nothing obviously wrong in that output.
  • nalimilan
    The kind of hanging which make the software hang. ;-) Nothing special about it, Firefox does not respond and eventually need to kill it (which is suggested by my window manager). There's plenty of details in the stack trace:
    https://bugzilla.mozilla.org/attachment.cgi?id=8377200
  • dstillman
    Right, but I mean approximately how many seconds are we talking?
  • dstillman
    Oh, you're killing the process? So you're saying that's the end of the debug output you posted? In other words, it's hanging after this?
    zotero(3)(+0000000): Proxies: Retrieving IPs

    zotero(3)(+0000002): Proxies: Performing reverse lookup for IP 172.16.22.148

    zotero(3)(+0000000): Proxies: Sent reverse lookup request
  • dstillman
    And that would suggest that this goes away if you disable proxy redirection in the Proxy pane of the Zotero preferences?
  • dstillman
    Simon knows the details, but it looks like we're doing a blocking DNS call, so if something — a firewall rule, say — is blocking UDP DNS requests to 8.8.8.8 (Google's DNS servers), this might cause Firefox to hang until the request times out. Hopefully we can change this to be asynchronous in a future version, but check your firewall rules.
  • nalimilan
    Yeah, I need to kill it, I've never seen it become reactive again after the hang. But I've not waited for more than a few seconds.

    I've seen the hang when connected to two different networks, and it appeared after a system upgrade, so I'm inclined to think it's not related to firewall rules. But now I'm home I'm no longer able to reproduce the bug, at least at the moment, so I cannot check. I'll also try disabling the proxy (I think I tried that but I'm not sure now).

    How long would it take to time out? It would be interesting to wait and see whether Firefox comes back to life.
  • nalimilan
    I've been able to reproduce the hang once on a different network today, but then my second attempt succeeded. So there's really something non-deterministic going on. Once Zotero has done the reverse lookup, will it run it again after each restart of Firefox, or does it cache it somewhere?

    Do you have an idea of how I could send UDP requests to 8.8.8.8 similar to the ones Zotero emits?
  • dstillman
    You can try dig:

    dig 172.16.22.148 @8.8.8.8
  • nalimilan
    Thanks! Indeed, once out of about 10-20 attempts, dig takes about 5 seconds to return a result. What's weird is that it reports the lookup only took a few ms. And the Firefox hang lasts more than 5 seconds.

    $ dig 172.16.22.148 @8.8.8.8
    ; <<>> DiG 9.9.4-P2-RedHat-9.9.4-11.P2.fc20 <<>> 172.16.22.148 @8.8.8.8
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 65306
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 512
    ;; QUESTION SECTION:
    ;172.16.22.148. IN A

    ;; AUTHORITY SECTION:
    . 1493 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2014030400 1800 900 604800 86400

    ;; Query time: 45 msec
    ;; SERVER: 8.8.8.8#53(8.8.8.8)
    ;; WHEN: mar. mars 04 11:42:28 CET 2014
    ;; MSG SIZE rcvd: 117
  • dstillman
    I believe 5 seconds is the default DNS timeout on most Linux systems, so I'd guess that it's retrying after 5 seconds and succeeding. The Zotero code is making a raw socket connection, so it probably has a different default timeout (if it has one at all) — this isn't my code, so I don't know the details. We should certainly fix the timeout (and also make the request asynchronous), but the root issue is that some of your DNS requests are failing.

    In any case, turning off proxy redirection would be the temporary fix.
  • dstillman
    I've created a ticket for adding a timeout.
  • nalimilan
    OK. I've managed to see Firefox hang and then come back to life after a few seconds once, so maybe there's indeed a timeout. I'll try to see this again, but I think I've also waited for longer than that without luck.

    I'll have to investigate why DNS lookups are failing on my system after the upgrades, but using dig sounds like much easier to debug an report than telling Fedora developers to install Zotero and restart Firefox twenty times. :-)
Sign In or Register to comment.