[Python-3000] Py3k_struni additional test failures under cygwin

[Joe Smith]

"Joe Smith" <unknown_kev_cat at hotmail.com> wrote in message 
news:f8is94$tgh$1 at sea.gmane.org...
>
> "Guido van Rossum" <guido at python.org> wrote in message
> news:ca471dc20707181158p17417c9cg37c5382d61b53fe5 at mail.gmail.com...
>> On 7/18/07, Joe Smith <unknown_kev_cat at hotmail.com> wrote:
>>> >> I'm wondering if the recusion limit on my build is getting set too 
>>> >> low
>>> >> somehow.
>>> >
>>> > Can you find out what it is? sys.getrecursionlimit().
>>>
>>> Hmm...  It is a limit of 1000.
>>> That is probably large enough, no?
>>
>> Yes, that's what it is for me.
>>
>>> Anyway, from some basic testing it looks like marshal is always throwing
>>> that error when marshal.load() is called.
>>> However, marshal.loads() works fine.
>>>
>>> Might this be another encoding related error?
>>
>> Perhaps. Or something else. Do try to investigate.
>>
>
> What I have found is that (on CYGWIN) all of marshal seems to work fine
> except for marshal.load().
> marshal.dump()'s output can be read by 2.5's marshal.load() without 
> problem.
> 3k's marshal.load() will not
> load the data from 3k's marshal.dump or 2.5's marshal.dump()
>
> It turns out to be a fault due to an uninitialized value on a RFILE.
> Specifically, the following patch (part of marshal_load in marshal.c fixes
> things.
>
> -----BEGIN PATCH-----
> Index: Python/marshal.c
> ===================================================================
> --- Python/marshal.c    (revision 56620)
> +++ Python/marshal.c    (working copy)
> @@ -1181,6 +1181,7 @@
>                return NULL;
>        }
>        rf.strings = PyList_New(0);
> +       rf.depth=0;
>        result = read_object(&rf);
>        Py_DECREF(rf.strings);
>        Py_DECREF(data);
> -----END PATCH-----
>
> I'll submit the patch to sourceforge if needed, although the fact that all
> the other loading methods
> do set rf.depth=0 (including PyMarshal_ReadObjectFromFile) indicates to me
> that this is definately the correct patch.
> Looks like that line was accidentally forgoten.



With that patch, things on CYGWIN are getting close to matching the other 
platforms.

There are still some problems with the 'Python' directory for example. This 
is because of a change in the internals of Cygwin.
Cygwin does have "managed mounts" which allow for case sensitivity. 
Compiling Python inside a managed mount eliminates those issues.
So it is not a terribly big deal.

If I patch io.py to default to "utf-8" rather than using the filesystem 
encoding (ascii), that fixes a few more things. (test_coding.py and 
test_minidom.py)


Then there are only 2 test failures remaining that are not listed on the 
wiki. One of them is a very minor issue in test_platform.py.
The other is a more complicated problem with test_mailbox.py

First the test_platform problem.
sys.executable lacks the ".exe" suffix.  In order for libc_ver to work it 
would need to be passed the exe suffix.
The cygwin specific hack in the test_platform.py does not work if when using 
a managed mount because a managed mount is case sensitive, so 
isdir(executable) returns false.
(Using libc_ver with no arguments also fails for the same basic reason. 
(although there is no cygwin hack in that case.))   That said, using 
libc_ver on cygwin would not be meaningful because cygwin uses newlib 
instead of libc/glibc.




The mailbox.py problem seems troubling, I'm getting exceptions of type 
"IOError: [Errno 13] Permission denied" on "./@test" (aka. 
test_support.TESTFN) .

This is true for all tests after TestMbox's run of test_add(). All of 
TestMailDir works fine. TestMbox's test_add() works fine, but all the 
remaining tests that use "./@test" fail. Sounds like something is not 
getting cleaned up correctly. That said no "@test" file or directory is left 
behind after the end of the test.

(For whats its worth, Cygwin's python 2.5 (as installed on my system) fails 
2 of the tests in it's version of test_mailbox.py, both with "IOError: 
[Errno 13] Permission denied").