Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 228941

Summary: libxml2 random errors in Python application
Product: Red Hat Enterprise Linux 5 Reporter: Jos Vos <jos>
Component: libxml2Assignee: Daniel Veillard <veillard>
Status: CLOSED INSUFFICIENT_DATA QA Contact: David Lawrence <dkl>
Severity: high Docs Contact:
Priority: medium    
Version: 5.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-06-20 20:58:24 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Jos Vos 2007-02-16 00:42:47 UTC
Description of problem:
A Python application parsing XML files results in random (underterministic!)
application errors.  The same application works fine in RHEL4.

Version-Release number of selected component (if applicable):

The problem seems to be fixed after installing version 2.6.27-1.FC6 from FC6
updates.  I hope this fix is already in the current RHEL5 spins...

Comment 1 Daniel Veillard 2007-02-18 08:38:00 UTC
I don't know the problem you're hitting, there is no special error reported,
and libxml2 is used in many places for XML parsing in RHEL5. I guess something 
wrong happened on your installation, but what I just can't guess. There
is no update planned of libxml2 for RHEL5, and no other bug reported either.
So please come back with a clear problem indication, as is there is nothing
I can do ...


Comment 2 Jos Vos 2007-02-18 13:37:50 UTC
My scenario:

# rpm -q libxml2 libxml2-python libxml2-devel
# rpm -V libxml2 libxml2-python libxml2-devel

... application fails at random data ...

# rpm -Uvh /tmp/x1/libxml2-*
# rpm -q libxml2 libxml2-python libxml2-devel
# rpm -V libxml2 libxml2-python libxml2-devel

... application runs fine ...

And when I reinstall the RHEL5b2 packages again with "rpm -Uvh --oldpackage .."
the application randomly gives errors again.

Comment 3 Jos Vos 2007-03-23 13:36:09 UTC
FYI: the error is still present in RHEL5 GA.  Should I refile the bug as a RHEL5
(non-beta) bug?  It seems to be impossible to change "Product" and "Version" for
this bug (at least for me).

Comment 4 Daniel Veillard 2007-03-23 13:49:32 UTC
I changed it, everything seems to work fine for me (I'm on 
RHEL5) so unless you actually give me a reproduceable test case
there is really nothing I can do about it though ...


Comment 5 Jos Vos 2007-03-23 14:20:38 UTC
As an extra test, I just have rebuilt libxml2-2.6.27-1.FC6.src.rpm on RHEL5,
installed it (i.e. upgrade libxml2*), and after that everything works fine again.

Looking into libxml2's changelog between 2.6.26 and 2.6.27, I see a huge list of
fixes (many of them with your name ;-)), so probably one of them is related to
my problem...

Will try to make a small test case, although I'm not very optimistic that this
will succeed, given the kind of errors I get.

Comment 6 Daniel Veillard 2007-06-20 20:58:24 UTC
never got any report similar to your, libxml2 in RHEL-5.0 seems to just work
for people, and I don't get any reproductible test case. Honnestly I don't
think I can try to chase or fix this bug, it's way too incomplete, no idea
where I would start,


Comment 7 Jos Vos 2007-07-24 13:14:25 UTC
Hi Daniel,

I have more detailed diagnostics:

xpathEval() randomly (!) gives the matching node *twice* i.s.o. once (say, once
in 30 times).  I'm using a static XML file that I read in every loop again and a
(static) XPath expression applied to that parsed document sometimes returns the
matching node twice, i.s.o. once.  This happens also when using the etree.lxml
binding for Python (until now I used the libxml2 Python module).

Will reopen the bug as soon as I can reproduce it (I'm not optimistic about
that), but maybe you get new ideas now...