Last modified: 2013-05-02 17:51:33 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T47325, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 45325 - Loading of a Wikidata entry hangs while waiting for something and sometimes crashes
Loading of a Wikidata entry hangs while waiting for something and sometimes c...
Status: RESOLVED WORKSFORME
Product: Wikimedia
Classification: Unclassified
Wikidata (Other open bugs)
unspecified
All All
: High major with 1 vote (vote)
: ---
Assigned To: Wikidata bugs
https://www.wikidata.org/wiki/Q146
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-24 11:23 UTC by Nemo
Modified: 2013-05-02 17:51 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Timeline of the cat crash (150.53 KB, image/png)
2013-02-24 11:23 UTC, Nemo
Details
Firebug net and profiling top (149.40 KB, image/png)
2013-02-24 12:05 UTC, Nemo
Details

Description Nemo 2013-02-24 11:23:59 UTC
Created attachment 11834 [details]
Timeline of the cat crash

Usually it just takes forever, especially waiting for bits (on Firefox); but I've tried now with Chromium and it crashed completely ("whoops"): 23.0.1271.95 Built from source for Fedora release 17 (Beefy Miracle) (169798).

I don't know how to attach useful data, I made a screenshot of the timeline. U used "Cat" ([[wikidata:Q146]]) as example, the problem usually happens with bigger entries – I think –.
Comment 1 Nemo 2013-02-24 12:05:37 UTC
Created attachment 11835 [details]
Firebug net and profiling top

Note, comment 0 was as logged out and it's the same over HTTP.

When logged in, on Firefox, it would seem that there's something weird about the logo and stewards banner? Don't ask me to export profiling data, last time I tried it was a huge waste of time.
Comment 2 jeblad 2013-02-24 19:48:55 UTC
Wild guess, soomething goes wrong in decoding the data urls. How dos it crashes? A sigsegv?
Comment 3 Nemo 2013-02-25 08:55:14 UTC
(In reply to comment #2)
> Wild guess, soomething goes wrong in decoding the data urls. How dos it
> crashes? A sigsegv?

I don't know, I just saw the "whoops" page Chromium uses; Chromium is more picky than Firefox, so it might just have got sick of waiting.
Comment 4 Andre Klapper 2013-02-26 20:00:45 UTC
Nemo: Is this reproducible?

jeblad / Wikidata team: How to attach useful data?
Comment 5 Nemo 2013-02-27 08:47:05 UTC
(In reply to comment #4)
> Nemo: Is this reproducible?

I don't know what's "this", so I don't know how to reproduce. The symptoms, however, always happen to me when I open any Wikidata entry (maybe I'm opening only the wrong ones, no idea).
Comment 6 jeblad 2013-02-27 10:28:02 UTC
Try to clear out the browser cache, perhaps the problem goes away. Check if the problem repeat itself if you try to access the entries that has previously failed. Try to turn off all gadgets and see if the problem goes away.

I can't reproduce this at my machine, but I (and the rest in the team) don't use the community gadgets.
Comment 7 jeblad 2013-02-27 10:38:26 UTC
It doesn't seem like there is anything wrong with the cat-entry.
https://www.wikidata.org/w/api.php?action=wbgetentities&ids=q146
Comment 8 Nemo 2013-02-27 11:53:14 UTC
(In reply to comment #6)
> I can't reproduce this at my machine, but I (and the rest in the team) don't
> use the community gadgets.

I was logged out in Chromium, so gadgets can't be the problem.
Comment 9 Nemo 2013-05-02 17:51:33 UTC
I've not seen this lately, although I tried opening some huge entries now and then; tentatively closing.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links