<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div class="BodyFragment"><font size="2"><span style="font-size:10pt;">
<div class="PlainText">I've built a debug version of clang with address sanitizer support (-fsanitize=address), and it also suggests that it is a use-after-free bug when using (not compiling as I mistakenly claimed before) the precompiled header:<br>
<br>
> SUMMARY: AddressSanitizer: heap-use-after-free ??:0 clang::LazyOffsetPtr<clang::Decl, unsigned int, &(clang::ExternalASTSource::GetExternalDecl(unsigned int))>::operator=(clang::Decl*)<br>
> Shadow bytes around the buggy address:<br>
<snip><br>
>   0x1c3200005890: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd<br>
> =>0x1c32000058a0: fd fd fd fd fd[fd]fd fd fd fd fd fd fd fd fd fd<br>
>   0x1c32000058b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa<br>
>   0x1c32000058c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa<br>
>   0x1c32000058d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd<br>
<snip><br>
> Shadow byte legend (one shadow byte represents 8 application bytes):<br>
>   Addressable:           00<br>
>   Partially addressable: 01 02 03 04 05 06 07<br>
>   Heap left redzone:     fa<br>
>   Heap right redzone:    fb<br>
>   Freed heap region:     fd<br>
<br>
(I have attached the full output from asan.)<br>
<br>
Best,<br>
Tobias<br>
<br>
Am 17.06.2014 um 20:36 schrieb Tobias Hahn <tobias.hahn@ableton.com>:<br>
<br>
> Thanks for the quick feedback :)<br>
> <br>
> I've reproduced this on the latest master as well as several versions that ship with Xcode (and I've also reported it to Apple). The isystem include is only necessary in versions built from source, otherwise clang doesn't seem to find libc++. The versions
 shipping with Xcode don't need this, they seem to find it using a compiled in path.
<br>
> <br>
> The <list> include seems necessary; it doesn't crash for me when I remove it. I'll see if I can find a Linux-box where I can reproduce it.
<br>
> <br>
> Thanks for looking into it. <br>
> Tobias<br>
> <br>
> Am 17.06.2014 um 00:17 schrieb "Nikola Smiljanic" <popizdeh@gmail.com>:<br>
> <br>
>> It might make sense to file this with apple if you're using clang shipped with XCode as they ship their own releases. What version of clang are you using? Is the isystem flag important? What about #include <list>? I've tried to reproduce this but it's not
 so straightforward because I'm on linux and some of the stuff in that bash script assumes mac os... I was wondering if it's possible to reduce this to something that's reproducible everywhere or if this is a mac specific issue.<br>
>> <br>
>> <br>
>> On Mon, Jun 16, 2014 at 11:55 PM, Nikola Smiljanic <popizdeh@gmail.com> wrote:<br>
>> Thanks for the detailed report! The only thing you can do more is try and debug this yourself ;)<br>
>> <br>
>> <br>
>> On Mon, Jun 16, 2014 at 8:33 PM, Tobias Hahn <tobias.hahn@ableton.com> wrote:<br>
>> Hi all,<br>
>> <br>
>> I've run into (what I believe is) a memory bug with clang while producing a precompiled header. In short, under certain circumstances, clang will write a pch that causes a crash when trying to use this pch in a later compilation unit.<br>
>> <br>
>> Occasionally, while clang is compiling the pch, malloc complains that one of its checksums has been overwritten; while at other times, clang throws an error that a definition has a different exception specification than the declaration two lines above it
 (when both have no exception specification). Both these symptoms lead me to believe that somewhere clang overwrites memory.<br>
>> <br>
>> I have stripped the code that reliably causes this crash down to a few hundred lines and have created a little script to reproduce the bug (details at
<a href="http://llvm.org/bugs/show_bug.cgi?id=20026">http://llvm.org/bugs/show_bug.cgi?id=20026</a>). I'm not sure, however, about your process for handling such bugs, which is why I'm cross-posting here. My main question is if there is anything else I could
 provide you with to help fixing this issue.<br>
>> <br>
>> Thank you very much in advance!<br>
>> <br>
>> Best,<br>
>> Tobias<br>
>> <br>
>> <br>
>> Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany<br>
>> Sitz (Registered Office) Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838<br>
>> Vorstand (Management Board): Gerhard Behles, Jan Bohl<br>
>> Vorsitzender des Aufsichtsrats (Chair of the Supervisory Board): Uwe Struck<br>
>> <br>
>> <br>
>> <br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> cfe-dev@cs.uiuc.edu<br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>> <br>
>> <br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> cfe-dev@cs.uiuc.edu<br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br>
Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany<br>
Sitz (Registered Office) Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838<br>
Vorstand (Management Board): Gerhard Behles, Jan Bohl<br>
Vorsitzender des Aufsichtsrats (Chair of the Supervisory Board): Uwe Struck<br>

</div>
</span></font></div>
<div class="BodyFragment"><font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
</div>
</span></font></div>
</body>
</html>