Removing the character data handler from within the
character data handler while character data remains to
be reported causes a call to a NULL pointer (generally
followed by a memory access violation of your
platform's favorite flavor).
If the XML_StopParser() API has been called, this is
not a problem with the version in CVS.
This is admittedly an odd use case. The recent fixes
to make the XML_StopParser() calls supported makes the
parser behave well when accessed from languages that
support exceptions (the host language API can call
XML_StopParser to abort further work from Expat when an
exception occurs). The case of a character data
handler removing itself is unusual (in context, there
can be no calls to anything else other than a decoding
I think there are two possible solutions:
1) Document that the character data handler cannot
remove itself without calling XML_StopParser(). This
avoids introducing a performance penalty for really
this really odd case, but I don't know how bad testing
for a NULL value would really be at this point, since
there are a few other checks and an indirect assignment.
2) Add a check that the character data handler is still
set before the loop goes around again, and fall back to
the defaultHandler for the remaining data. This would
introduce a single check for a NULL pointer in the loop
in the XML_TOK_DATA_CHARS case in doContent().
I've attached a patch with a test case that
demonstrates this bug; the test generates a segfault on