[4suite] Re: [XML-SIG] ANN: 4Suite and 4SuiteServer 0.11.1 beta 2

[Dieter Maurer]

--eNIT2rXqug
Content-Type: text/plain; charset=us-ascii
Content-Description: message body text
Content-Transfer-Encoding: 7bit

Dear Uche,

Uche Ogbuji writes:
 > ....
 > Thanks for the reminder, but I'm unable to reproduce this.  Now I've had problems reproducing
 > 
 > bugs triggered by nwalsh's stylesheets before until I did things just a certain way,
 > 
 > so let me tell you just what I did so you can tell me where I took a 
 > wrong turn.
Everything looks good!

 > I added a print to the pDomletteReader entityRef handler in order to 
 > trace things down:
 > 
 > --- Lib/ReaderBase.py	2001/06/12 17:45:36	1.18
 > +++ Lib/ReaderBase.py	2001/06/17 13:06:23
 > @@ -334,6 +334,7 @@
 > 
 >       _entity_stack= None
 >       def entityRef(self, context, base, sysid, pubid):
 > +        print "entityRef", context, base, sysid, pubid
 >           stream = self.resolveEntity(pubid, _combineSysid(base, sysid))
 > 
 >           if self._entity_stack is None: self._entity_stack = []
I followed your lead...

 > Then I copied the book.xml you posted earlier to a directory.  Then I 
 > created an empty chap3.xml file in the same directory.
 > 
 > This is the result of running the nwalsh docbook html stylesheet
 > 
 > (the "db" dir is the root directory of the 1.39 docbook stylesheets)
 > 
 > $ 4xslt book.xml db/html/docbook.xsl
 > entityRef ca /usr/local/lib/xslt/db/common/l10n.xml ca.xml None
 > ...
 > entityRef zh_tw /usr/local/lib/xslt/db/common/l10n.xml zh_tw.xml None
Hm, you notice that the reference to "chap3" is not reported?

But, I get similar results when "chap3.xml" is an empty file.
For me, the "chap3" reference is listed.

Apparently, the problem has to do with the content of "chap3.xml".
I validated its content with "nsgmls", thus it is not the structure.

I have had similar problems with 4suite 0.9. Then, I tracked
the problem down to a weird (and very difficult to reproduce)
bug in "xmlparse.c" in connection with CDATA sections.
I have submitted the bug and patch to xml-sig a long time
ago, but never heard anything about it.
Maybe, the bug was not fixed.


And indeed! I applied my patch to "xmlparse" and the problem
went away. I attach the patch.

Sorry for my impatience!


Earlier, I have been unable to come up with a short test case
to reproduce the "xmlparse" problem. I could provide
the book sources, but it they are about 250 kB.


Dieter


--eNIT2rXqug
Content-Type: application/octet-stream
Content-Description: Patch for weird xmlparse problem that may occur in very rare cases in connection with external entities and CDATA sections
Content-Disposition: attachment;
	filename="xmlparse.pat"
Content-Transfer-Encoding: base64

