IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Reported by Petr Sumbera <petr.sumbera@oracle.com>
Two threads entering xmlInitializeDict concurently could lead
to a lockup due to multiple initializations of the lock used.
To avoid this problem move this to a new private function
called from xmlOnceInit() and deprecate the old initalizer.
Since threaded programs must call xmlInitParser() and this
will lead to dereference of private data and the call to
xmlOnceInit() guaranteed to be unique this should be safe now.
This patch adds xmlXPathSetContextNode and xmlXPathNodeEval,
which make it easier to evaluation XPath expressions with a
context node other than the document root without poking about
inside the internals of the context.
This patch is compile-tested only, and is my first libxml2
contribution, so please go easy.
Signed-off-by: Alex Bligh <alex@alex.org.uk>
while still compiling on recent Python2:
- change the handling of files, tweak the generator, get the fd
instead of the FILE *, dup it and fdopen based on mode, add a
Release function on Python3 and call to flush from the generated
python stubs
- switch to using Capsules instead of CObjects
- fix PyString to PyBytes
- fix PyInt to PyLong
- tweak the module registration to compile on both versions
- drop PyInstance check for passed xmlNodes and instead check
attributes presence
Daniel
Recently I have run into the very same problem Tiberius Duluman did back in
Wed, 13 May 2009 15:56:55 +0300 ([xml] Bug in xmlSchemaValidateOneElement
function). Now I can proof now that his problem is a valid problem. I checked
the latest available version of xmlschemas.c (2.9.0.) and the problem is still
there!
I think I have found a solution to the problem which I'd like proof with you:
My quick solution to the problem is to replace line 27849 in
xmlschemas.c
(v2.9.0.) in function xmlSchemaVDocWalk
valRoot = xmlDocGetRootElement(vctxt->doc);
with this one:
valRoot = vctxt->validationRoot ? vctxt->validationRoot : xmlDocGetRootElement(vctxt->doc);
Currently I'm using version 2.7.8. in Windows and this change seems to solve
the problem.
this is the other way to solve ./configure cannot remove messages by
simply removing rm detection in configure.in
There is already a raw 'rm -f' at the end on configure.in
Based on Thomas Gamper <icicle@cg.tuwien.ac.at> findings and
initial patch
There is no point doing a regexp validation of further
content if there actually is no further content because the
element is nilled.
https://bugzilla.gnome.org/show_bug.cgi?id=694185
RedHat Bug 624626 discusses the new behavior of libxml regarding brackets
around IPv6 addresses. In earlier versions such as 2.6.27, uri.c stripped the
brackets (e.g. uri->server == "fdf2:1e39:73d1:934e::119"); in the current
version it returns IPv6 addresses with brackets intact (e.g. uri->server
== "[fdf2:1e39:73d1:934e::119]").
Thus in 2.9.0, xmlCtxtReadFile() has a problem when it is passed a URL
containing a literal IPv6 address. xmlCtxReadFile() and its subroutines pass
uri->server unchanged to getaddrinfo(), which doesn't recognize a bracketed
IPv6 address, so the read fails.
This strips the [ and ] from IPv6 addresses allowing getaddrinfo()
to work properly with such URIs.
1. Setting entity loader does not increment the refcount on the Python object
passed in. This works only if the object is not deleted. For example, the
following code results in segmentation fault in Python interpreter when
attempting to process any document:
[[[
def register_entity_loader():
def entity_loader(URL, ID, ctxt):
...
libxml2.setEntityLoader(entity_loader
register_entity_loader()
]]]
2. setEntityLoader() does not verify if the passed object is callable. If it
is not, current implementation attempts to call it anyway and failing that,
silently moves on to default entity loader. Attached patch makes
setEntityLoader raise ValueError exception if non-callable object is
passed.
3. In debug mode, pythonExternalEntityLoader() outputs the result object to
stderr, while the messages before and after the object (description + newline)
go to stdout. Attached patch makes them all go to stdout.
It is possible to make xmlIO handle any protocol by means of
xmlRegisterInputCallback(). However, that function is currently only
available in C API. So, the natural solution seems to be implementing Python
bindings for the xmlRegisterInputCallback.
* python/generator.py: skip xmlPopInputCallbacks
* python/libxml.c python/libxml.py python/libxml_wrap.h: implement the
wrappers
* python/tests/input_callback.py python/tests/Makefile.am: also add a test case
I noticed another issue with Python bindings of libxml: the access methods do
not cast the pointers to specific classes such as xmlDtd, xmlEntityDecl, etc.
For example, with the following document:
<?xml version="1.0"?>
<!DOCTYPE root [<!ELEMENT root EMPTY>]>
<root/>
the following script:
import libxml2
doc = libxml2.readFile("c.xml", None, libxml2.XML_PARSE_DTDLOAD)
print repr(doc.children)
prints:
<xmlNode (root) object at 0xb74963ec>
With properly cast nodes, it outputs the following:
<xmlDtd (root) object at 0xb746352c>
The latter object (xmlDtd) enables one to use DTD-specific methods such as
debugDumpDTD(), copyDTD(), and so on.
If entities expansion in the XML parser is asked for,
it is possble to craft relatively small input document leading
to excessive on-the-fly content generation.
This patch accounts for those replacement and stop parsing
after a given threshold. it can be bypassed as usual with the
HUGE parser option.
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.
Otherwise, direct calls to xmlFree() etc. from the application will
use a different set of allocation functions to what was used to allocate
the memory internally.
