Closed Bug 591726 Opened 14 years ago Closed 13 years ago

Intermittent failure in test_tmpl_simplesyntaxusingdontrecurse.xul | Error is: attribute container is '' instead of 'true' - got "<hbox id=\"http://www.some-fictitious-zoo.com/arachnids\"><label value=\"Arachnids\"/></hbox><hbox id=\"http://www.some-fict

Categories

(Core :: XUL, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: philor, Unassigned)

References

Details

(Keywords: intermittent-failure, Whiteboard: [debugging in comment 281])

http://tinderbox.mozilla.org/showlog.cgi?log=TraceMonkey/1283057716.1283059371.17257.gz
Rev3 MacOSX Snow Leopard 10.6.2 tracemonkey debug test mochitest-other on 2010/08/28 21:55:16
s: talos-r3-snow-037

623 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/content/xul/templates/tests/chrome/test_tmpl_simplesyntaxusingdontrecurse.xul | simple syntax using dont-recurse
624 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/content/xul/templates/tests/chrome/test_tmpl_simplesyntaxusingdontrecurse.xul | Error is: attribute container is '' instead of  'true' - got "<hbox id=\"http://www.some-fictitious-zoo.com/arachnids\"><label value=\"Arachnids\"/></hbox><hbox id=\"http://www.some-fictitious-zoo.com/birds\"><label value=\"Birds\"/></hbox>", expected "Same"
OS: Mac OS X → All
Hardware: x86_64 → All
I've spent some time looking into this failure.  I can reproduce it consistently the first time I run a new with with the mochitest, and then it conveniently passes when I refresh the window, so I've been using those two runs to evaluate what's missing from the first time.

Basically, the container and empty attributes should be applied automatically by nsXULContentBuilder::BuildContentFromTemplate in the isGenerationElement branch (http://dxr.mozilla.org/mozilla-central/content/xul/templates/src/nsXULContentBuilder.cpp.html#l638).  It calls nsXULContentBuilder::SetContainerAttrs, but the call to GetIsContainer fails so the attributes are never applied.

As to the cause of the failure, I'm investigating.  What I've discovered is that in the passing cases nsRDFContainerUtils::IsContainer calls Is(..., kRDF_Seq) (http://dxr.mozilla.org/mozilla-central/rdf/base/src/nsRDFContainerUtils.cpp.html#229) which ends up in InMemoryDataSource::HasAssertion.  Here, the call to GetForwardArcs returns a non-null result when passing, and null when failing.  More information as it becomes available.
Whiteboard: [orange] → [orange][debugging in comment 281]
So gdb shows me that the container elements are created with the proper RDF_instanceof assertion, but later when actually checking for containers, we're apparently looking at other nearly identical elements that are lacking them.  This is quite confusing to me.
Depends on: 611313
Seems to have gone away despite a few occurrences after bug 611313 was fixed.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [orange][debugging in comment 281] → [debugging in comment 281]
You need to log in before you can comment on or make changes to this bug.