LS0tIDp4bWxwYXJzZS5jCUZyaSBTZXAgMjQgMDQ6MTg6MzggMTk5OQorKysgeG1scGFyc2Uu
YwlTYXQgRmViIDE3IDIyOjQ3OjMxIDIwMDEKQEAgLTMwMSw2ICszMDEsNyBAQAogICB2b2lk
ICgqbV91bmtub3duRW5jb2RpbmdSZWxlYXNlKSh2b2lkICopOwogICBQUk9MT0dfU1RBVEUg
bV9wcm9sb2dTdGF0ZTsKICAgUHJvY2Vzc29yICptX3Byb2Nlc3NvcjsKKyAgUHJvY2Vzc29y
ICptX2JlZm9yZUNkYXRhUHJvY2Vzc29yOwogICBlbnVtIFhNTF9FcnJvciBtX2Vycm9yQ29k
ZTsKICAgY29uc3QgY2hhciAqbV9ldmVudFB0cjsKICAgY29uc3QgY2hhciAqbV9ldmVudEVu
ZFB0cjsKQEAgLTM2MCw2ICszNjEsNyBAQAogI2RlZmluZSBucyAoKChQYXJzZXIgKilwYXJz
ZXIpLT5tX25zKQogI2RlZmluZSBwcm9sb2dTdGF0ZSAoKChQYXJzZXIgKilwYXJzZXIpLT5t
X3Byb2xvZ1N0YXRlKQogI2RlZmluZSBwcm9jZXNzb3IgKCgoUGFyc2VyICopcGFyc2VyKS0+
bV9wcm9jZXNzb3IpCisjZGVmaW5lIGJlZm9yZUNkYXRhUHJvY2Vzc29yICgoKFBhcnNlciAq
KXBhcnNlciktPm1fYmVmb3JlQ2RhdGFQcm9jZXNzb3IpCiAjZGVmaW5lIGVycm9yQ29kZSAo
KChQYXJzZXIgKilwYXJzZXIpLT5tX2Vycm9yQ29kZSkKICNkZWZpbmUgZXZlbnRQdHIgKCgo
UGFyc2VyICopcGFyc2VyKS0+bV9ldmVudFB0cikKICNkZWZpbmUgZXZlbnRFbmRQdHIgKCgo
UGFyc2VyICopcGFyc2VyKS0+bV9ldmVudEVuZFB0cikKQEAgLTEzODQsNiArMTM4Niw5IEBA
CiAgICAgY2FzZSBYTUxfVE9LX0NEQVRBX1NFQ1RfT1BFTjoKICAgICAgIHsKIAllbnVtIFhN
TF9FcnJvciByZXN1bHQ7CisKKwliZWZvcmVDZGF0YVByb2Nlc3Nvcj0gcHJvY2Vzc29yOwor
CiAJaWYgKHN0YXJ0Q2RhdGFTZWN0aW9uSGFuZGxlcikKICAgCSAgc3RhcnRDZGF0YVNlY3Rp
b25IYW5kbGVyKGhhbmRsZXJBcmcpOwogI2lmIDAKQEAgLTE3MzEsOCArMTczNiw4IEBACiB7
CiAgIGVudW0gWE1MX0Vycm9yIHJlc3VsdCA9IGRvQ2RhdGFTZWN0aW9uKHBhcnNlciwgZW5j
b2RpbmcsICZzdGFydCwgZW5kLCBlbmRQdHIpOwogICBpZiAoc3RhcnQpIHsKLSAgICBwcm9j
ZXNzb3IgPSBjb250ZW50UHJvY2Vzc29yOwotICAgIHJldHVybiBjb250ZW50UHJvY2Vzc29y
KHBhcnNlciwgc3RhcnQsIGVuZCwgZW5kUHRyKTsKKyAgICAvKiBwcm9jZXNzb3IgPSBjb250
ZW50UHJvY2Vzc29yOyAqLworICAgIHJldHVybiBwcm9jZXNzb3IocGFyc2VyLCBzdGFydCwg
ZW5kLCBlbmRQdHIpOwogICB9CiAgIHJldHVybiByZXN1bHQ7CiB9CkBAIC0xNzY3LDYgKzE3
NzIsOSBAQAogICAgICpldmVudEVuZFBQID0gbmV4dDsKICAgICBzd2l0Y2ggKHRvaykgewog
ICAgIGNhc2UgWE1MX1RPS19DREFUQV9TRUNUX0NMT1NFOgorCisgICAgICBwcm9jZXNzb3I9
IGJlZm9yZUNkYXRhUHJvY2Vzc29yOworCiAgICAgICBpZiAoZW5kQ2RhdGFTZWN0aW9uSGFu
ZGxlcikKIAllbmRDZGF0YVNlY3Rpb25IYW5kbGVyKGhhbmRsZXJBcmcpOwogI2lmIDAK

--eNIT2rXqug--