Please sign in to comment.
don't return a LogIterator on a broken handle
It might happen that we can't read from the logfile (and e.g. only append to it, which is the case on reasonable tuned SELinux systems). So in that case, we would return a LogIterator with a broken handle, that would then end up in an endless loop when trying to read from the logfile and a) spam the logfile (tons of messages written to it) and b) hog the cpu, as it's in an endless loop. This happens for example in lib/Log/LogIterator.php when trying to seek through the file within next(), as the position never comes to an end. Throwing an exception stops the endless loop before it begins and would give the possibility for upper layers to treat it appropriately. Though at the moment we just keep having a spinning wheel forever in admin interface's logging section. But at least no hogged cpus and spammed logs anymore... While working on the patch I saw #34 and it looks like, we also might have had a solution there, but nevertheless I think a LogIterator shouldn't even be created with an invalid handle.
- Loading branch information...