You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by Da...@lotus.com on 2000/07/14 05:06:46 UTC
Problems with latest Xerces code
Hi,
I just update my tree from the CVS archives and rebuilt Xerces. Now some
very simple XML files are failing because Xerces thinks that an element
contains two attributes of the same name. I can't tell if this is related
to any recent changes or not.
Here's the sample file:
<?xml version="1.0"?>
<data>
<histogram misc="0" name="load-times" type="int"/>
<INPUT type="text" OnDBLClick="retreive( )" testapos="JSFunction
('val1','val2')"/>
</data>
I traced the problem to XMLScanner::scanStartTag() line 2251 to this code:
XMLAttDef* attDef = elemDecl->findAttr
(
fAttNameBuf.getRawBuffer()
, 0
, 0
, XMLElementDecl::AddIfNotFound
, wasAdded
);
Inside DTDElementDecl::findAttr(), line 134 adds the attribute to its hash
table using the pointer passed in as the key:
fAttDefs->put((void*)qName, retVal);
I believe this is bogus, since there is no guarantee that this pointer will
be unique. Indeed, when I was debugging it, it was the same for all of the
attributes. Unfortunately, misc and name, in the histogram element of the
above sample ended up in the same hash bucket. The parser was looking for
the definition of name and found the definition of misc. When I stepped
around the problem in the debugger, or fiddled with the hash value for the
string "name", the document parsed correctly.
Dave
Re: Problems with latest Xerces code
Posted by Joe Polastre <jp...@apache.org>.
fixed, get the latest version from CVS.
-Joe Polastre (jpolast@apache.org)
IBM Cupertino, XML Technology Group
----- Original Message -----
From: <Da...@lotus.com>
To: <xe...@xml.apache.org>
Sent: Thursday, July 13, 2000 8:06 PM
Subject: Problems with latest Xerces code
> Hi,
>
> I just update my tree from the CVS archives and rebuilt Xerces. Now some
> very simple XML files are failing because Xerces thinks that an element
> contains two attributes of the same name. I can't tell if this is related
> to any recent changes or not.
>
> Here's the sample file:
>
> <?xml version="1.0"?>
> <data>
> <histogram misc="0" name="load-times" type="int"/>
> <INPUT type="text" OnDBLClick="retreive( )" testapos="JSFunction
> ('val1','val2')"/>
> </data>
>
> I traced the problem to XMLScanner::scanStartTag() line 2251 to this code:
>
> XMLAttDef* attDef = elemDecl->findAttr
> (
> fAttNameBuf.getRawBuffer()
> , 0
> , 0
> , XMLElementDecl::AddIfNotFound
> , wasAdded
> );
>
> Inside DTDElementDecl::findAttr(), line 134 adds the attribute to its hash
> table using the pointer passed in as the key:
>
> fAttDefs->put((void*)qName, retVal);
>
> I believe this is bogus, since there is no guarantee that this pointer
will
> be unique. Indeed, when I was debugging it, it was the same for all of
the
> attributes. Unfortunately, misc and name, in the histogram element of the
> above sample ended up in the same hash bucket. The parser was looking for
> the definition of name and found the definition of misc. When I stepped
> around the problem in the debugger, or fiddled with the hash value for the
> string "name", the document parsed correctly.
>
> Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
Re: Problems with latest Xerces code
Posted by Dean Roddey <dr...@charmedquark.com>.
I assume this must be from the changes that Joe put in recently for the hash
table stuff. I didn't look at it closely, so I'm not sure what it was about.
But that's the only changes to any hash table stuff I can remember lately.
The code I originally wrote definitely copied the strings, because the same
buffers are used over and over again internally, and used to pass data out
through the event APIs.
--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
droddey@charmedquark.com
http://www.charmedquark.com
"You young, and you gotcha health. Whatchoo wanna job fer?"
----- Original Message -----
From: <Da...@lotus.com>
To: <xe...@xml.apache.org>
Sent: Thursday, July 13, 2000 8:06 PM
Subject: Problems with latest Xerces code
> Hi,
>
> I just update my tree from the CVS archives and rebuilt Xerces. Now some
> very simple XML files are failing because Xerces thinks that an element
> contains two attributes of the same name. I can't tell if this is related
> to any recent changes or not.
>
> Here's the sample file:
>
> <?xml version="1.0"?>
> <data>
> <histogram misc="0" name="load-times" type="int"/>
> <INPUT type="text" OnDBLClick="retreive( )" testapos="JSFunction
> ('val1','val2')"/>
> </data>
>
> I traced the problem to XMLScanner::scanStartTag() line 2251 to this code:
>
> XMLAttDef* attDef = elemDecl->findAttr
> (
> fAttNameBuf.getRawBuffer()
> , 0
> , 0
> , XMLElementDecl::AddIfNotFound
> , wasAdded
> );
>
> Inside DTDElementDecl::findAttr(), line 134 adds the attribute to its hash
> table using the pointer passed in as the key:
>
> fAttDefs->put((void*)qName, retVal);
>
> I believe this is bogus, since there is no guarantee that this pointer
will
> be unique. Indeed, when I was debugging it, it was the same for all of
the
> attributes. Unfortunately, misc and name, in the histogram element of the
> above sample ended up in the same hash bucket. The parser was looking for
> the definition of name and found the definition of misc. When I stepped
> around the problem in the debugger, or fiddled with the hash value for the
> string "name", the document parsed correctly.
>
> Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
Re: Problems with latest Xerces code
Posted by Joe Polastre <jp...@apache.org>.
From: <Da...@lotus.com>
> Inside DTDElementDecl::findAttr(), line 134 adds the attribute to its hash
> table using the pointer passed in as the key:
> fAttDefs->put((void*)qName, retVal);
> I believe this is bogus, since there is no guarantee that this pointer
will
> be unique. Indeed, when I was debugging it, it was the same for all of
the
> attributes. Unfortunately, misc and name, in the histogram element of the
> above sample ended up in the same hash bucket. The parser was looking for
> the definition of name and found the definition of misc. When I stepped
> around the problem in the debugger, or fiddled with the hash value for the
> string "name", the document parsed correctly.
It is true that pointer is being passed in, but the pointer is not what is
hashed. In this case, the XMLCh* that the pointer points to is what is
being hashed.
I had the same problem previously (after first submitting the changes) but
fixed it on my end. I'll grab your XML document and try it out. hopefully
it will work.
I'll get back to you about this...
-Joe