aboutsummaryrefslogtreecommitdiff
path: root/src/common/dwarf_cu_to_module.cc
diff options
context:
space:
mode:
authorbenchan@chromium.org <benchan@chromium.org>2015-02-02 23:27:27 +0000
committerbenchan@chromium.org <benchan@chromium.org>2015-02-02 23:27:27 +0000
commit4c01a9c389ffcfb29bb1c2a4239804019eddc3d6 (patch)
tree6e529f8734a13e431b537dc9499a29e79beeece7 /src/common/dwarf_cu_to_module.cc
parentReplace uses of hash_map with unordered_map (diff)
downloadbreakpad-4c01a9c389ffcfb29bb1c2a4239804019eddc3d6.tar.xz
Handle failures of copying process data from a core file.
When LinuxCoreDumper fails to copy process data from a core file, it fills the return buffer with a repeated sequence of a special marker. However, MinidumpWriter doesn't know about that and may incorrectly interpret the data. In many cases, MinidumpWriter simply copies the gibberish data to the minidump, which isn't too bad. However, the gibberish data may cause MinidumpWriter to behave badly in some other cases. For example, when MinidumpWriter tries to iterate through the linked list of all loaded DSOs via the r_map field of a r_debug struct, if the linked list is filed with the special marker, the code keeps iterating through the same address. This CL addresses the issue by having LinuxCoreDumper::CopyFromProcess() returns a Boolean value to indicate if the expected data is found from the core file. MinidumpWriter can then decide how to handle that. BUG=chromium:453484 TEST=Run core2md with the test data attached to chromium:453484. R=mark@chromium.org Review URL: https://breakpad.appspot.com/4724002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1420 4c0a9323-5329-0410-9bdc-e9ce6186880e
Diffstat (limited to 'src/common/dwarf_cu_to_module.cc')
0 files changed, 0 insertions, 0 deletions