DynamoRIO / DynamoRIO/drmemory

DrMemory full mode uses too much memory, causing app alloc failures on Chrome unit_tests

Open
#792 11 comments 0 reactions 0 assignees View on GitHub
Bug-AppFail Migrated Priority-Medium
Dominant language
C
Stars
2.7k
Forks
290
PR merge metrics
No merged PRs in 30d

Description

_From [rnk@google.com](https://code.google.com/u/rnk@google.com/) on February 23, 2012 10:51:40_

Example build: http://build.chromium.org/p/chromium.fyi/builders/Windows%20Tests%20%28DrMemory%20full%29/builds/936 See unit_tests shard 1 of 3 in particular: http://build.chromium.org/p/chromium.fyi/builders/Windows%20Tests%20%28DrMemory%20full%29/builds/936/steps/memory%20test%3A%20unit_1/logs/stdio We run for awhile and eventually we get some warnings about failed heap allocations:
[ RUN ] ExtensionServiceTest.InstallTheme
~~Dr.M~~
~~Dr.M~~ Error `#133`: WARNING: heap allocation failed
~~Dr.M~~ # 0 (0x22b80048)
~~Dr.M~~ # 1 Pickle::Resize [base\pickle.cc:405]
~~Dr.M~~ # 2 Pickle::BeginWrite [base\pickle.cc:383]
~~Dr.M~~ # 3 Pickle::WriteBytes [base\pickle.cc:330]
~~Dr.M~~ # 4 Pickle::WriteData [base\pickle.cc:324]
~~Dr.M~~ # 5 IPC::ParamTraits::Write [content\public\common\common_param_traits.cc:538]
~~Dr.M~~ # 6 IPC::WriteParam [ipc\ipc_message_utils.h:169]
~~Dr.M~~ # 7 IPC::ParamTraits >::Write [ipc\ipc_message_utils.h:897]
~~Dr.M~~ # 8 IPC::WriteParam > [ipc\ipc_message_utils.h:169]
~~Dr.M~~ # 9 IPC::ParamTraitsstd::vector > > >::Write [ipc\ipc_message_utils.h:541]
~~Dr.M~~ `#10` IPC::WriteParamstd::vector > > > [ipc\ipc_message_utils.h:169]
~~Dr.M~~ `#11` ExtensionUnpacker::DumpImagesToFile [chrome\common\extensions\extension_unpacker.cc:218]
~~Dr.M~~ `#12` SandboxedExtensionUnpacker::Start [chrome\browser\extensions\sandboxed_extension_unpacker.cc:275]
~~Dr.M~~ `#13` base::internal::RunnableAdapter::Run [base\bind_internal.h:132]
~~Dr.M~~ Note: @0:36:37.300 in thread 3652

The app crashes and does a self-backtrace afterwards.

We should repro this locally and gather statistics about what is taking the most memory. My best guesses are that we're generating and suppressing lots of reports, so we may be holding too many packed callstacks. Alternatively, maybe the delayed freelist is too long. Or dbghelp is using lots of memory.

For the moment I'm going to try splitting unit_tests into 6 shards to see if that lets us get further.

_Original issue: http://code.google.com/p/drmemory/issues/detail?id=792_

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.