Parser cannot be freed while it is parsing. in /srv/mediawiki/php-1.25wm f16/includes/media/XMP.php on line 156
Offending code:
⠀⠀⠀/** Destroy the xml parser
⠀⠀⠀ *
⠀⠀⠀ * Not sure if this is actually needed.
⠀⠀⠀ */
⠀⠀⠀function __destruct() {
⠀⠀⠀⠀⠀⠀// not sure if this is needed.
⠀⠀⠀⠀⠀⠀xml_parser_free( $this->xmlParser );
⠀⠀⠀}Nope, just bad autocomplete when I tried to add MediaWiki-General (which really should come up when I type "mediawiki" IMO but there is a task tracking that ...somewhere...).
This is now the #1 fatal error with nearly 1000 hits in the latest 1000 lines of the hhvm.log
Change 213761 had a related patch set uploaded (by Brian Wolff):
Move xml_free_parser out of destructor.
Does that mean my patch did not work? I couldnt reproduce locally so it was just a guess.
The bug was closed too fast as the error is still occurring:
Warning: Parser cannot be freed while it is parsing. in /srv/mediawiki/php-1.26wmf11/includes/media/XMP.php on line 167
210 occurrences over 24 hours, so that it is probably an improvement. For the last 30 days from logstash:
Logstash now says:
"Parser cannot be freed" (244) count per 12h | (244 hits)
Does someone plan to investigate more (assignee is set to @Bawolff)? Is this still high priority?
This is the #1 logged error in fatalmonitor on wmf20 branch, and wmf20 hasn't even gone out to group2 yet. This is a high priority as it's blocking the train deployment now.
Looking at the HHVM source code, it appears that [[https://github.com/facebook/hhvm/blob/013a32a8409176a580cc63be5f649dbcb4f1e442/hphp/runtime/ext/xml/ext_xml.cpp#L732-L735|this warning is raised when the isparsing internal flag is set]]. Based on that and the flow I see in the code:
p->isparsing = 1;
ret = XML_Parse(p->parser, (const XML_Char*)data.data(), data.size(),
isFinal);
p->isparsing = 0;seeing the error means that we are trying to free when the XML_Parse() function from libexpat has interrupted the normal code path via a longjmp of some type (or been interrupted by the interpreter in some way). This could easily happen due to a tag handler that we have registered with the parser raising an Exception. This *should* mean that we've ended up in the catch block of XMP::parse(). That block tries to log the exception that it has caught. In WMF production we don't have logging enabled for the XMP log channel those messages are sent to so we can't verify this today.
I think if we remove the call to XMP::destroyXMLParser() in the catch block of XMP::parse() these errors will all go away. A related question is whether or not we should enable logging for the XMP channel and see the resulting exception data.
Change 234407 had a related patch set uploaded (by BryanDavis):
XMP: log structured data for halting errors
Change 234425 had a related patch set uploaded (by BryanDavis):
Enable logging of XMP debug log channel for severity >=warning
Change 234428 had a related patch set uploaded (by Legoktm):
Don't free the parser in the catch() block of parse()
Change 234428 merged by jenkins-bot:
Don't free the parser in the catch() block of parse()
Change 234425 merged by jenkins-bot:
Enable logging of XMP debug log channel for severity >=warning