Follow-up Comment #8, bug #67508 (group denemo): I've instrumented libxml2 (v2.13.1) tree.c::xmlNodeListGetStringInternal() to show which 'return' statement is triggered that results in the NULL. Surprisingly, it is the final "return(ret)" that one would expect to have a valid value since
ret = xmlBufDetach(buf);
So I added instrumentation to buf.c::xmlBufDetach() as well, and see it also
its 'good' "return ret" statement but ret is NULL. With more instrumentation
in the loop in xmlNodeListGetStringInternal() we finally see what is going
wrong:
Denemo - WARNING : parseLilyDir() calling xmlNodeListGetString()
Denemo - WARNING : parseLilyDir() calling xmlNodeListGetString()
Entered xmlNodeListGetStringInternal()
xmlNodeListGetStringInternal() with escMode=0
node->type=1 (n/a)
node->type=1 (n/a)
node->type=1 (n/a)
node->type=1 (n/a)
node->type=1 (n/a)
node->type=1 (n/a)
xmlBufDetach()
xmlBufDetach() ret = buf->content
Leave xmlBufDetach() at return ret
Leave xmlNodeListGetStringInternal() at return(ret)
Denemo - WARNING : parseLilyDir() doing backward compatibility
Denemo - WARNING : parseLilyDir() return
type=1 maps to XML_ELEMENT_NODE (as we would expect since <lily-directive> has
child elements) but it seems like the function only deals with text, CDATA, or
entity references:
typedef enum {
XML_ELEMENT_NODE= 1,
XML_ATTRIBUTE_NODE= 2,
XML_TEXT_NODE= 3,
XML_CDATA_SECTION_NODE= 4,
XML_ENTITY_REF_NODE= 5,
Unfortunately this function, or its code, is not in v2.12.x so any kind of
comparison is not possible.
However I think there is now enough evidence of a regression in libxml2
v2.13.x+ that you may want to report this - I don't think there is anything
wrong with Upbeat,denemo XML syntax and xmllint doesn't report anything
incorrect in it.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67508>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
