clearerr called on NULL FILE* ?

Chad Austin chad at
Wed May 10 15:56:19 CEST 2006

Sorry to respond to myself; I wanted to give an update on this crash.  It turns 
out it's a race condition with multiple threads accessing the same Python file 

Python-dev thread at

I wrote about the experience at 
  I agree that our program was incorrect to be writing to a log on one thread 
while it rotated them on another, but it'd be nice to get an exception that 
unambiguously shows what's going on rather than having random crashes reported 
in the field.


Chad Austin wrote:
> Hi all,
> My first post to the list.  :)  I'm debugging one of our application 
> crashes, and I thought maybe one of you has seen something similar 
> before.  Our application is mostly Python, with some work being done in 
> a native C++ module.  Anyway, I'm getting a memory access violation at 
> the following stack:
>      ExceptionRecord: 0x0012e518
>          ExceptionCode: 0xc0000005 EXCEPTION_ACCESS_VIOLATION
>          ExceptionFlags: 0x00000000
>          ExceptionAddress: 0x7c901010
>          NumberParameters: 2
>              ExceptionInformation[0]: 0x00000000
>              ExceptionInformation[1]: 0x00000034
>          ExceptionRecord: 0x00000000
> THREAD ID: 10b0    frame count: 4
> PYTHON23!0x000baa00 - PyFile_Type
> PYTHON23!0x0003ac27 - PyFile_SetEncoding
>    MSVCRT!0x00030a06 - clearerr
>     ntdll!0x00001010 - RtlEnterCriticalSection
> Here's my understanding:  something is getting called on a PyFileObject 
> where f_fp is NULL, and clearerr in the multithreaded runtime tries to 
> enter an invalid critical section.  It looks like PyFile_SetEncoding in 
> the stack, but I can't figure out how in the Python source how 
> SetEncoding calls clearerr.
> Based on the timing of the crashes, I also think it might have something 
> to do with log rollovers in RotatingFileHandler.
> Has anyone run into something similar?  I don't expect anyone to spend a 
> lot of time on this, but if there are any quick tips, they would be 
> greatly appreciated...
> We're using Python 2.3.5 and Visual C++ 6.
> --
> Chad Austin

More information about the Python-list mailing list