GNOME Bugzilla – Bug 653724
Schma duration parsing problem
Last modified: 2011-11-11 08:55:24 UTC
Created attachment 191001 [details] Problematic schema xmllint -schema micro.xml 1.xml Schemas parser error : facet 'maxInclusive': 'maxInclusive' has to be greater than or equal to 'minInclusive'. WXS schema micro.xml failed to compile 1.xml:1: parser error : StartTag: invalid element name </root> ^ 1.xml:1: parser error : Extra content at the end of the document </root> ^ where 1.xml content: <root/> problematic schema, also enclosed. <xs:schema attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://schemas.microsoft.com/2003/10/Serialization/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://schemas.microsoft.com/2003/10/Serialization/"> <xs:element name="duration" nillable="true" type="tns:duration"/> <xs:simpleType name="duration"><xs:restriction base="xs:duration"> <xs:pattern value="\-?P(\d*D)?(T(\d*H)?(\d*M)?(\d*(\.\d*)?S)?)?"/> <xs:minInclusive value="-P10675199DT2H48M5.4775808S"/> <xs:maxInclusive value="P10675199DT2H48M5.4775807S"/> </xs:restriction> </xs:simpleType> </xs:schema>
The schema is valid and the error raised not true. I would guess that is has to do something with minus in minInclusive.
From my testing it seems that this is only an issue on 32-bit. The 'days' part for the minInclusive and maxInclusive facet values seems to be the problem. Changing to ...12427D... as a maximum will allow the schema validation to succeed. The above works as normal on 64-bit. Looking into the code I have identified the problem to be the size of the 'carry' variable in xmlSchemaCompareDurations() in xmlschematypes.c. Changing carry from long to long long seems to solve the problem.
Okay, I finally came around reading this, sorry for the delay. This is a bit scary, I mean it's a lot of code, I got a bit better when I discovered it was in a large part based on alone_decoder.c from the xz project code. There is still a few things I worry about like in xz_state, the lzma_stream and z_stream structures are embbeded in. This create a serious risk, if the libraries are upgrated, and somehow they change the structures, libvirt will suddenly crash. Yes libraries are not supposed to break ABIs, in practice this happens all the time, and I'm cautious. I would very much prefer using an allocator/deallocator from the library if this exists instead. ... okay read a bit of doc "Passing data to and from liblzma" and it seems that they really expect us to allocate that structure it's weird... I think the new xzlib.c will need a header with author etc.. and go though indent(1) to match existing libxml2 code. but that's something I can do... Will look for possible feedback on your side before pushing this in any case thanks, Daniel
Whoops ignore comment 3, wrong window, another bug. Concerning your bug, I pushed a fix yesterday in git, so it should be solved now, thanks, Daniel