parsing an empty container from a rdf file fails to set nextVal

NEW
Unassigned

Status

14 years ago
3 months ago

People

(Reporter: vlad, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

If a container is created using Make{Seq,Bag,Alt} and then serialized to a file
without adding any elements, when it's read, nextVal is never set causing future
uses of RDFContainer to fail.

The parser is using change on an old value that it got from GetTarget, but in
this case there is no old value, and Change fails (InMemoryDS wants oldTarget to
be non-null).
Created attachment 154346 [details] [diff] [review]
rdf-xml-mark-on-change-0.patch

(wrong bug analysis above)

RDFXMLDataSource wasn't doing a Mark on Change (nor Move), and so the nextVal
assertions were getting wiped on the next Sweep.

Also, the in-memory DS isn't checking whether oldtarget/newtarget and/or
oldsource/newsource are the same before doing the unasserts/asserts.  The only
effect that change can maybe have is if the previous assertion had a false
truth value, it wouldn't get updated to true.
Comment on attachment 154346 [details] [diff] [review]
rdf-xml-mark-on-change-0.patch

>     nsresult rv;
> 
>     if (IsLoading() || mIsWritable) {
>         rv = mInner->Change(aSource, aProperty, aOldTarget, aNewTarget);
> 
>+        nsCOMPtr<nsIRDFPurgeableDataSource> gcable = do_QueryInterface(mInner);
>+        if (gcable) {
>+            PRBool didMark;
>+            rv = gcable->Mark(aSource, aProperty, aNewTarget, PR_TRUE, &didMark);
>+            if (NS_FAILED(rv)) return rv;
>+        }
>+
>         if (!IsLoading() && rv == NS_RDF_ASSERTION_ACCEPTED)
>             mIsDirty = PR_TRUE;

Will gcable->Mark() return NS_RDF_ASSERTION_ACCEPTED?  Seems unlikely, so we're
likely to never mark ourselves dirty if we have a purgeable DS.  Might be
better
to use an rv2, or even to compute a PRBool accepted right after calling
->Change().
Attachment #154346 - Flags: review-
Ah, good catch.  Axel had some comments regarding this in irc -- he's thinks
there may be an explicit reason why Change/Move don't mark -- but he mentioend
he won't have time to look at it for a few days.  However, considering that the
one and only use of Change in RDF code is what's causing this particular bug,
I'm unconvinced :)

Updated

3 months ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.