Jesse Ruderman Reporter
	Description • 15 years ago

###!!! ASSERTION: unknown nsISVGValue: 'Not Reached', file /Users/jruderman/mozilla-central/content/svg/content/src/nsSVGElement.cpp, line 969

	Daniel Holbert [:dholbert]
	Comment 1 • 15 years ago

This is WORKSFORME in a Linux debug build from today. I get this output at pageload:
{
nsSVGStringProxyValue CTOR
nsSVGStringProxyValue(0xaf971b40)::SetValueString(10 20)
  -> call failed, now using cached value
}
but no assertion failures.

Jesse, mind verifying?

	Daniel Holbert [:dholbert]
	Comment 2 • 15 years ago

(In reply to comment #1)
> nsSVGStringProxyValue CTOR
> nsSVGStringProxyValue(0xaf971b40)::SetValueString(10 20)
>   -> call failed, now using cached value

FWIW, this appears to be non-scary output, from glancing at the source:
http://mxr.mozilla.org/mozilla-central/source/content/svg/content/src/nsSVGStringProxyValue.cpp#112
http://mxr.mozilla.org/mozilla-central/source/content/svg/content/src/nsSVGStringProxyValue.cpp#150

	Daniel Holbert [:dholbert]
	Comment 3 • 15 years ago

(see also Bug 556808, for another instance of this "unknown nsISVGValue" assertion failure.)

	Jesse Ruderman Reporter
	Comment 4 • 15 years ago

Yeah, WFM.  I'll add this as a crashtest.

	Jesse Ruderman Reporter
	Comment 5 • 14 years ago

Crashtest added: http://hg.mozilla.org/mozilla-central/rev/d3e7c18f58fc

	Henri Sivonen (:hsivonen) (away from Bugzilla until 2023-09-11)
	Comment 6 • 14 years ago

The patch for bug 552938 regresses this. Why might that be?

	Henri Sivonen (:hsivonen) (away from Bugzilla until 2023-09-11)
	Comment 7 • 14 years ago

I can't reproduce the problem on either Mac 32-bit or Linux 64-bit. How should I proceed with the patch for bug 552938? Would it be too inappropriate to land it and reopen this bug?

	Robert Longson [:longsonr]
	Comment 8 • 14 years ago

I don't get any asserts on Windows with the testcase with your patch from bug 552938.

	Jesse Ruderman Reporter
	Comment 9 • 14 years ago

I wouldn't especially mind.  Be sure to add asserts(0-1) or asserts(1) to the crashtest manifest so you don't turn the tree orange.

	Jesse Ruderman Reporter
	Comment 11 • 14 years ago

Comment on attachment 449588 [details] [diff] [review]
Add an assertion annotation

I take it the assertion can happen up to twice?

Please add a comment on the line pointing back to this bug, so we're more likely to remember to remove the asserts() if this bug becomes WFM again:

+asserts(0-2) load 535691-1.svg # bug 535691

Btw, if a stack trace from Try would help you figure out why this happens, you can push your patch for bug 552938 with my patch for bug 570287.

	Henri Sivonen (:hsivonen) (away from Bugzilla until 2023-09-11)
	Comment 12 • 14 years ago

(In reply to comment #11)
> (From update of attachment 449588 [details] [diff] [review])
> I take it the assertion can happen up to twice?
> 
> Please add a comment on the line pointing back to this bug, so we're more
> likely to remember to remove the asserts() if this bug becomes WFM again:
> 
> +asserts(0-2) load 535691-1.svg # bug 535691

Thanks. Landed with the comment:
http://hg.mozilla.org/mozilla-central/rev/d36a5c77457f

> Btw, if a stack trace from Try would help you figure out why this happens, you
> can push your patch for bug 552938 with my patch for bug 570287.

OK. Thanks.

	Brian Birtles (:birtles)
	Comment 13 • 14 years ago

This should now be fixed by bug 603917, specifically changeset http://hg.mozilla.org/mozilla-central/rev/4e06966e8dfe

I'll wait to check that everything is fine on tinderbox (TryServer was all good) and, unless there are any objections, mark this fixed.