WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
115398
Simplify ContainerNode::removeChildren
https://bugs.webkit.org/show_bug.cgi?id=115398
Summary
Simplify ContainerNode::removeChildren
Ryosuke Niwa
Reported
2013-04-30 00:46:10 PDT
Simplify ContainerNode::removeChildren
Attachments
Cleanup
(2.19 KB, patch)
2013-04-30 00:47 PDT
,
Ryosuke Niwa
no flags
Details
Formatted Diff
Diff
Archive of layout-test-results from webkit-ews-01 for mac-mountainlion
(530.54 KB, application/zip)
2013-04-30 01:54 PDT
,
Build Bot
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Ryosuke Niwa
Comment 1
2013-04-30 00:47:32 PDT
Created
attachment 200087
[details]
Cleanup
Andreas Kling
Comment 2
2013-04-30 00:52:46 PDT
Comment on
attachment 200087
[details]
Cleanup View in context:
https://bugs.webkit.org/attachment.cgi?id=200087&action=review
> Source/WebCore/dom/ContainerNode.cpp:610 > - Vector<RefPtr<Node>, 10> removedChildren; > + NodeVector removedChildren;
I think we should get rid of the NodeVector typedef, or at least give it a less silly default capacity. Since it's always on the stack, we can just as well go with 16, 32 or 64. The goal is presumably to avoid having to allocate a heap buffer, so why not try a little harder?
Ryosuke Niwa
Comment 3
2013-04-30 00:53:42 PDT
Comment on
attachment 200087
[details]
Cleanup View in context:
https://bugs.webkit.org/attachment.cgi?id=200087&action=review
>> Source/WebCore/dom/ContainerNode.cpp:610 >> + NodeVector removedChildren; > > I think we should get rid of the NodeVector typedef, or at least give it a less silly default capacity. > Since it's always on the stack, we can just as well go with 16, 32 or 64. > The goal is presumably to avoid having to allocate a heap buffer, so why not try a little harder?
The last time I checked, 11 was the magic number.
Andreas Kling
Comment 4
2013-04-30 00:59:18 PDT
Comment on
attachment 200087
[details]
Cleanup View in context:
https://bugs.webkit.org/attachment.cgi?id=200087&action=review
>>> Source/WebCore/dom/ContainerNode.cpp:610 >>> + NodeVector removedChildren; >> >> I think we should get rid of the NodeVector typedef, or at least give it a less silly default capacity. >> Since it's always on the stack, we can just as well go with 16, 32 or 64. >> The goal is presumably to avoid having to allocate a heap buffer, so why not try a little harder? > > The last time I checked, 11 was the magic number.
Right, but what is the harm in using a higher number?
Build Bot
Comment 5
2013-04-30 01:54:00 PDT
Comment on
attachment 200087
[details]
Cleanup
Attachment 200087
[details]
did not pass mac-ews (mac): Output:
http://webkit-queues.appspot.com/results/252025
New failing tests: fast/frames/crash-remove-iframe-during-object-beforeload.html
Build Bot
Comment 6
2013-04-30 01:54:02 PDT
Created
attachment 200092
[details]
Archive of layout-test-results from webkit-ews-01 for mac-mountainlion The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: webkit-ews-01 Port: mac-mountainlion Platform: Mac OS X 10.8.2
Ryosuke Niwa
Comment 7
2013-04-30 11:12:56 PDT
Stack trace: 0 com.apple.WebCore 0x0000000106747b24 WTF::KeyValuePair<WebCore::RenderObject*, unsigned int>* WTF::HashTable<WebCore::RenderObject*, WTF::KeyValuePair<WebCore::RenderObject*, unsigned int>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::RenderObject*, unsigned int> >, WTF::PtrHash<WebCore::RenderObject*>, WTF::HashMapValueTraits<WTF::HashTraits<WebCore::RenderObject*>, WTF::HashTraits<unsigned int> >, WTF::HashTraits<WebCore::RenderObject*> >::lookup<WTF::IdentityHashTranslator<WTF::PtrHash<WebCore::RenderObject*> >, WebCore::RenderObject*>(WebCore::RenderObject* const&) + 4 (HashTable.h:609) 1 com.apple.WebCore 0x00000001067227c4 WebCore::AXObjectCache::get(WebCore::RenderObject*) + 36 (HashTable.h:422) 2 com.apple.WebCore 0x0000000106722cd7 WebCore::AXObjectCache::getOrCreate(WebCore::RenderObject*) + 55 (AXObjectCache.cpp:394) 3 com.apple.WebCore 0x00000001068ecbe3 WebCore::Document::implicitClose() + 819 (Document.cpp:2469) 4 com.apple.WebCore 0x0000000106a2d0b1 WebCore::FrameLoader::checkCompleted() + 337 (FrameLoader.cpp:771) 5 com.apple.WebCore 0x0000000106a2bfcc WebCore::FrameLoader::finishedParsing() + 92 (FrameLoader.cpp:704) 6 com.apple.WebCore 0x00000001068f56c9 WebCore::Document::finishedParsing() + 313 (Frame.h:324) 7 com.apple.WebCore 0x0000000106aba198 WebCore::HTMLDocumentParser::prepareToStopParsing() + 168 (HTMLDocumentParser.cpp:756) 8 com.apple.WebCore 0x00000001069128ed WebCore::DocumentWriter::end() + 61 (RefPtr.h:133) 9 com.apple.WebCore 0x00000001069015d3 WebCore::DocumentLoader::finishedLoading(double) + 355 (ResourceErrorBase.h:42) 10 com.apple.WebCore 0x00000001067b488c WebCore::CachedResource::checkNotify() + 76 (CachedResource.cpp:366) 11 com.apple.WebCore 0x00000001067b1954 WebCore::CachedRawResource::data(WTF::PassRefPtr<WebCore::ResourceBuffer>, bool) + 436 (PassRefPtr.h:68) 12 com.apple.WebCore 0x00000001072c2640 WebCore::SubresourceLoader::didFinishLoading(double) + 128 (PassRefPtr.h:68) I don't think this is related to the patch.
Andrei Bucur
Comment 8
2013-04-30 11:21:18 PDT
(In reply to
comment #7
)
> Stack trace: > 0 com.apple.WebCore 0x0000000106747b24 WTF::KeyValuePair<WebCore::RenderObject*, unsigned int>* WTF::HashTable<WebCore::RenderObject*, WTF::KeyValuePair<WebCore::RenderObject*, unsigned int>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::RenderObject*, unsigned int> >, WTF::PtrHash<WebCore::RenderObject*>, WTF::HashMapValueTraits<WTF::HashTraits<WebCore::RenderObject*>, WTF::HashTraits<unsigned int> >, WTF::HashTraits<WebCore::RenderObject*> >::lookup<WTF::IdentityHashTranslator<WTF::PtrHash<WebCore::RenderObject*> >, WebCore::RenderObject*>(WebCore::RenderObject* const&) + 4 (HashTable.h:609) > 1 com.apple.WebCore 0x00000001067227c4 WebCore::AXObjectCache::get(WebCore::RenderObject*) + 36 (HashTable.h:422) > 2 com.apple.WebCore 0x0000000106722cd7 WebCore::AXObjectCache::getOrCreate(WebCore::RenderObject*) + 55 (AXObjectCache.cpp:394) > 3 com.apple.WebCore 0x00000001068ecbe3 WebCore::Document::implicitClose() + 819 (Document.cpp:2469) > 4 com.apple.WebCore 0x0000000106a2d0b1 WebCore::FrameLoader::checkCompleted() + 337 (FrameLoader.cpp:771) > 5 com.apple.WebCore 0x0000000106a2bfcc WebCore::FrameLoader::finishedParsing() + 92 (FrameLoader.cpp:704) > 6 com.apple.WebCore 0x00000001068f56c9 WebCore::Document::finishedParsing() + 313 (Frame.h:324) > 7 com.apple.WebCore 0x0000000106aba198 WebCore::HTMLDocumentParser::prepareToStopParsing() + 168 (HTMLDocumentParser.cpp:756) > 8 com.apple.WebCore 0x00000001069128ed WebCore::DocumentWriter::end() + 61 (RefPtr.h:133) > 9 com.apple.WebCore 0x00000001069015d3 WebCore::DocumentLoader::finishedLoading(double) + 355 (ResourceErrorBase.h:42) > 10 com.apple.WebCore 0x00000001067b488c WebCore::CachedResource::checkNotify() + 76 (CachedResource.cpp:366) > 11 com.apple.WebCore 0x00000001067b1954 WebCore::CachedRawResource::data(WTF::PassRefPtr<WebCore::ResourceBuffer>, bool) + 436 (PassRefPtr.h:68) > 12 com.apple.WebCore 0x00000001072c2640 WebCore::SubresourceLoader::didFinishLoading(double) + 128 (PassRefPtr.h:68) > > I don't think this is related to the patch.
FYI, I wasn't able to repro the crash on my machine.
WebKit Commit Bot
Comment 9
2013-04-30 11:43:45 PDT
Comment on
attachment 200087
[details]
Cleanup Clearing flags on attachment: 200087 Committed
r149386
: <
http://trac.webkit.org/changeset/149386
>
WebKit Commit Bot
Comment 10
2013-04-30 11:43:48 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug