Nasty intersphinx bug on windows ( 'invalid distance too far back' )

24 views
Skip to first unread message

Dougn

unread,
Sep 14, 2010, 4:42:26 PM9/14/10
to sphinx-dev
Man this was a hard one to track down.
Some of my object.inv files were not being loaded due to some odd zlib
error. This is on windows, python 2.6.1.

The problem? While the inventory file is being written in binary mode
for v2, it is being read in text mode in intersphinx.
Why is that an issue? Well it means that if the compressed stream
contains mungable characters (like \r\n or the special windows EOF
character) the data will be modified. And that is what is happening.
In my case it is finding the special EOF character that windows, in
its infinite wisdom and desire to have viruses, decided to implement
and keep around.

So I get a truncated inventory file on read.

The file is written in binary mode, and the '\n' is explicit so there
should not be OS line termination issues for version 2 of teh file,
but there will be for version 1. *sigh*

Bug is listed here:

http://bitbucket.org/birkenfeld/sphinx/issue/524/intersphinx-corrupt-objectsinv-due-to-zlib-issue-on

A patch is not too hard, but a regression test is much harder for me
to come up with. The inventory file in question has a bunch of work
proprietary information in it.

Has anyone else ran into this?

Georg Brandl

unread,
Sep 17, 2010, 4:09:36 AM9/17/10
to sphin...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 14.09.2010 22:42, schrieb Dougn:
> Man this was a hard one to track down.
> Some of my object.inv files were not being loaded due to some odd zlib
> error. This is on windows, python 2.6.1.
>
> The problem? While the inventory file is being written in binary mode
> for v2, it is being read in text mode in intersphinx.
> Why is that an issue? Well it means that if the compressed stream
> contains mungable characters (like \r\n or the special windows EOF
> character) the data will be modified. And that is what is happening.
> In my case it is finding the special EOF character that windows, in
> its infinite wisdom and desire to have viruses, decided to implement
> and keep around.
>
> So I get a truncated inventory file on read.
>
> The file is written in binary mode, and the '\n' is explicit so there
> should not be OS line termination issues for version 2 of teh file,
> but there will be for version 1. *sigh*
>
> Bug is listed here:
>
> http://bitbucket.org/birkenfeld/sphinx/issue/524/intersphinx-corrupt-objectsinv-due-to-zlib-issue-on

This bug is now fixed in 1.0.4, released just now.

Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAkyTIkAACgkQN9GcIYhpnLA7EgCfTc1x4oQ8dLbQyJ3fd8LVcTAn
53AAoKR7xSPB4OQNtYOSQHtuRIHLIQJ2
=Y8Yq
-----END PGP SIGNATURE-----

Reply all
Reply to author
Forward
0 new messages