[lxml-dev] Test failures on Windows

[Stefan Behnel]

Hi Sidnei,

Sidnei da Silva wrote:
> On Sat, Oct 28, 2006 at 10:05:14AM +0200, Stefan Behnel wrote:
> | You got me convinced. I think that's because we are using the context reusing
> | calls (xmlCtxt*). They require calling xmlCtxtReset afterwards to clean up
> | both the input stack and memory resources. This is normally called
> | automatically when using the parser context the next time (which is why there
> | never were any enduring side effects), but waiting for that has the temporal
> | side effect of leaving the input stream open when passing control back to the
> | user code.
> |
> | Now, the problem is, running xmlCtxtReset can currently segfault in some
> | cases, so we can't just call it carelessly. I played with it a bit to figure
> | out in which cases it can be called, but it doesn't look like we can safely
> | call it in every case where it would make sense. Guess I'll file a bug report
> | on it and try to come up with a work-around...
> 
> Erm.... did you look at the attached patch? It just frees ctxt->input
> if its not NULL. I guess you're looking for a generic fix though.

Not only generic. Pending open files is only a symptom here. The real problem
is that none of the resources allocated for parsing is freed before you call
the parser again (in which case new resources will be allocated right away).

So popping the input streams fixes the windows problem, but calling
xmlClearParserCtxt() after parsing would be the right thing to do - if it
didn't crash.

Stefan