Comment # 8 on bug 1188353 from Aaron Puchert

Very interesting, thanks.

> Syscall param waitid(infop) points to unaddressable byte(s)
> [...]
>  Address 0x0 is not stack'd, malloc'd or (recently) free'd
I'll ignore that one. The man page doesn't say anything about whether infop is
allowed to be NULL, but I guess either the implementation is robust or we'd see
a different crash. (Though it might contribute to the crash, for example
because a failure of the syscall wasn't expected.)

> Invalid read of size 8
>    at 0x48BC810: UnknownInlinedFun (FileEntry.h:62)
>    by 0x48BC810: UnknownInlinedFun (FileEntry.h:364)
>    by 0x48BC810: clang_getFileName (CIndex.cpp:4333)
>    by 0x263789: clang::operator<<(QDebug, clang::SourceLocation const&) (in /usr/bin/shiboken2)
>    by 0x263A4A: clang::operator<<(QDebug, clang::Diagnostic const&) (in /usr/bin/shiboken2)
>    by 0x1EAA45: AbstractMetaBuilderPrivate::buildDom(QList<QByteArray>, LanguageLevel, unsigned int) (in /usr/bin/shiboken2)
>    by 0x1F2437: AbstractMetaBuilder::build(QList<QByteArray> const&, LanguageLevel, unsigned int) (in /usr/bin/shiboken2)
>    by 0x1D8372: ApiExtractor::run(bool) (in /usr/bin/shiboken2)

Nice, that's pretty much exactly our crash stack. Except that we now know that
it's an invalid read, and why it's invalid:

> Address 0x11be4c20 is 144 bytes inside a block of size 152 free'd
>   at 0x484171B: operator delete(void*) (vg_replace_malloc.c:802)
>   by 0x62335F7: deallocate (new_allocator.h:145)
>   by 0x62335F7: deallocate (alloc_traits.h:492)
>   by 0x62335F7: _M_put_node (stl_tree.h:565)
>   by 0x62335F7: _M_drop_node (stl_tree.h:632)
>   [...]
>   by 0x623018C: ~_Rb_tree (stl_tree.h:984)
>   by 0x623018C: ~map (stl_map.h:302)
>   by 0x623018C: clang::FileManager::~FileManager() (FileManager.cpp:61)
>   by 0x80EE274: Release (IntrusiveRefCntPtr.h:96)
>   by 0x80EE274: release (IntrusiveRefCntPtr.h:154)
>   by 0x80EE274: release (IntrusiveRefCntPtr.h:222)
>   by 0x80EE274: ~IntrusiveRefCntPtr (IntrusiveRefCntPtr.h:189)
>   by 0x80EE274: clang::ASTUnit::~ASTUnit() (ASTUnit.cpp:273)
>   by 0x48AB7A2: clang_disposeTranslationUnit (CIndex.cpp:4164)
>   by 0x255D37: clang::parse(QList<QByteArray> const&, unsigned int, clang::BaseVisitor&) (in /usr/bin/shiboken2)
>   by 0x1EA925: AbstractMetaBuilderPrivate::buildDom(QList<QByteArray>, LanguageLevel, unsigned int) (in /usr/bin/shiboken2)
>   by 0x1F2437: AbstractMetaBuilder::build(QList<QByteArray> const&, LanguageLevel, unsigned int) (in /usr/bin/shiboken2)

So we want to get the filename for a source location, but that information
seems to have been in a map in clang::FileManager (sounds plausible), which has
already been cleaned up. The cleanup was triggered by a call to
clang_disposeTranslationUnit.

So AbstractMetaBuilderPrivate::buildDom calls clang::parse (in shiboken2
still), which disposes some translation unit, but then later wants to print a
diagnostic from the translation unit that was just disposed. That can not be
expected to work. Either the disposal happens too early, or the diagnostics are
from an earlier run and haven't been cleaned up yet.

I think the later issues are just because valgrind tries to continue somehow.