search

llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
28.16k stars 11.62k forks source link

Bad debug info when inlining #22921

Open nico opened 9 years ago

nico commented 9 years ago
Bugzilla Link 22547
Version trunk
OS All
CC @dwblaikie,@DougGregor,@echristo

Extended Description

clang/asan gave us this stack for something going wrong:

==2120==ERROR: AddressSanitizer: heap-use-after-free on address 0x1701b5e4 at pc 0x0b77244f bp 0xdeadbeef sp 0x0028ae3c READ of size 4 at 0x1701b5e4 thread T0

​0 0xb77244e in content::FrameAccessibility::GetParent C:\b\build\slave\CrWinAsan\build\src\base\memory\scoped_ptr.h:251

#​1 0xb214bbc in content::RenderFrameHostImpl::AccessibilityGetParentFrame C:\b\build\slave\CrWinAsan\build\src\content\browser\frame_host\render_frame_host_impl.cc:530
#​2 0xb1abc0e in content::BrowserAccessibilityManager::GetDelegateFromRootManager C:\b\build\slave\CrWinAsan\build\src\content\browser\accessibility\browser_accessibility_manager.cc:461

Note how the top line points at scoped_ptr.h. A different, cl.exe-based tool (I think) gives the right location:

BEGIN MEMORY TOOL REPORT (error hash=#AFC58CEC99C34439#)

UNADDRESSABLE ACCESS of freed memory: reading 0x02d9b69c-0x02d9b6a0 4 byte(s)

0 content.dll!content::FrameAccessibility::GetParent [content\browser\frame_host\frame_accessibility.cc:163]

1 content.dll!content::RenderFrameHostImpl::AccessibilityGetParentFrame [content\browser\frame_host\render_frame_host_impl.cc:512]

2 content.dll!content::BrowserAccessibilityManager::GetDelegateFromRootManager [content\browser\accessibility\browser_accessibility_manager.cc:443]

(never mind the shifting line numbers, they're at slighly different revisions.)

The code in question is https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/frame_host/frame_accessibility.cc&l=163 .

nico commented 9 years ago

Yes, will definitely get you a repro tomorrow.

dwblaikie commented 9 years ago

Nothing obvious I can see from the stack/source (not sure which variables might be scoped_ptrs there, etc).

A preprocessed source file, command line (preferably clang -cc1) to produce an object file would be helpful.

(to check that these steps reproduce the problem, checking the asm output to see that the use is in a line entry attributed to scoped_ptr.h would be handy)

nico commented 9 years ago

(note to self: extracted from http://crbug.com/455060)

llvmbot commented 1 year ago

@llvm/issue-subscribers-debuginfo