After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 339311 - "internal error"
"internal error"
Status: RESOLVED FIXED
Product: libxml2
Classification: Platform
Component: general
git master
Other All
: Normal normal
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
Depends on:
Blocks: 339192
 
 
Reported: 2006-04-21 15:09 UTC by Morten Welinder
Modified: 2006-04-24 08:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
foo.xml sample file (61 bytes, application/xml)
2006-04-21 16:39 UTC, Morten Welinder
Details

Description Morten Welinder 2006-04-21 15:09:35 UTC
Using this file, foo.xml:

<?xml version="1.0" encoding="UTF-8"?>
<xxx>xxx  yyy</xxx>

(where there are two literal ^Hs between "xxx " and " yyy") I get...

> ./xmllint ~/foo.xml 
/home/welinder/foo.xml:2: parser error : internal error
<xxx>xx yyy</xxx>
         ^
/home/welinder/foo.xml:2: parser error : Extra content at the end of the document
<xxx>xx yyy</xxx>
         ^
(And, btw., it should be "parser error:" not "parser error :".)

Note: I don't know if this file is valid or not.  But in either case,
"internal error" is not the right answer.
Comment 1 Daniel Veillard 2006-04-21 16:11:21 UTC
if ^H is what it means, then that's not XML, the fact it's raising it as internal
error is a different relatively minor problem. Provide the input as an attachment
no way a cut an past be meaningful in such a context.
Looks NOTABUG to me except for the message, which I will track down if I have
a reproductible case,

Daniel
Comment 2 Morten Welinder 2006-04-21 16:39:00 UTC
Created attachment 64062 [details]
foo.xml sample file
Comment 3 Daniel Veillard 2006-04-24 08:51:36 UTC
The example contains character of codepoint 0008, and clearly this is not XML
http://www.w3.org/TR/REC-xml/#NT-Char

the parser must fail on it, so the behviour is normal, the error report is right
when pointing the location of the error, just that the message is not right.
I fixed this in CVS:

paphio:~/XML -> xmllint foo.xml
foo.xml:2: parser error : PCDATA invalid Char value 8
<xxx>xx yyy</xxx>
         ^
foo.xml:2: parser error : PCDATA invalid Char value 8
<xxx>xx yyy</xxx>
          ^
paphio:~/XML ->

  thanks for the report, 

Daniel