My favorites | Sign in
Logo
Project Home
  
Downloads
  
Wiki
  
Issues
    
New issue | Search
for
| Advanced search | Search tips
Issue 11213: Memory leak in WebCore::ResourceHandle::create
5 people starred this issue and may be notified of changes. Back to list
 
Reported by dank@chromium.org, Apr 29, 2009 
I think this is how I found this warning:
export GTEST_TOTAL_SHARDS=17
export GTEST_SHARD_INDEX=13
sh tools/valgrind/chrome_tests.sh -t ui 

Stack:
3,896 (24 direct, 3,872 indirect) bytes in 2 blocks are definitely lost in loss record 377 of
412
   at operator new(unsigned int) vg_replace_malloc.c:214
   by WebCore::ResourceHandle::create(WebCore::ResourceRequest const&,
WebCore::ResourceHandleClient*, WebCore::Frame*, bool, bool, bool)
webkit/glue/resource_handle_impl.cc:652
   by WebCore::ResourceLoader::load(WebCore::ResourceRequest const&)
third_party/WebKit/WebCore/loader/ResourceLoader.cpp:131
   by WebCore::SubresourceLoader::create(WebCore::Frame*,
WebCore::SubresourceLoaderClient*, WebCore::ResourceRequest const&, bool, bool, bool)
third_party/WebKit/WebCore/loader/SubresourceLoader.cpp:101
   by WebCore::Loader::Host::servePendingRequests(WTF::Deque<WebCore::Request*>&,
bool&) third_party/WebKit/WebCore/loader/loader.cpp:261
   by WebCore::Loader::Host::servePendingRequests(WebCore::Loader::Priority)
third_party/WebKit/WebCore/loader/loader.cpp:213
   by WebCore::Loader::load(WebCore::DocLoader*, WebCore::CachedResource*, bool, bool,
bool) third_party/WebKit/WebCore/loader/loader.cpp:121
   by WebCore::CachedResource::load(WebCore::DocLoader*, bool, bool, bool)
third_party/WebKit/WebCore/loader/CachedResource.cpp:107
...
Comment 1 by dank@chromium.org, Apr 30, 2009 
More precisely, it's TabRestoreUITest.RestoreToDifferentWindow
Comment 2 by dank@chromium.org, May 05, 2009 
Also seen after AutomationProxyTest.AutocompleteParallelProxy
Comment 3 by dank@chromium.org, May 05, 2009 
To repeat, let this run twenty or so iterations:

while true 
do
    sh tools/valgrind/chrome_tests.sh -t ui --generate_suppressions --
done
Comment 4 by jon@chromium.org, Jun 09, 2009 
(No comment was entered for this change.)
Status: Available
Labels: -Pri-2 -Area-Misc Pri-1 Area-WebKit Mstone-4
Comment 5 by huanr@chromium.org, Jun 25, 2009 
(No comment was entered for this change.)
Labels: Fixit
Comment 6 by huanr@chromium.org, Jun 29, 2009 
(No comment was entered for this change.)
Status: Assigned
Owner: vict...@chromium.org
Comment 7 by vict...@chromium.org, Jul 01, 2009 
Looks like this needs to be repro and debugged on linux box with valgrind. I don't have 
strong knowledge in this area. I could setup a linux development environment to look 
into this if needed. It may take some time to ramp up. Let me know if there is an 
better way to track this down, or repro on Windows machine.
Comment 8 by vict...@chromium.org, Jul 09, 2009 
Cannot repro this.

TabRestoreUITest.RestoreToDifferentWindow is disabled so I reenabled it and tried:
1. sh tools/valgrind/chrome_tests.sh -t ui --
gtest_filter=RestoreUITest.RestoreToDifferentWindow
2. sh tools/valgrind/chrome_tests.sh -t ui
3. repeat running it 20 times as suggested above.
4. run it with or without GTEST_TOTAL_SHARDS and GTEST_SHARD_INDEX.
5. remove the error for this bug from suppressions.txt and repeat above.

Dan, let me know if I miss anything.
Owner: d...@chromium.org
Cc: vict...@chromium.org
Comment 9 by mattm@chromium.org, Oct 27, 2009 
This still shows up on the bots.  A sampling of recent runs which had it:
Linux_Tests_(valgrind)(1).ui.779.txt:      1 bug_11213
Linux_Tests_(valgrind)(1).ui.785.txt:     20 bug_11213
Linux_Tests_(valgrind)(2).ui.1080.txt:     20 bug_11213
Linux_Tests_(valgrind)(2).ui.1083.txt:     30 bug_11213
Linux_Tests_(valgrind)(4).ui.1220.txt:      2 bug_11213
Linux_Tests_(valgrind)(4).ui.1222.txt:      1 bug_11213
Webkit_Linux_(valgrind_layout).layout.2946.txt:     28 bug_11213
Cc: ma...@chromium.org
Comment 10 by mattm@chromium.org, Oct 27, 2009 
I should note that TabRestoreUITest.FLAKY_RestoreToDifferentWindow only shows up in 
logs from Linux_Tests_(valgrind)(3), so it would seem that test doesn't trigger the 
leak anymore.
Comment 11 by daniel.r.kegel, Oct 28, 2009 
I think it showed up in TabRestoreUITest.RestoreIntoSameWindow
in the most recent build,
http://build.chromium.org/buildbot/waterfall/builders/Linux%20Tests%20(valgrind)(2)/bui
lds/1127/steps/valgrind%20test:%20ui/logs/stdio
I'll try to reproduce.
Comment 12 by dank@chromium.org, Nov 02, 2009 
It's still happening on the bot, but I can't reproduce this locally with
the ui tests.
Which layout test showed the problem?
Comment 13 by mattm@chromium.org, Nov 02, 2009 
I don't think you can tell exactly which one from the bot logs, but it was one of 
these:
http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Linux%20(valgrind%20lay
out)/builds/2946/steps/valgrind%20test:%20layout/logs/stdio
Comment 14 by daniel.r.kegel, Nov 04, 2009 
I'm trying to repro now.

(Sorry for the delay.  I took a detour to write a tool to
scrape the valgrind layout bots and reproduce errors locally,
tools/valgrind/regrind.sh, and filed 3 bugs (two with fixes) for the
nonleak errors it found.)
Comment 15 by dank@chromium.org, Nov 13, 2009 
Sorry, I've been wrestling with windows memory test rigs,
didn't have time.  It's only a leak, let's defer it to mstone 5.
Labels: -Mstone-4 Mstone-5
Sign in to add a comment