Upgrade StorageSome citations crash Firefox
In one particular word-processed file of about 8,000 words and heavy citation, some of my Zotero citations cause Firefox to crash: Firefox will then hog all CPU and needs to be force-quit.
The offending citations work fine in any other document, and one temporary solution to the problem consisted in breaking the document into two parts, both of which were then fine. To merge the two parts again, I needed to identify and remove the offending citations.
So here's a group of citations that will crash Firefox if inserted into this document. The same citations work fine if inserted into any other document, or indeed the troubled document broken up into two parts.
A database check reveals no corruption.
Thanks for any suggestions on how to fix this issue.
Vital stats: Zotero 2.0.3, OOo 3.1.1, Firefox 3.5.9, Ubuntu 9.10
The offending citations work fine in any other document, and one temporary solution to the problem consisted in breaking the document into two parts, both of which were then fine. To merge the two parts again, I needed to identify and remove the offending citations.
So here's a group of citations that will crash Firefox if inserted into this document. The same citations work fine if inserted into any other document, or indeed the troubled document broken up into two parts.
A database check reveals no corruption.
Thanks for any suggestions on how to fix this issue.
Vital stats: Zotero 2.0.3, OOo 3.1.1, Firefox 3.5.9, Ubuntu 9.10
Simon, as mentioned, when I break the document into two parts, the problem goes away, so to come up with the smallest document fragment that produces the problem, I would probably need to remove all the copy and leave the citations in. I'd also need to send you the database for you to reproduce the problem, as the crash occurs when I'm trying to insert any one of a small number of citations that will misbehave in this particular context.
As a test, I chose one troubled citation in the final few paragraphs of the chapter, then selected everything further up in the document, dropped it into a text editor and then copied and pasted it back into the document. With all of the prior citations thus removed, I tried inserting the citation that would otherwise crash Firefox, and it went in without a hitch.
Creating a fresh Zotero entry for a misbehaving citation, then going back to the full unmodified document and trying to insert the fresh instance of the citation instead of the known miscreant resulted in another crash.
I then decided to log a crash incident in debugging mode. The log turned out to have reams and reams of "SELECT A.itemId" and "SELECT N.itemID" towards its end:
(5)(+0000000): SELECT A.itemID, value AS title FROM itemAttachments A NATURAL JOIN items I LEFT JOIN itemData ID ON (fieldID=110 AND A.itemID=ID.itemID) LEFT JOIN itemDataValues IDV ON (ID.valueID=IDV.valueID) WHERE sourceItemID=? AND A.itemID NOT IN (SELECT itemID FROM deletedItems)
(5)(+0000000): Binding parameter 1 of type int: 9579
(5)(+0000001): SELECT N.itemID, title FROM itemNotes N NATURAL JOIN items WHERE sourceItemID=? AND N.itemID NOT IN (SELECT itemID FROM deletedItems)
(5)(+0000000): Binding parameter 1 of type int: 9579
(5)(+0000000): SELECT A.itemID, value AS title FROM itemAttachments A NATURAL JOIN items I LEFT JOIN itemData ID ON (fieldID=110 AND A.itemID=ID.itemID) LEFT JOIN itemDataValues IDV ON (ID.valueID=IDV.valueID) WHERE sourceItemID=? AND A.itemID NOT IN (SELECT itemID FROM deletedItems)
(5)(+0000000): Binding parameter 1 of type int: 7275
(5)(+0000000): SELECT N.itemID, title FROM itemNotes N NATURAL JOIN items WHERE sourceItemID=? AND N.itemID NOT IN (SELECT itemID FROM deletedItems)
(5)(+0000000): Binding parameter 1 of type int: 7275
(5)(+0000000): SELECT A.itemID, value AS title FROM itemAttachments A NATURAL JOIN items I LEFT JOIN itemData ID ON (fieldID=110 AND A.itemID=ID.itemID) LEFT JOIN itemDataValues IDV ON (ID.valueID=IDV.valueID) WHERE sourceItemID=? AND A.itemID NOT IN (SELECT itemID FROM deletedItems)
(5)(+0000001): Binding parameter 1 of type int: 12481
The Debug ID is D1240430265.
To test the hypothesis that year suffix disambiguation lies at the bottom of this, I removed a bunch of the author's citations from that year, then attempted to add the formerly miscreant citation from the same year -- which promptly went in.
So this is beginning to look like a bug report. Year suffix disambiguation doesn't scale up beyond YYYYaz. Could you fix this?
maybe someone can test this on the new processor?
For the time being it might make sense for you to switch to a style without disambiguation to prevent crashes.
var lastDisambiguate = "az";
var newDisambiguate = "";
var charCode = lastDisambiguate.charCodeAt(lastDisambiguate.length-1);
if(charCode == 122) {
newDisambiguate = lastDisambiguate.replace(/z+$/, "");
var consecutiveZs = lastDisambiguate.length-newDisambiguate.length;
if(newDisambiguate.length >= 1) {
var nonZCharCode = lastDisambiguate.charCodeAt(newDisambiguate.length-1);
newDisambiguate = newDisambiguate.substr(0,newDisambiguate.length-1);
newDisambiguate += String.fromCharCode(nonZCharCode+1);
for(i=0;i<consecutiveZs;i++) {
newDisambiguate += "a";
}
}
else {
newDisambiguate = lastDisambiguate.replace(/z/g, "a");
newDisambiguate += "a";
}
}
else {
// next lowercase letter
newDisambiguate = lastDisambiguate.substr(0,lastDisambiguate.length-1);
newDisambiguate += String.fromCharCode(charCode+1);
}
> I don't think this will be fixed in the current plugin, as a new one is
> being rolled out
Is there a target release date for the new plugin or for a public beta of it?
Rintze:
> Mea culpa
Well, never mind. Do you share Adamsmith's assessment that there won't be a maintenance release of the old plugin with this bug fixed?
there is a (n almost) daily public trunk release for testing (and testing only!)
http://www.zotero.org/support/dev/svn_and_trac_access
Zotero devs have in the past either not given target release dates or have been off significantly - for 2.1. the former is the case and I wouldn't expect any reliable eta - from how things look on trac my guess would be sooner rather than later, but that's about as reliable as you're going to get.
Devs have said that the current csl implementation is no longer developed&maintained, so I'm pretty sure I'm right about that, especially since yours is a very, very rare usage case and not a crucial fix.
Fair enough.
Thanks.
I'll try to get some debugging information, but since the insert multiple citations dialog doesn't allow me to select multiple items, it's a bit of a pain.
If the fix in the 2.0 branch is just adding a line "var i;", then perhaps that could still get committed to the 2.0 branch. The old processor is not being actively maintained, but that doesn't mean that user-submitted patches will be automatically rejected. Then anark could use the 2.0 development XPI and keep on working.
Instructions:
http://www.zotero.org/support/dev/modifying_zotero_files
The line to change:
https://www.zotero.org/trac/browser/extension/branches/2.0/chrome/content/zotero/xpcom/csl.js#L2461
Original line
for(i=0;i<consecutiveZs;i++) {New line
for(var i=0;i<consecutiveZs;i++) {> you're probably better off trying the change in your local Zotero 2.0.3 copy
Let's see, I edited /content/zotero/xpcom/csl.js to:
if(newDisambiguate.length >= 1) {var nonZCharCode = lastDisambiguate.charCodeAt(newDisambiguate.length-1);
newDisambiguate = newDisambiguate.substring(0,newDisambiguate.length-1);
newDisambiguate += String.fromCharCode(nonZCharCode+1);
for(var i=0;i<consecutiveZs;i++) {
newDisambiguate += "a";
}
Then rebooted the system and tried to insert another citation into the big document. Firefox crashed.
52 items (correct): 53 items (problem already starts after 2008b):
In a world where monographs and research papers are the smallest citable entities, 52 refences for the same author within the same years does seem excessive and one "should never have this situation", I agree.
However, we don't live in that world any longer. In my particular case, the 52+ references are mostly blog posts.
It seems like a terrible thing to do to your reader.
Any Chicago-style (it seems in your case note would be better than full note) will handle this without problem and the reader actually has an idea what the citations mean - the rational behind author-date, after all, is that a reader from the same field will often know what a citation like "Smith 1776" refers to - clearly that's not the case for what you're writing.
Even if you have to use author-date for whatever reason, you should consider adapting your citation practice (e.g. by referring to individual blogposts by date in-text or so).
After all, if you're living in an entirely different world it seems appropriate to adjust your citation practice to that alternate reality.
> 53 items (problem already starts after 2008b)
Erratic reference sorting has been a problem before. Maybe the fix that was adopted at the time doesn't play well with the upper reaches of year suffix disambiguation?
Ajlyon wrote:
> I went ahead and tried to replicate this using the Zotero trunk, which is
> using the new citeproc-js engine, and OpenOffice crashed on me.
Have you filed a bug report?
If it's the former, then a style that substitutes the post title might be appropriate?
I almost exclusively use author-date styles, and I also often work with historical manuscripts, and I've never had more than 10 or so duplicate author-year, even in a dissertation or book.
YMMV of course, but just thought I'd ask the question.
Thanks for raising this. In fact, I had largeish year-suffixes in mind when I wrote the code that generates them in the new processor. It's a tricky problem, actually, because a system of counting by letter-sequences doesn't have a zero. It seems like nothing (!), but it becomes an issue when rolling over to the next digit. Not sure whether that's what's affecting the current processor, but the citeproc-js suffix generator will work with three or four hundred items without any problem. However ...
Identifying groups of entries that need a suffix assigned to them is another story. A 52-item test case built to mimick anark's requirements turned up a bug in the citeproc-js disambiguation code, and when that was fixed, the test took over a minute to clear. Ouch.
This was clearly unacceptable, so I put some time in yesterday to rewrite the processor's disambiguation code (which had grown extremely wooly and hard to manage). That's now done, all existing test cases clear, and the 52-item citation clears in about 2 seconds on my (very slow) netbook.
It will take awhile for these revisions to work their way into the development trunk, but when 2.1 arrives it should handle use cases like this just fine.
Fbennett, thanks for fixing this in the new processor. I really appreciate the effort!
How can I tell the programme that it should work like "aa,ab,...,az,ba,bb,...,bz,...,za,...zz" relating the suffixes?
Thanks for any help!
For the developers to be able to reproduce the issue, you might need to state what exactly your setup is.
Do you would like to have a look into the citation style editor? Or do you need any more information?
What happens when you switch from "Zeitschrift für Soziologie" citation format to one of the default author-date formats that ship with the English version of the software, such as American Psychological Association (APA)? Does the problem persist?
As mentioned above, using APA I haven't had any problems with any of this for years. If you can get your citations to work in APA as well, the bug is likely to be in the "Zeitschrift für Soziologie" citation style rather than in Zotero's rendering engine.