test_fileio fails on windows with MSVC "Debug Assertion failed" message
since last week.

Can you find out in which test case the assertion is triggered?
Also, is there more information in the error message itself?

I cannot test this because I don't have recent VC, but last week change
to _fileio.c is this.

http://svn.python.org/view/python/branches/py3k/Modules/_fileio.c?r1=70187&r2=70352

On windows, lseek was used before, but _lseeki64 in portable_lseek is
used now. Maybe does following patch work?

Index: Modules/_fileio.c
===================================================================
--- Modules/_fileio.c	(revision 70537)
+++ Modules/_fileio.c	(working copy)
@@ -682,6 +682,9 @@
 			return NULL;
 	}
 
+	if (!_PyVerify_fd(fd))
+		return NULL;
+
 	Py_BEGIN_ALLOW_THREADS
 #if defined(MS_WIN64) || defined(MS_WINDOWS)
 	res = _lseeki64(fd, pos, whence);

I'm afraid your patch doesn't solve it.

I got the same popup:

Debug Assertion Failed!
Program: .....\python_d.exe
File: f:\dd\vctoools\crt_bld\self_x86\crt\src\close.c
Line: 48
Expression: (_osfile(fh) & FOPEN)

It failed while running testErrnoOnClose.

I'm using VC 2008 Express Edition.

I wonder whether a magic assertion-disabling spell is needed around the
call to close() in _fileio.c. Kristjan, do you have any insights on this?

I intentionally don't covered all the places where a fd would be needed, 
only those where the fd was delivered through python.  It is possible 
that there is some new error that is causing e.g. a double close of a 
fd.
A few months ago, when I removed the assertions experimentally, I found 
a few such bugs, related to the new IO library.
I'll look into it...  I'll have to repro since there is no traceback.

It is not strictly speaking "an error" which is causing the double
close... It's the deliberate behaviour of a test I have added to check
that errno is correctly set on the raised IOError when calling close()
on a FileIO object whose handle has already been closed manually (with
os.close()).

In other words, since it is possible to retrieve the file descriptor of
an IO object using the fileno() method (and, moreover, it is possible to
give an existing file descriptor to the open() function so as to wrap it
inside an IO object), access to a closed file is always possible and
should be protected against (that is, it raises an IOError with the
errno attribute equal to EBADF).

You are right, if it is accessible from python, then we should guard 
against it.  The case I was referring to (I'm too lazy to find the 
revision) was that a python exception wasn't raised either, so a logic 
error fell through, but the assert found it.

Anyway, that's beside the point:  The point is that I can't repro this 
using the latest version of the py3k branch, running 
lib/test/regrtest.py test_fileio
Am I in the wrong place?

I stepped back to r70187 and got no assertion.
An update to r70349 result in an assertion.

So I reverted the changes in test_fileio.py of r70349 and got no assertion.

But the test should work without assertion.

I tested releases 2.6.1, 3.0.1 and current trunk with:
import os
f = open('test.test', 'w')
os.close(f.fileno())
f.close()

2.6.1 and 3.0.1 raised an Exception with Errno 9.
With current trunk I've got the MSVC assertion.

I can definitely reproduce the problem under a Windows XP virtual
machine using Visual C++ 2008 Express in debug mode. Here is a screenshot.

Unfortunately, I'm not a Windows programmer and I'm not able to produce
a patch for this. But the close() call in _fileio.c should certainly be
protected by whatever magic is necessary.

r69214 works with os.close(f.fileno());f.close() (Exception with Errno 9)
r69560 does not compile
r70152 test_fileio failed (different reason)
       MSVC Assertion with os.close(f.fileno());f.close()

I was not able to use _fileio.c from r69214 in cause of other dependencies.

Okay, I have fixed this in revision: 70579, by adding a test in the 
close_internal() function.

However, the (somewhat pathological) case:
f = open('test.test', 'w')
os.close(f.fileno())
f.close()
Shows that there are other ways to make it crash.  By calling read, for 
example, after the os.close().  Can you add further tests and find out 
the operations that can have similar results?

The fix is wrong, it doesn't raise an error when the fd is invalid...

Sorry, fixed in 70580.
But what other cases are there?
read? write? stat?

Basically, all FileIO methods should be protected (I'm not even sure why
you are asking! we can't let the interpreter crash rather than raise an
exception).
Someone has to write additional tests for those though, for now only
close() is tested.

I´ve written tests for the other cases, and fixed them.
See revision 70582

Closed as stated fixed in revision 70582.