Max DeLiso added the comment:
ok I checked in to this more deeply and I was wrong about a few things. first,
my patch is worthless - there are several more instances where the retval of
fileno is passed directly to fstat and that is totally valid (provided the
file* points to a valid file).
looking deeper in the call stack, this call stack is originating from a
PyCFunction_Call from mercurial's native extension, osutil.
# Call Site
00 MSVCR90!fstat64i32+0xe8
01 python27!dircheck+0x29
02 python27!fill_file_fields+0x18e
03 python27!PyFile_FromFile+0x89
04 osutil+0x176f
05 python27!PyCFunction_Call+0x76
Here's the code in osutil.c (which is part of mercurial)
(osutil.c:554)
#ifndef IS_PY3K
fp = _fdopen(fd, fpmode);
if (fp == NULL) {
_close(fd);
PyErr_SetFromErrnoWithFilename(PyExc_IOError, name);
goto bail;
}
file_obj = PyFile_FromFile(fp, name, mode, fclose); //this is the call
that is the parent
if (file_obj == NULL) {
fclose(fp);
goto bail;
}
PyFile_SetBufSize(file_obj, bufsize);
#else
fileno() is actually 'succeeding' and returning a value of 3.
fstat is then throwing the invalid parameter exception, presumably because 3 is
not a valid file descriptor.
the way fileno() is implemented in M$CRT is really simple: it just copies a
value at a fixed offset from the pointer passed to it without checking to see
if the FILE* is valid.
this is why in the docs for _fileno they say "The result is undefined if stream
does not specify an open file."
anyways, I don't think this is a bug in python, but rather in the mercurial
extension.
it's a little tricky to debug on windows because the osutil module gets
delay-loaded.
I'm taking another pass at it now.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18197>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
