Upgrade StorageZotero Error Report - nr. 526018063 - Zotero in Windows 7 SP1 amd64
Hello,
I'm running Zotero in Windows 7 (SP-1 amd64) with Windows 7 installed within a virtual guest environment on a FreeBSD OS (FreeBSD 11.2-RELEASE-p8, amd64). The virtual guest for the Windows 7 instance has approximately 6 GB RAM, four processors, and approximately 5 GB of unallocated storage space available to it, at this time.
This morning, while I was editing a note in my private Zotero archive, Zotero presented a message, "An error has occurred. Please restart Zotero," within the application main window.
After selecting the "Report Errors" option, in the Help menu in the menubar, this was then accompanied with a dialogue window presenting an option for reviewing an application log and submitting it to zotero.org. After reviewing and submitting the application log, a dialogue window was presented with the issue tracking code, 526018063.
I'm not sure if it may be any manner of a reproducible error. To my recollection, it's the first time I've seen Zotero "Crash," in any such way. In the nearest guess I can possibly imagine as to how it occurred, perhaps it may have had anything to do with the operating system being in any ways potentially resource-starved? I happen to have a number of Chrome browser tabs open, right now. Moreover, there may seem to be something of a memory leak that usually occurs, with such a thing, with Chrome on numerous platforms. So, possibly this may have affected the performance of Zotero as an application -- whether or not per se affecting it in terms of available RAM, but possibly affecting it in ostensibly deterministic effects. Of course, this is only a guess, if it may have anything do with the Chrome process' resource usage, per se.
This Chrome issue, perhaps, it may have been to any effect of why the message, "Operation timed out," has occurred in the Debug Output log for this Zotero application session. At the least, Chrome seems to add a certain latency to the desktop environment -- all the more so, when it's been running for a few hours.
To try to clear up the resource issue, I can store the browser tabs with the Fresh Start add-on for Chrome and restart Chrome, shortly. The Zotero application might then have some more resources available in the OS environment, to work with.
In the top message presented in the Debug Output log, I'm seeing the text, 'JavaScript Error: "No matching references found,' four times. I'm afraid it's not clear as to where this error is occurring. Perhaps there may be way to debug this JavaScript, with any available Firefox debugging tools?
The message about "No matching references" occurs after a message from an IndexedDB process, such that the latter message points to a source file, ActorsParent.cpp (line nr. 18877, it seems). The full text of that error message, then, is as follows;
[JavaScript Error: "IndexedDB Maintenance finished with error: NS_ERROR_NOT_AVAILABLE: ActorsParent.cpp:18877"]
Preceding that, in the Debug Output, there are a small number of other JavaScript Error messages -- namely, the two 'Operation Timed Out' messages and then three of a "Type Error: cs is null" for one button.xml file -- such that, in a guess, the file might represent an XUL resource. This Zotero session has been running for a few hours, so those might have occurred a lot earlier, before this application issue.
Candidly, I think this presents an interesting opportunity to learn a little more about the architecture of the Zotero stand-alone application. Although I'm still curious as to how the codebase has been adapting since Firefox developers removed xulrunner from their revision-head at mozilla-central, obviously the Zotero project has not been too far put off by their decision as such.
Interestingly enough, xulrunner might also be used somewhere in the Eclipse Standard Widget Toolkit -- though this, of course, might serve to present another set of topics entirely, as perhaps concerning any manner of portability for applications, if not also concerning the characteristics of BSD operating system environments. Concerning Zotero on FreeBSD, I'd been looking at the Chromium Embedded Framework (CEF) though -- candidly -- I was a little put-off by the characteristics of the Python-driven build system for Chromium and CEF, as to how it could allow for any normal porting for the same, pursuant to any applications. Of course, there's also the memory-leak thing in Chrome. It seems that it may be a fairly non-trivial issue to debug, entirely, across all of Chrome's own rendering framework, and the V8 JavaScript engine, and any other proverbial moving parts in a Chrome distribution.
Insofar as concerning the Eclipse platform -- though it might be widely far apart to this application issue -- perhaps there may be another viable route towards portability, there. Of course, if there was any manner of a Zotero interface for the Eclipse platform, then it would add the overhead of the JVM to the application runtime.
At the time when this application issue was presented, I was editing a note in a stand-alone window in Zotero, using the HTML editor in Zotero -- such that this HTML editor might be provided with tinyMCE.
Happily, I was able to continue editing the note, even after the application issue occurred, whereby there was the message, "An error has occurred. Please restart Zotero."
Candidly, I regret that Firefox has abandoned xulrunner. I'm glad that Zotero development is continuing, however. I hope I'll be able to figure out how to port it to FreeBSD, ideally in a full build-from-source approach, non-trivial though that could be.
This application issue is a minor thing, I think, but I wanted to pass along this description anyway.
I wouldn't want to dominate the forums with any concerns as to any ideas for how Zotero can be ported to FreeBSD. Insofar as Zotero can run in Microsoft Windows and it's possible to install Microsoft Windows -- I'm using an old Dreamspark disc for this, candidly -- to install Microsoft Windows in VirtualBox, perhaps there's a certain utility to it, though I'm afraid that this approach would fall short of complete portability.
I'm running Zotero in Windows 7 (SP-1 amd64) with Windows 7 installed within a virtual guest environment on a FreeBSD OS (FreeBSD 11.2-RELEASE-p8, amd64). The virtual guest for the Windows 7 instance has approximately 6 GB RAM, four processors, and approximately 5 GB of unallocated storage space available to it, at this time.
This morning, while I was editing a note in my private Zotero archive, Zotero presented a message, "An error has occurred. Please restart Zotero," within the application main window.
After selecting the "Report Errors" option, in the Help menu in the menubar, this was then accompanied with a dialogue window presenting an option for reviewing an application log and submitting it to zotero.org. After reviewing and submitting the application log, a dialogue window was presented with the issue tracking code, 526018063.
I'm not sure if it may be any manner of a reproducible error. To my recollection, it's the first time I've seen Zotero "Crash," in any such way. In the nearest guess I can possibly imagine as to how it occurred, perhaps it may have had anything to do with the operating system being in any ways potentially resource-starved? I happen to have a number of Chrome browser tabs open, right now. Moreover, there may seem to be something of a memory leak that usually occurs, with such a thing, with Chrome on numerous platforms. So, possibly this may have affected the performance of Zotero as an application -- whether or not per se affecting it in terms of available RAM, but possibly affecting it in ostensibly deterministic effects. Of course, this is only a guess, if it may have anything do with the Chrome process' resource usage, per se.
This Chrome issue, perhaps, it may have been to any effect of why the message, "Operation timed out," has occurred in the Debug Output log for this Zotero application session. At the least, Chrome seems to add a certain latency to the desktop environment -- all the more so, when it's been running for a few hours.
To try to clear up the resource issue, I can store the browser tabs with the Fresh Start add-on for Chrome and restart Chrome, shortly. The Zotero application might then have some more resources available in the OS environment, to work with.
In the top message presented in the Debug Output log, I'm seeing the text, 'JavaScript Error: "No matching references found,' four times. I'm afraid it's not clear as to where this error is occurring. Perhaps there may be way to debug this JavaScript, with any available Firefox debugging tools?
The message about "No matching references" occurs after a message from an IndexedDB process, such that the latter message points to a source file, ActorsParent.cpp (line nr. 18877, it seems). The full text of that error message, then, is as follows;
[JavaScript Error: "IndexedDB Maintenance finished with error: NS_ERROR_NOT_AVAILABLE: ActorsParent.cpp:18877"]
Preceding that, in the Debug Output, there are a small number of other JavaScript Error messages -- namely, the two 'Operation Timed Out' messages and then three of a "Type Error: cs is null" for one button.xml file -- such that, in a guess, the file might represent an XUL resource. This Zotero session has been running for a few hours, so those might have occurred a lot earlier, before this application issue.
Candidly, I think this presents an interesting opportunity to learn a little more about the architecture of the Zotero stand-alone application. Although I'm still curious as to how the codebase has been adapting since Firefox developers removed xulrunner from their revision-head at mozilla-central, obviously the Zotero project has not been too far put off by their decision as such.
Interestingly enough, xulrunner might also be used somewhere in the Eclipse Standard Widget Toolkit -- though this, of course, might serve to present another set of topics entirely, as perhaps concerning any manner of portability for applications, if not also concerning the characteristics of BSD operating system environments. Concerning Zotero on FreeBSD, I'd been looking at the Chromium Embedded Framework (CEF) though -- candidly -- I was a little put-off by the characteristics of the Python-driven build system for Chromium and CEF, as to how it could allow for any normal porting for the same, pursuant to any applications. Of course, there's also the memory-leak thing in Chrome. It seems that it may be a fairly non-trivial issue to debug, entirely, across all of Chrome's own rendering framework, and the V8 JavaScript engine, and any other proverbial moving parts in a Chrome distribution.
Insofar as concerning the Eclipse platform -- though it might be widely far apart to this application issue -- perhaps there may be another viable route towards portability, there. Of course, if there was any manner of a Zotero interface for the Eclipse platform, then it would add the overhead of the JVM to the application runtime.
At the time when this application issue was presented, I was editing a note in a stand-alone window in Zotero, using the HTML editor in Zotero -- such that this HTML editor might be provided with tinyMCE.
Happily, I was able to continue editing the note, even after the application issue occurred, whereby there was the message, "An error has occurred. Please restart Zotero."
Candidly, I regret that Firefox has abandoned xulrunner. I'm glad that Zotero development is continuing, however. I hope I'll be able to figure out how to port it to FreeBSD, ideally in a full build-from-source approach, non-trivial though that could be.
This application issue is a minor thing, I think, but I wanted to pass along this description anyway.
I wouldn't want to dominate the forums with any concerns as to any ideas for how Zotero can be ported to FreeBSD. Insofar as Zotero can run in Microsoft Windows and it's possible to install Microsoft Windows -- I'm using an old Dreamspark disc for this, candidly -- to install Microsoft Windows in VirtualBox, perhaps there's a certain utility to it, though I'm afraid that this approach would fall short of complete portability.
This is an old discussion that has not been active in a long time. Before commenting here, you should strongly consider starting a new discussion instead. If you think the content of this discussion is still relevant, you can link to it from your new discussion.