<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 - Memory errors in DIBuilder::createFile() that result in a seg fault"
href="https://bugs.llvm.org/show_bug.cgi?id=38310">38310</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Memory errors in DIBuilder::createFile() that result in a seg fault
</td>
</tr>
<tr>
<th>Product</th>
<td>new-bugs
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>vext01@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Hi,
I was doing some simple code-gen using the C++ API from llvm-7 (trunk) and I
think I've found some memory errors.
Here's a minimal example, xxx.cpp:
```
#include "llvm/IR/LLVMContext.h"
#include "llvm/IR/Module.h"
#include "llvm/IR/DIBuilder.h"
#include <iostream>
using namespace llvm;
int
main(void)
{
LLVMContext TheContext;
StringRef ModName("mymod");
Module TheModule(ModName, TheContext);
DIBuilder DBuilder(TheModule);
StringRef DFile("main.xxx");
StringRef DDir(".");
std::cout << "making the file" << std::endl;
DBuilder.createFile(DFile, DDir);
std::cout << "made the file" << std::endl;
return 0;
}
```
I have two versions of LLVM to test this with:
```
$ llvm-config-6.0 --version
6.0.1
$ llvm-config --version
7.0.0svn
```
LLVM-6.0.1 is from the llvm apt repo, and LLVM-7.0 is manually built from trunk
(last tried using the 2018-07-25 code).
And here's the Makefile used to build using those versions:
```
BIN=xxx
all: ${BIN}-6 ${BIN}-7
${BIN}-6: ${BIN}.cpp
clang++ -g $< `llvm-config-6.0 --cxxflags --ldflags --system-libs
--libs core` -o $@
${BIN}-7: ${BIN}.cpp
clang++ -g $< `llvm-config --cxxflags --ldflags --system-libs --libs
core` -o $@
```
After building, this program works fine under LLVM-6.0.1, but crashes on trunk:
```
$ ./xxx-6
making the file
made the file
$ ./xxx-7
making the file
Segmentation fault
```
Here's a trace, sadly it's not very useful:
```
(gdb) run
Starting program: /home/vext01/research/llvm-api-examples/xxx/xxx-7
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
making the file
Program received signal SIGSEGV, Segmentation fault.
0x00000000004080d9 in llvm::DIBuilder::createFile(llvm::StringRef,
llvm::StringRef, llvm::Optional<llvm::DIFile::ChecksumInfo<llvm::StringRef> >,
llvm::Optional<llvm::StringRef>) ()
(gdb) bt
#0 0x00000000004080d9 in llvm::DIBuilder::createFile(llvm::StringRef,
llvm::StringRef, llvm::Optional<llvm::DIFile::ChecksumInfo<llvm::StringRef> >,
llvm::Optional<llvm::StringRef>) ()
#1 0x000000000040799b in main () at xxx.cpp:21
```
If we valgrind the non-crashing 6.0.1 version:
```
$ valgrind --leak-check=full ./xxx-6
==26367== Memcheck, a memory error detector
==26367== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==26367== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright
info
==26367== Command: ./xxx-6
==26367==
making the file
made the file
==26367==
==26367== HEAP SUMMARY:
==26367== in use at exit: 72,952 bytes in 1,158 blocks
==26367== total heap usage: 1,497 allocs, 339 frees, 278,644 bytes allocated
==26367==
==26367== LEAK SUMMARY:
==26367== definitely lost: 0 bytes in 0 blocks
==26367== indirectly lost: 0 bytes in 0 blocks
==26367== possibly lost: 0 bytes in 0 blocks
==26367== still reachable: 72,952 bytes in 1,158 blocks
==26367== suppressed: 0 bytes in 0 blocks
==26367== Reachable blocks (those to which a pointer was found) are not shown.
==26367== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==26367==
==26367== For counts of detected and suppressed errors, rerun with: -v
==26367== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
```
So that's fine.
Now the crashing trunk binary:
```
$ valgrind --leak-check=full ./xxx-7
==26419== Memcheck, a memory error detector
==26419== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==26419== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright
info
==26419== Command: ./xxx-7
==26419==
making the file
==26419== Use of uninitialised value of size 8
==26419== at 0x4080D9: llvm::DIBuilder::createFile(llvm::StringRef,
llvm::StringRef, llvm::Optional<llvm::DIFile::ChecksumInfo<llvm::StringRef> >,
llvm::Optional<llvm::StringRef>) (in
/home/vext01/research/llvm-api-examples/xxx/xxx-7)
==26419== by 0x40799A: main (xxx.cpp:21)
==26419==
==26419== Invalid read of size 1
==26419== at 0x4080D9: llvm::DIBuilder::createFile(llvm::StringRef,
llvm::StringRef, llvm::Optional<llvm::DIFile::ChecksumInfo<llvm::StringRef> >,
llvm::Optional<llvm::StringRef>) (in
/home/vext01/research/llvm-api-examples/xxx/xxx-7)
==26419== by 0x40799A: main (xxx.cpp:21)
==26419== Address 0x10000000f is not stack'd, malloc'd or (recently) free'd
==26419==
==26419==
==26419== Process terminating with default action of signal 11 (SIGSEGV)
==26419== Access not within mapped region at address 0x10000000F
==26419== at 0x4080D9: llvm::DIBuilder::createFile(llvm::StringRef,
llvm::StringRef, llvm::Optional<llvm::DIFile::ChecksumInfo<llvm::StringRef> >,
llvm::Optional<llvm::StringRef>) (in
/home/vext01/research/llvm-api-examples/xxx/xxx-7)
==26419== by 0x40799A: main (xxx.cpp:21)
==26419== If you believe this happened as a result of a stack
==26419== overflow in your program's main thread (unlikely but
==26419== possible), you can try to increase the size of the
==26419== main thread stack using the --main-stacksize= flag.
==26419== The main thread stack size used in this run was 8388608.
==26419==
==26419== HEAP SUMMARY:
==26419== in use at exit: 8,001 bytes in 68 blocks
==26419== total heap usage: 73 allocs, 5 frees, 82,533 bytes allocated
==26419==
==26419== LEAK SUMMARY:
==26419== definitely lost: 0 bytes in 0 blocks
==26419== indirectly lost: 0 bytes in 0 blocks
==26419== possibly lost: 0 bytes in 0 blocks
==26419== still reachable: 8,001 bytes in 68 blocks
==26419== suppressed: 0 bytes in 0 blocks
==26419== Reachable blocks (those to which a pointer was found) are not shown.
==26419== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==26419==
==26419== For counts of detected and suppressed errors, rerun with: -v
==26419== Use --track-origins=yes to see where uninitialised values come from
==26419== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Segmentation fault
```
As you can see, there are memory errors, which I assume is causing the problem.
Looks like a bug to me.</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>