![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
http://bugzilla.opensuse.org/show_bug.cgi?id=1188353
http://bugzilla.opensuse.org/show_bug.cgi?id=1188353#c8
--- Comment #8 from Aaron Puchert
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. -- You are receiving this mail because: You are on the CC list for the bug.