https://bugzilla.gnome.org/show_bug.cgi?id=692915
the new set of converting functions tried to limit the encoding
conversion of the raw buffer to the consumption one to work in
a more progressive fashion. Unfortunately this was bad for
performances and led to errors on progressive parsing when
a very large chunk was close to the end of the document. Fix
the new internal function and switch back to the old way of
converting. Fix another bug in the process.
https://bugzilla.gnome.org/show_bug.cgi?id=690202
Buffer overflow errors originating from xmlBufGetInputBase in 2.9.0
The pointers from the context input were not properly reset after
that call which can do reallocations.
Related to https://bugs.launchpad.net/lxml/+bug/502959
Basically the core of the issue is that if an entity references another
entity, then in case we are replacing entities content, we should always
do so by copying the referenced content as long as the reference is
done within the entity. Otherwise, if for some reason there is a later
parsing error that entity content may be freed.
Complex scenario exposed by command:
thinkpad:~/XML/diveintopython-5.4/xml -> valgrind --db-attach=yes
../../xmllint --loaddtd --noout --noent diveintopython.xml
Document references &a;
a references &b;
we references b content directly in by linking in the a content
a has an error further down
we free a, freeing the chunk from b
Document references &b; after &a;
we try to copy b content, but it was freed already => segfault
* parser.c: never reference directly entity content without copying if
we aren't in the document main entity
Fix the lack of line number as reported by Johan Corveleyn <jcorvel@gmail.com>
* parser.c include/libxml/parser.h: add an XML_PARSE_BIG_LINES parser
option not switch on by default, it's an opt-in
* SAX2.c: if XML_PARSE_BIG_LINES is set store the long line numbers
in the psvi field of text nodes
* tree.c: expand xmlGetLineNo to extract those informations, also
make sure we can't fail on recursive behaviour
* error.c: in __xmlRaiseError, if a node is provided, call
xmlGetLineNo() if we can't get a valid line number.
* xmllint.c: switch on XML_PARSE_BIG_LINES in xmllint
That condition is one raised when the parser should positively stop
processing further even to report errors. Best is to test is after
most GROW call especially within loops
Those can be overrided by the XML_PARSE_HUGE option, they
are just default limits for Name lenght, dictionary size limits
and maximum amount of parser lookup.
* include/libxml/parserInternals.h: define the limits
* include/libxml/xmlerror.h: add a new error
* parser.c parserInternals.c: implements the new limits
Unless the XML_PARSE_HUGE option is given to the parser,
the value is XML_MAX_TEXT_LENGTH, i.e. the same than for a
text node within content.
Also cleanup some unsigned int used for memory size.
Unless the XML_PARSE_HUGE option is given to the parser,
the value is XML_MAX_TEXT_LENGTH, i.e. the same than for a
text node within content.
Also cleanup some unsigned int used for memory size.
When calling xmlParserInputBufferPush, the buffer may be reallocated
and at the input level the pointers for base, cur and end need to
be reevaluated.
* buf.c buf.h: add two new functions, one to get the base from the
input of the buffer, and another one to reset the pointers based
on the cur and base inded
* HTMLparser.c parser.c: cleanup to use the new helper functions
as well as making sure size_t is used for the indexes computations
This was scattered in a number of modules, xmlParserInputPtr
have usually their base, cur and end pointer set from an
xmlBuf used as input.
* buf.c buf.h: add a new function implementing this setup
* parser.c HTMLparser.c catalog.c parserInternals.c xmlreader.c
use the new function instead of digging into the buffer in
all those modules
The main changes are when the internal of the buffers structure
were adressed directly, we now use routines coming from buf.h
The routine xmlParserInputRead() which wasn't used anywhere is
deprecated too.
Unless explicietely asked for when validating or replacing entities
with their value. Problem pointed out by Tom Lane <tgl@redhat.com>
* parser.c: do not load external parsed entities unless needed
* test/errors/extparsedent.xml result/errors/extparsedent.xml*:
add a regression test to avoid change of the behaviour in the future
tsan reported that rand() is not thread safe, so create
a thread safe wrapper, use rand_r() if available.
Consolidate the function, initialization and cleanup in
dict.c and make sure it is initialized in xmlInitParser()
For https://bugzilla.gnome.org/show_bug.cgi?id=643949
In case of error on an IO creation input the given context
is terminated with the given close function, except if the
error happened in xmlParserInputBufferCreateIO. This can
lead to a resource leak which is fixed by this patch.
For both XML and HTML, the document can provide an encoding
either in XMLDecl in XML, or as a meta element in HTML head.
This adds options to ignore those encodings if the encoding
is known in advace for example if the content had been converted
before being passed to the parser.
* parser.c include/libxml/parser.h: add XML_PARSE_IGNORE_ENC option
for XML parsing
* include/libxml/HTMLparser.h HTMLparser.c: adds the
HTML_PARSE_IGNORE_ENC for HTML parsing
* HTMLtree.c: fix the handling of saving when an unknown encoding is
defined in meta document header
* xmllint.c: add a --noenc option to activate the new parser options
Mostly except we keep support for some older constructs and
don't implement extension or privateuse. It's messy because
it's used mostly by XSD datatype which itself reference RFC 3066
and suggests a lexical space completely different from what
5646 defines.
In xmlInitParser, both __xmlGlobalInitMutexLock and xmlInitGlobals are
called before xmlInitThreads, and both use pthread symbols.
__xmlGlobalInitMutexLock does so directly, without checking if the symbol
exists, and xmlInitGlobals calls xmlNewMutex, which correctly depends on
libxml_is_threaded... except libxml_is_threaded is still -1 by then...
And again, when releasing the global mutex in __xmlGlobalInitMutexUnlock,
the pthread function is called directly.
The patch changes the initialization order and make sure the functions
are available before calling them
if encoding was autodetected, in xmlParseChunk, if initial size is 86 (a
chunk in UTF-16 encoding), the code that tries to read only the first line
will set the size to 90, which eventually leads to a memmove of 90 bytes
(in xmlBufferAdd) which will copy extra random memory bytes, which will
make the parser to fail because of these extra bytes.
