Last modified: 2007-01-26 12:13:54 UTC
I have some problems with displaying uploaded djvu files. Most of the time it
works well but sometimes it crashes.
I have loaded up several djvu files
(http://commons.wikimedia.org/wiki/User:Joergens.mi#Transfer, 32 files total),
some of them (at least 3) cause the mediawiki SW to crash when you try to acces
the file on commons as you can see here.
Sometimes it helps to make a second upload, if you get chance to use the
interface, which gets corrupted by the upload.
If you acces the file from wikisource, you can download it, and it works (
http://de.wikisource.org/wiki/Orchideen ). The uploaded file itself seems to be ok.
If you try to access the commons descripton page by that way, the same problem
as with the direct commons access.
I tried to access a file on commons, from a unix station. No difference, same fault
Thank you for help
*Should* be fixed in r19651. Of course, if the file you've uploaded isn't well-formed XML, we
can't help that (but at least we should be able to look at it easily now).
I doesn't understand that because for the upload i simply use the
commons inteface, consisting of the following steps:
1.) first entering on the Browser the following line: http://
2.) the Information this file doesn't exist, you can upload it
3.) pressing on the link upload now
4.) copying the information template into the according box
5.) filling it with the according information
6.) selecting the according djvu-file on my local pc
7.) pressing upload
using this procedure, I didn't see any possibilty for me to generate
bad xml-code. the fault must be something else.
I understand yout that the r19651 is active on commons, I tried to
access the page bat the fault is still there.
The fix is not yet active. [[commons:Special:Version]] says that it's only updated to r19597 as of
As for how the original error arose, it seems like your Djvu file was malformed somehow. If it
wasn't, that's really a separate bug. The issue here is that MediaWiki shouldn't ever crash like
that. Once the fix is active I can pretty easily look to see what was causing the Djvu file to be
found invalid (probably some way to do it now too, I suppose, but I don't know it offhand and am
doing other stuff).
Thanks for this fast reply.
When I acces this djvu file from german wikisource it is fully
functional. It is used in the article
I can download it, and i can see the description I put to commons. to
see this you can use the url
The downloaded file can be fully accessed und read by the programms
irfanview Version 3.99 with djvu plugin and with DjVu Solo Version
3.1 (Lizardtech). That is the reason for me to think the djvu File is
completly correct. I've just tested it once again. (17:30 MEZ today )
This text is for giving you additional information an not to urge you
to act immediately. In my opinion, you're idea that this may be a
seperate bug is correct, an the fix mentioned above wont fix it.
DO NOT SET BUGS TO WONTFIX IF YOU ARE NOT DEVELOPING THE SOFTWARE.
WONTFIX INDICATES THAT WE WILL NOT APPLY THE REQUESTED FIX (EG, THE REQUEST WILL
NOT BE FULFILLED BECAUSE IT IS UNDESIRABLE, BOGUS, OR CANNOT WORK FOR SOME REASON.)
what shall I do to indicate, that the proposed solution ist not
working, the state resolved fixed isn't correct.
As you can see in Note 4 your hope that the djvu file is not well
formed, I disagree because I loaded this file from commons via
german wiki-source and the downloaded file works fine. All file
which have been loaded to commons by my person are done with DjVu
Please wait until the fix goes live. Then I'll take a look at the file to see what's wrong with it,
Fix is bogus; it looks in the wrong place (at very high level, leaving low-level
failures untouched) and instead of ignoring the error it just causes another
error in the process.
The root problem may be that the djvutoxml program needed to extract the
metadata is missing on several servers.
As a result, the metadata doesn't get properly loaded.
Then, the case where the data is missing is handled poorly at both low and high
levels, leading to the fun crashes:
* An empty metadata field is not handled properly as a miss case, as the object
ends up with serialize(array()) instead of '0' or ''
Additionally, this seems to result in a null metadata field getting saved, which
breaks MySQL 5 strict mode sometimes....
* Empty/null XML metadata is fed to SimpleXML instead of being calmly ignored.
Warnings are suppressed, but there's nothing to handle the exceptions (perhaps
new in later versions of php?) or deal with a missing/broken field if the
exception is found and cleaned up.
Fixed up the servers, and better lower-level fixes in r19668