Issue metadata
Sign in to add a comment
|
ChromeCrashReporterClient::GetShouldDumpLargerDumps doesn't affect dump size
Reported by
rkuk...@yandex-team.ru,
Mar 31 2017
|
||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 Steps to reproduce the problem: 1. Setup chromium repo on local machine 2. Paste "if (true)" here: https://cs.chromium.org/chromium/src/components/crash/content/app/crashpad_win.cc?rcl=d0d7b778255e08f2631af09016db8f172215a89e&l=89 3. Build target chrome 4. Run browser and navigate to chrome://crash What is the expected behavior? directory "%localappdata%\Chromium\User Data\Crashpad\reports" contains a large .dmp file What went wrong? .dmp files are small Crashed report ID: How much crashed? Just one tab Is it a problem with a plugin? No Did this work before? Yes Chrome version: 59.0.3057.0 dev Channel: n/a OS Version: 10.0 Flash Version: Shockwave Flash 25.0 r0 my gn args: is_win_fastlink=true is_component_build=true is_debug=true enable_nacl=false
,
Apr 5 2017
,
Feb 13 2018
,
Feb 22 2018
scottmg: Does this seem expected?
,
Feb 23 2018
set_gather_indirectly_referenced_memory attempts to dereference an extra level from pointer-like things on the stack, but there might not be very much to capture for a chrome://crash crash. Just to clarify (since you mentioned pasting if (true)), is it set_gather_indirectly_referenced_memory() that seems wrong, or the plumbing of GetShouldDumpLargerDumps() as mentioned in the title of the bug? |
|||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||
Comment 1 by ranjitkan@chromium.org
, Apr 4 2017