[Expat-bugs] [ expat-Bugs-667511 ] additional patch for #618199

[SourceForge.net]

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

Category: None
>Group: Test Required
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: additional patch for #618199

Initial Comment:
The attached patch ensures that localPart will point to TAG.buf 
when storeRawNames is called. 
 
There was no need to replace the TAG_NAME.str with the 
keyname for the ELEMENT_TYPE hash entry since the pool 
takes care of deallocating it (keyname) when the pool is 
destroyed. 

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-20 23:39

Message:
Logged In: YES 
user_id=3066

This should be moved to the "Test Required" group, but there
isn't enough information in the report to reproduce the
problem, so I'm closing it instead.

Jeremy, if you are able to provide enough information to
reproduce this, please insist that we re-open this report or
open a new one with the information.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-14 19:57

Message:
Logged In: YES 
user_id=290026

Patch applied in rev. 1.101 of xmlparse.c.

Assigned to Fred for regression testing.
However, no reproducible bug description was supplied by
the author of this bug report.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-14 12:48

Message:
Logged In: YES 
user_id=290026

I looked at storeAtts, and I agree with your assessment.
tag->name.str is always pointing into tag->buf when 
passed to storeAtts() (except for empty elements, but 
for that storeRawnames won't get called).

tag->name.localPart is set to point to tag->name.str 
inside of  storeAtts(). So, if tag->name.str gets 
reassigned inside storeAtts() before assigning it to 
localPart then localPart will not point into tag->buf 
anymore.

I will apply your patch soon.


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

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-14 04:16

Message:
Logged In: YES 
user_id=38980

Sorry, I cannot trim a problem to a small test case.  It seems to 
require a certain amount of additional malloc/realloc/free that I 
cannot determine.  I can say that it only happens when doing multiple 
XML_ParseBuffer calls.  Eith debug prints I traced the error to where 
storeRawNames updates the TAG_NAME.localPart.   
 
The problem is that it should only be updated when localPart points 
into tag->buf, which it almost always does.  The exception to this is 
addressed by my patch.  To fix this in storeRawNames would add 
overhead that is not required if TAG_NAME.str is not redefined before 
TAG_NAME.localPart is defined in storeAtts. 

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-13 23:05

Message:
Logged In: YES 
user_id=290026

I think you meant to say:

"The attached patch ensures that TAG_NAME.str will point to
TAG.buf when storeRawNames is called."

Your changes make sense to me, but I am not sure
that there is a bug, since TAG_NAME.str doesn't need
to be updated when it does not point to tag->buf.

Is there a specific case where it fails for you?
If yes, would you please give us the details, so that
we can build a regression test for the patch?

Thanks! 




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

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-13 21:34

Message:
Logged In: YES 
user_id=38980

Oops... 
Here is the attachment again 

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-13 21:06

Message:
Logged In: YES 
user_id=290026

Two things:

- I can't see the attachment
- Does this apply to the current CVS?

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

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