[Expat-bugs] [ expat-Bugs-669861 ] storeRawNames and namespace processing

[SourceForge.net]

Bugs item #669861, was opened at 2003-01-17 12:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=669861&group_id=10127

Category: None
Group: None
Status: Open
>Resolution: Duplicate
Priority: 5
Submitted By: Pavel Hlavnicka (pavel_hlavnicka)
>Assigned to: Karl Waclawek (kwaclaw)
Summary: storeRawNames and namespace processing

Initial Comment:
I'm really not sure it is really a bug, so forgive me,
if I'm wrong.

I think, there is a bug in the storeRawNames procedure,
where this code is executed:

tag->buf = temp;
tag->name.str = (XML_Char *)temp;

It makes buf and name.str the same, and the value is
unexpanded tag name (like UML:Multiplicity in my case).

It is in contradiction with what is set to name.str,
when namespace processing is active and the
storeAttributes method (good camouflage :) concatenates
qname uri, separator and local name set as name.str.

As the values of name.strLen and name.uriLen are kept,
there may a rare error occure in doContent
(XML_TOK_END_TAK) is executed, namely the fragment:

uri = (XML_Char *)tag->name.str + tag->name.uriLen;
while (*localPart) *uri++ = *localPart++;

Under certain conditions both of uri and local part
points the same buffer, and uri points behind the local
name, what results to the overriding of the terminal
zero and endless pattern is copied into the memory
until segfault tells its last word.

As I said, I wish to be more exact, but I believe, my
observations are correct.

Unfortunately, I didn't succeed to create just sample
program, all is happening just in the complex program
(Sablotron), so i'm not 100% it's just a side-effect of
my fault somewhere else. Accept my appology in such a case.

Keep a good work

----------------------------------------------------------------------

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-20 11:59

Message:
Logged In: YES 
user_id=290026

That's great.

Please let me know if you have any more problems.

If I don't hear from you in the next few days,
I'll close this bug as a duplicate. 

----------------------------------------------------------------------

Comment By: Pavel Hlavnicka (pavel_hlavnicka)
Date: 2003-01-20 11:00

Message:
Logged In: YES 
user_id=302801

CVS version seems be ok. This entry looks like a duplicate
of  #667511 (but don't trust me too much :)

----------------------------------------------------------------------

Comment By: Pavel Hlavnicka (pavel_hlavnicka)
Date: 2003-01-20 04:28

Message:
Logged In: YES 
user_id=302801

Bugs you pointed seem be of the similar flavour. Especially
#667511. 

I'd like to try the CVS version, but my system uses older
version of autoconf, and I have got some reasons not to upgrade.

If you want me to test it, please be so nice, and make a
test distribution for me. Sorry and thanks.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-17 13:40

Message:
Logged In: YES 
user_id=290026

We hava a few fixes for storeRawNames in CVS.
Please check bugs #618199 and #667511 if they explain
the behaviour to you.

Before spending more time on it, I recommend you
run with CVS for a while and check if the problem
shows up again.

I also asked the user who reported these bugs first,
and he thinks your problem may be the same.

----------------------------------------------------------------------

Comment By: Pavel Hlavnicka (pavel_hlavnicka)
Date: 2003-01-17 13:27

Message:
Logged In: YES 
user_id=302801

I'm using 1.95.5. I didn't check CVS, and would have to
check the source, not execution to prove it. The reason for
it is that the error is really hard to reporoduce.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-17 13:19

Message:
Logged In: YES 
user_id=290026

Which version are you talking about?
Does this problem exist with the current CVS?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=669861&group_id=10127