I'll follow up with a reproduce case. Basically, the m_selectionStart and End members of RenderView are being kept past the lifetime of the RenderObjects they refer to. I've only seen it happen as a document is being destroyed. This can cause crashes on Windows, but is still a problem on all platforms.
Created attachment 12314 [details] sets assertions to catch dangling ref Apply the test.patch I attached, build-webkit, and run gdb-safari. Load the following layout test from svn: LayoutTests/dom/html/level2/html/HTMLInputElement22.html . The ASSERT should fire.
Created attachment 12317 [details] simplified test page This is a simplified test case. Point a patched version of safari at this html page instead of the layout test. (I basically gutted the layout test to include only what causes the assert/crash).
Created attachment 12320 [details] proposed patch enums are signed on Windows, so in this case, m_selectionState = 4 results in m_selectionState == -4. This was causing a RenderText object not to be recognized as selected, so it was deleted without clearing the selection, resulting in a dangling ref to it. I was wrong that this applied to Mac as well. It appears Mac treats enums as unsigned in this case. My asserts were firing for other reasons.
Comment on attachment 12320 [details] proposed patch Change looks fine, but there should be a comment to prevent a future programmer from changing it back again. Also the change log as attached here isn't landable.
Created attachment 12323 [details] fixed patch as darin requested
Comment on attachment 12323 [details] fixed patch as darin requested r=me
I would have liked to put those assertions into RenderView too, but they still fire. Maybe there's still a real bug here.
Comment on attachment 12323 [details] fixed patch as darin requested Committed revision 18709. Clearing the review flag on the patch because the bug may need to stay open anyway.
I think it's OK that the assertions fire, because that code (setSelection) gets called from within RenderObject::destroy() (via RenderContainer::removeChild). As part of the cleanup of the object, it clears the selection, which calls that code. (Before this patch, setSelection wouldn't get called until after destroy() was finished, which was definitely bad).
I agree with the previous comment, these assertions seem too string to try and make them always pass.