Menu
▾
▴
1 Attachments
#1430 Crash in webkit when displaying URL icon
When importing ISI WOK references by use of the Web Of Science ISI search group, bibdesk 1.6.1 (including latest nightly builds) crashes after around 2-3 successful imports. It happens only when displaying the ISI WOK URL icon on the right sidebar. Turning off the sidebar solves the problem. Christiaan Hoffman suggests that this is related to the webkit functionality. Please find the crash report included to this ticket.
Reto
The problem is not with the import itself. It's a problem with the display of the URL icon. So it has to do with the downloaded data. So please report the offending item, in particular the remote URL.
There is unfortunately no specific offending item. Even the same URL sometimes works and sometimes not. The URL's are however always ISI WOK pages. When It would thus be interesting to hear if this symptom has ever been seen by other users.
Even if it is intermittent, I still need at least one URL to be able to reproduce. If I cannot reproduce it, I certainly cannot do anything about it.
http://apps.webofknowledge.com/InboundService.do?UT=A1995RR75900003&IsProductCode=Yes&mode=FullRecord&product=WOS&SID=S1UoXh7jPpcR6nmLHxH&smartRedirect=yes&SrcApp=PARTNER_APP&DestFail=http%3A%2F%2Fwww.webofknowledge.com%3FDestApp%3DCEL%26DestParams%3D%253Faction%253Dretrieve%2526mode%253DFullRecord%2526product%253DCEL%2526UT%253DA1995RR75900003%2526customersID%253DTROpenURL%26e%3DsXgYAu6PECe0dwaCRL0Yw00VTA5ixCiY7oPvDIP7u7UMMkHmwKg3A9tgp2oBo4tA%26SrcApp%3DPARTNER_APP%26SrcAuth%3DTROpenURL&action=retrieve&Init=Yes&SrcAuth=TROpenURL&customersID=TROpenURL&Func=Frame
This is the last citation when issuing a search with TS="regional hydrological applications"
R KEMMERS. Ecohydrological systems-analysis - theory and practice. Eurasian Soil Science, 27:12–18, 1995.
Re-opening BibDesk, searching for it again, worked fine. I have one guess:
WOK has lately implemented a so-called Throttle-Server, which does not allow for more than 5 searches within 5 minutes. It could be (though I have no communication log) that bibdesk can retrieve the search list, but when you click on the item and it then tries to display the associated URL, WOK simply returns an error instead of the URL content. How about that?
This Throttle Server is in place for some Universities like ETH in Zurich where I am located.
Thanks. I can also not reproduce any problem with this URL tough.
When the server returns an error that certainly is not a reason to have a crash. It should just give a blank screen.
Do you have more crash reports? From the stack trace, this looks to me like a heap corruption bug elsewhere, or possibly a bug in WebKit. It's crashing while setting up a fresh webview, which is a pretty innocuous operation, and not specific to a given link.
2 more crashreports attached. They all look pretty much the same. I'm accessing the internet/WOK through a proxy server.
Reto
Indeed, as I also indicated before, looks like a WebKit bug. Which means we cannot do anything about it, unfortunately.
Ok, close the ticket.
The workaround for this webkit bug is not to open the sidebar (and thus not to display the URL content) ... which is fine ;-)
Another thing you can do is set the hidden default FVWebIconMaximumNumberOfWebViews to 0. While BibDesk is not running, typethe folliwing in Terminal.app:
defaults write -app BibDesk FVWebIconMaximumNumberOfWebViews -int 0
This works even better. Now I can have the PDF preview but not the crashing URL preview.
thanks a lot! (and now you can close the bug ticket).
I wish to add to this, since BD also crashed to me under similar circumstances that Reto describes. However, again it is an intermittent problem and the crash is not reproducible. Doing exactly the same after a relaunch, all works fine and as expected. Yet, these crashes during import occur now since weeks frequently enough so that I see a need to report on it.
My suspicion is that it has little to do with the location from which to import. Rather any import, whether importing from WOK ISI or from another currently open BibDesk file. For instance I had a crash during importing a publication when drag/dropping it from a downloaded (export citation) file, such as a nature12350.ris file as can be downloaded from this site http://www.nature.com/nature/journal/v500/n7462/full/nature12350.html or bibtex-citations.bib, a file generated by a Science website, e.g. http://www.sciencemag.org/content/341/6142/1236361. In all these cases drag dropping the publication from the temporary download bib file to my main BibDesk bibliography resulted in a crash. Thus my suspicion is that during any import one may get a crash of BibDesk.
The crash reports from both aforementioned examples plus the involved temporary bib files are attached. However, my main BibDesk bibliography file is not included in the zip archive, since it is way too large.
I have observed this behavior since several weeks with several latest nightlies consistently. The most recent used being Version 1.6.1 (2953) (BibDesk-20130812.dmg).
Cheers,
Andreas
Andreas, is a crash with the files you included reliably reproducible? There are two very different crash reports. One is in WebKit, the other (drag-and-drop) is in the Obj-C message dispatch machinery.
Dear Adam,
Yes, both types of crashes (import from pubmed or ISI WOS or drag/drop from one bib file to another) occur regularly. In case of not fully reproducible crashes, here the case, I do never report a bug unless I have encountered the same problem many times and after several clean restarts (still possible with Snow Leopard, ;-) ) and otherwise making sure all is as it should, yet getting the crash.
Perhaps I should have filed the drag/drop crash as another bug, yet it seemed to me to be related to what Reto originally reported.
Now, the two crash reports were both created during a drag drop operation (I missed out on saving previous crash reports for the reasons given above and sent them only via Apple).
They indeed show different routines where the exception occurred, yet from what I did, it was in both cases dragging a pub from one file to another. I am not aware of any difference between the two states, except I could not say whether I had prior to the operation saved my main BibDesk bib-file or not. I regularly do a Cmd-S to minimize risks of losing work because of these frequent crashes, meaning I do not always remember everything perfectly.
Any idea whether there is really nothing one could do from the side of BibDesk to circumvent these annoyingly frequent crashes? Since it seems not only to occur in the Webkit, there may be another memory problem involved here? Moreover, I fear Apple will never fix the Webkit, pretty sure not for Snow Leopard. Except for Microsoft programs, and now BibDesk during imports, other applications are very stable on my system.
Regards,
Andreas
ETH Zurich
Prof. Dr. Andreas Fischlin
Systems Ecology - Institute of Integrative Biology
CHN E 21.1
Universitaetstrasse 16
8092 Zurich
SWITZERLAND
andreas.fischlin@env.ethz.chandreas.fischlin@env.ethz.ch
www.sysecol.ethz.chhttp://www.sysecol.ethz.ch
+41 44 633-6090 phone
+41 44 633-1136 fax
+41 79 595-4050 mobile
On 17/08/2013, at 05:06 , Adam Maxwell wrote:
Andreas, is a crash with the files you included reliably reproducible? There are two very different crash reports. One is in WebKit, the other (drag-and-drop) is in the Obj-C message dispatch machinery.
[bugs:#1430]http://sourceforge.net/p/bibdesk/bugs/1430/ Crash in webkit when displaying URL icon
Status: open
Created: Tue Jul 30, 2013 07:38 PM UTC by Reto Stockli
Last Updated: Fri Aug 16, 2013 02:42 PM UTC
Owner: nobody
When importing ISI WOK references by use of the Web Of Science ISI search group, bibdesk 1.6.1 (including latest nightly builds) crashes after around 2-3 successful imports. It happens only when displaying the ISI WOK URL icon on the right sidebar. Turning off the sidebar solves the problem. Christiaan Hoffman suggests that this is related to the webkit functionality. Please find the crash report included to this ticket.
Reto
Sent from sourceforge.nethttp://sourceforge.net because you indicated interest in https://sourceforge.net/p/bibdesk/bugs/1430/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Related
Bugs:
#1430Hi, I've the same issues.
The strange thing is, I disabled the preview panel in the main window.
The preview in the "Get Info" view works perfectly. No crashes there.
So what's the big difference between them?
Thanks a lot in advance.
The preview panel in the main window is not the same as the right sidebar.
Regards,
Andreas
On 29/10/2013, at 15:00 , MartinN wrote:
Hi, I've the same issues.
The strange thing is, I disabled the preview panel in the main window.
The preview in the "Get Info" view works perfectly. No crashes there.
So what's the big difference between them?
Thanks a lot in advance.
[bugs:#1430]http://sourceforge.net/p/bibdesk/bugs/1430/ Crash in webkit when displaying URL icon
Status: open-wont-fix
Created: Tue Jul 30, 2013 07:38 PM UTC by Reto Stockli
Last Updated: Mon Sep 09, 2013 05:19 PM UTC
Owner: nobody
When importing ISI WOK references by use of the Web Of Science ISI search group, bibdesk 1.6.1 (including latest nightly builds) crashes after around 2-3 successful imports. It happens only when displaying the ISI WOK URL icon on the right sidebar. Turning off the sidebar solves the problem. Christiaan Hoffman suggests that this is related to the webkit functionality. Please find the crash report included to this ticket.
Reto
Sent from sourceforge.nethttp://sourceforge.net because you indicated interest in https://sourceforge.net/p/bibdesk/bugs/1430/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Related
Bugs:
#1430This seems to have worsened a lot on Mavericks 10.9, so it will be disabled by default on that system.
It'll be interesting to see if some other crash takes its place; WebKit really seems like a red herring to me. Until someone comes up with a way to reproduce it, though, it's hard to say. It might be worth looking at static analyzer output in detail.