<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - llvm-pdbutil dump -symbols crash with InlineSiteSym and Inlinee TypeIndex 0x8000002a"
href="https://bugs.llvm.org/show_bug.cgi?id=35550">35550</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>llvm-pdbutil dump -symbols crash with InlineSiteSym and Inlinee TypeIndex 0x8000002a
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>DebugInfo
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>scott@GameRanger.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=19523" name="attach_19523" title="gdb_backtrace.txt">attachment 19523</a> <a href="attachment.cgi?id=19523&action=edit" title="gdb_backtrace.txt">[details]</a></span>
gdb_backtrace.txt
Overview: llvm-pdbutil dump -symbols crashes when LazyRandomTypeCollection
tries to allocate an invalid size, due to an InlineSiteSym with an Inlinee
TypeIndex with the high bit set (0x8000002a).
Steps to Reproduce:
1) PDB file:
<a href="http://opensource.spotify.com/cefbuilds/cef_binary_3.2704.1414.g185cd6c_windows32_release_symbols.tar.bz2">http://opensource.spotify.com/cefbuilds/cef_binary_3.2704.1414.g185cd6c_windows32_release_symbols.tar.bz2</a>
(libcef.dll.pdf is roughly 1GB after expanding)
2) llvm-pdbutil dump -symbols libcef.dll.pdb > libcef.dll.pdb.symbols
Actual Results: llvm-pdbutil crashes with a bad-alloc. The
libcef.dll.pdb.symbols file size is 877776896 bytes at this point.
The last lines in the output file before the crash are:
Mod 9026 | `obj\base\strings\base.utf_string_conversions.obj`:
4 | S_OBJNAME [size = 100] sig=0,
`y:\work\cef3_git\chromium\src\out\release\obj\base\strings\base.utf_string_conversions.obj`
104 | S_COMPILE3 [size = 60]
machine = intel pentium 3, Ver = Microsoft (R) Optimizing Compiler,
language = c++
frontend = 19.0.23918.0, backend = 19.0.23918.0
flags = ltcg | security checks
164 | S_BUILDINFO [size = 8] BuildId = `0x142AB8`
172 | S_GPROC32 [size = 212]
`std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
<span class="quote">>::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
><char const *,void>`</span >
parent = 0, end = 800, addr = 0001:575872, code size = 52
type = `0x7D9F (void std::basic_string<wchar_t,s...)`, debug start =
9, debug end = 46, flags = has fp | opt debuginfo
384 | S_LOCAL [size = 16] `this`
type=0x1182 (const std::basic_string<wchar_t,...), flags = param
400 | S_DEFRANGE_REGISTER [size = 16]
register = 18, may have no name = 0, range start = 0001:575872, length
= 9
gaps = []
416 | S_DEFRANGE_REGISTER [size = 16]
register = 23, may have no name = 0, range start = 0001:575881, length
= 37
gaps = []
Expected Results: No crash. :)
Build Date & Hardware: Tested today (2017-12-06) with trunk (Revision: 319898)
on CentOS 7.4
Additional Builds and Platforms: Also crashed on Mac OS X, with a build a week
earlier, but this isn't platform specific.
Additional Information: This was built with VS2015u2, however I've seen this on
another build/version of the DLL with VS2013.
[ gdb backtrace as attachment ]
(gdb) frame 15
#15 0x00000000004dd90b in llvm::pdb::MinimalSymbolDumper::visitKnownRecord
(this=0x7ffcc0d823c0, CVR=..., IS=...)
at
/home/build/llvm-build/llvm/tools/llvm-pdbutil/MinimalSymbolDumper.cpp:631
631 IS.Parent, IS.End);
(gdb) print /x IS
$1 = (llvm::codeview::InlineSiteSym &) @0x7ffcc0d81d70:
{<llvm::codeview::SymbolRecord> = {Kind = 0x114d}, Parent = 0xac, End = 0x2a8,
Inlinee = {
static FirstNonSimpleIndex = 0x1000, static SimpleKindMask = 0xff, static
SimpleModeMask = 0x700, Index = {Value = {buffer = {0x2a, 0x0, 0x0, 0x80}}}},
AnnotationData = std::vector of length 16, capacity 16 = {0x6, 0x2, 0xc, 0x2,
0x5, 0x6, 0x3, 0xc, 0x7, 0xd, 0x6, 0x2, 0xc, 0xa, 0xa, 0x0}, RecordOffset =
0x0}
(gdb) print /x (uint32_t) IS.Inlinee.Index
$2 = 0x8000002a
>From a quick look through Microsoft's cvinfo.h, it looks like this is actually
a FuncId / DecoratedItemId:
typedef struct INLINESITESYM {
unsigned short reclen; // Record length
unsigned short rectyp; // S_INLINESITE
unsigned long pParent; // pointer to the inliner
unsigned long pEnd; // pointer to this block's end
CV_ItemId inlinee; // CV_ItemId of inlinee
unsigned char binaryAnnotations[CV_ZEROLEN]; // an array of compressed
binary annotations.
} INLINESITESYM;
// Combined encoding of TI or FuncId, In compiler implementation
// Id prefixed by 1 if it is function ID.
typedef struct DecoratedItemId
{
DecoratedItemId(bool isFuncId, CV_ItemId inputId) {
if (isFuncId) {
decoratedItemId = 0x80000000 | inputId;
} else {
decoratedItemId = inputId;
}
}
DecoratedItemId(CV_ItemId encodedId) {
decoratedItemId = encodedId;
}
operator unsigned int() {
return decoratedItemId;
}
bool IsFuncId()
{
return (decoratedItemId & 0x80000000) == 0x80000000;
}
CV_ItemId GetItemId()
{
return decoratedItemId & 0x7fffffff;
}
private:
unsigned int decoratedItemId;
} DecoratedItemId;</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>