GNOME Bugzilla – Bug 523738
libxml2 : xmllint valdating with schema produce "Bus error" on OS X with static build
Last modified: 2021-07-05 13:27:34 UTC
Steps to reproduce: There is a regression wich appeard in version 2.6.28. The problem is still present in the current version 2.6.31. The problem may be related to the complex schema which is used (I can send them as well as the sample xml document if necessary). With version 2.6.27 : $ ~/Programming/libs/bin/xmllint -noout -nowarning -schema RPPS_XSD_3.2/CR/XMLRppsCRAlim.xsd sample.xml sample.xml validates With version 2.6.28 : $ ~/Programming/libs/bin/xmllint -noout -nowarning -schema RPPS_XSD_3.2/CR/XMLRppsCRAlim.xsd sample.xml Bus error Stack trace: Other information: I built Universal Binaries sources for 2.6.27 and 2.6.28 the same way (on OS 10.4 Tiger) : mkdir ~/Programming/ mkdir ~/Programming/libs mkdir ~/Programming/libs/src mkdir ~/Programming/libs/include mkdir ~/Programming/libs/lib mkdir ~/Programming/libs/bin mkdir ~/Programming/libs/man mkdir ~/Programming/libs/share cd ~/Programming/libs/src curl -O http://ftp.gnu.org/gnu/libiconv/libiconv-1.12.tar.gz tar xzf libiconv-1.12.tar.gz rm libiconv-1.12.tar.gz cd libiconv-1.12 CFLAGS="-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk" ./configure \ --prefix=$PWD/../../ \ --enable-static \ --disable-shared make -j3 make install cd ~/Programming/libs/src curl -O ftp://xmlsoft.org/libxml2/libxml2-2.6.28.tar.gz tar xzf libxml2-2.6.28.tar.gz rm libxml2-2.6.28.tar.gz cd libxml2-2.6.28 CFLAGS="-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk" ./configure \ --prefix=$PWD/../../ \ --with-iconv=$PWD/../../ \ --enable-static \ --disable-shared \ --disable-dependency-tracking make -j3 make install
Created attachment 107760 [details] contains the sample.xml dans schema files
I was able to reproduce the problem on linux. Apparently it was related to a problem processing the following regexp: Program received signal SIGSEGV, Segmentation fault. 0x00000000004b8a92 in xmlFARegExec (comp=0x9b0ed8, content=0x54db4d "") at xmlregexp.c:3163 3163 while ((exec->status == 0) && (gdb) p exec $1 = (xmlRegExecCtxtPtr) 0x7fff47a19410 (gdb) p *exec $2 = {status = 0, determinist = 1, comp = 0x9b0ed8, callback = 0, data = 0x0, state = 0x0, transno = 0, transcount = 0, maxRollbacks = 0, nbRollbacks = 0, rollbacks = 0x0, counts = 0x0, inputStackMax = 0, inputStackNr = 0, index = 0, charStack = 0xa1ce88, inputString = 0x54db4d "", inputStack = 0x0, errStateNo = 1201771680, errState = 0x9f6545, errString = 0x99eac8 "X�\231", errCounts = 0x5009aa328, nbPush = 0} (gdb) p exec->inputString $3 = (const xmlChar *) 0x54db4d "" (gdb) p exec->index $4 = 0 (gdb) p exec->state $5 = (xmlRegStatePtr) 0x0 (gdb) p *exec->comp $7 = { string = 0x9b29f8 "(19|[2-9][0-9])[0-9]{2,2}((0[0-9]|1[012])[012][0-9]|(0[13-9]|1[012])30|(0[13578]|10|12)31)|", nbStates = 29, states = 0x9b6ae8, nbAtoms = 30, atoms = 0x9b7728, nbCounters = 0, counters = 0x0, determinist = -1, nbstates = 0, compact = 0x0, transdata = 0x0, nbstrings = 0, stringMap = 0x0} (gdb) For some reason we ended up with a NULL state pointer in that loop which wasn't properly tested beforehand. If I had a smaller XSD test case i would have added it to the regression suite, but that's way to big. When i see things like this regexp i wonder how those things are generated it looks a bit insane... Expected fix commited to SVN revision 3744, thanks, Daniel
" When i see things like this regexp i wonder how those things are generated it looks a bit insane..." I agree :-) This is just to have a date in string type element with a YYYYMMDD format (I don't know why they chose this)... Personnally I would have used the date type (maybe it is too simple for some people)... If this is this pattern which causes the exception, I can isolate the patten in a new xsd file if you want and provide some files for your regression tests. Let me know... Thanks for the fix anyway :-) Bruno
Well one thing which should be done is take the regexp and try it standalone against some values using testRegexp which is part of the source distribution to make sure I didn't just fixed a side-effect and the behaviour is actually correct, Daniel
(In reply to comment #4) > Well one thing which should be done is take the regexp > and try it standalone against some values using testRegexp > which is part of the source distribution to make sure I didn't > just fixed a side-effect and the behaviour is actually correct, > > Daniel I did reproduce the problem with current version 2.7.7. I am going to add two attachements : - the build script I use on OS X 10.6 - basic sample files (one xml, two xsd : on which is ok and one with the offending pattern) About testRegexp, is it a binary generated when building xmllb ?
Created attachment 170876 [details] lib xml build script for OS X
Created attachment 170877 [details] sample data file
Created attachment 170878 [details] schema with an ok pattern
Created attachment 170879 [details] schema with pattern causing a crash
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/libxml2/-/issues/ Thank you for your understanding and your help.