To about 700MB size, netting 6mln lines of fascinating log information (if notepad++ is to be trusted with counting lines of files that have more lines it has chars in it's code:P).
It's probably fixed, since modified date is 2010-07-01, it's still bloody amusing.
I believe that you need full information, so I took to attach offending file (nope, even 6GB ram is not enough to do c&p in windows). Will post nice, rared up archive somewhere (compression ratio is pretty impressive:P).
Log itself looks like this:
Code: Select all
File "logging\handlers.pyo", line 73, in emit
File "logging\handlers.pyo", line 147, in shouldRollover
ValueError: I/O operation on closed file
Traceback (most recent call last):
File "logging\handlers.pyo", line 73, in emit
File "logging\handlers.pyo", line 147, in shouldRollover
ValueError: I/O operation on closed file
Traceback (most recent call last):
File "logging\handlers.pyo", line 73, in emit
File "logging\handlers.pyo", line 147, in shouldRollover
ValueError: I/O operation on closed file
Traceback (most recent call last):
File "logging\handlers.pyo", line 73, in emit
File "logging\handlers.pyo", line 147, in shouldRollover
ValueError: I/O operation on closed file
Traceback (most recent call last):
File "logging\handlers.pyo", line 73, in emit
File "logging\handlers.pyo", line 147, in shouldRollover
ValueError: I/O operation on closed file
Traceback (most recent call last):
File "logging\handlers.pyo", line 73, in emit
File "logging\handlers.pyo", line 147, in shouldRollover
ValueError: I/O operation on closed file
Traceback (most recent call last):
File "logging\handlers.pyo", line 73, in emit
File "logging\handlers.pyo", line 147, in shouldRollover
ValueError: I/O operation on closed file....multiplied few million times.
It's quite noteworthy, that adding datestamps would make it so much more useful.
In this particular case it's going to be fix_by_deletion, but I'm curious if the bug was squashed in the past and what could have caused it.
