http://bugzilla.opensuse.org/show_bug.cgi?id=1188353 http://bugzilla.opensuse.org/show_bug.cgi?id=1188353#c1 --- Comment #1 from Christophe Giboudeaux --- Created attachment 851238 --> http://bugzilla.opensuse.org/attachment.cgi?id=851238&action=edit cmake --build . -t PyFalkon I can reproduce the build failure locally. Nothing indicates I get a crash however. TW / pyside 5.15.2 / llvm12 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1188353 http://bugzilla.opensuse.org/show_bug.cgi?id=1188353#c3 --- Comment #3 from Aaron Puchert --- Seems to be a memory error. Could you try running with valgrind? Perhaps it's actually happening much earlier and we just see it materialize here. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1188353 http://bugzilla.opensuse.org/show_bug.cgi?id=1188353#c5 --- Comment #5 from Albert Hensel --- (In reply to Aaron Puchert from comment #3)

Could you try running with valgrind?

After compilation of Falkon has failed: $ cd src/plugins/PyFalkon $ LC_ALL=C eval valgrind `grep -o '/usr/bin/shiboken2 .*' CMakeFiles/PyFalkon_autogen.dir/build.make` The relevant part of the output: Process terminating with default action of signal 11 (SIGSEGV): dumping core General Protection Fault at 0x123878FD: ??? (in /memfd:sljit (deleted)) by 0x12872367: ??? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1188353 http://bugzilla.opensuse.org/show_bug.cgi?id=1188353#c7 --- Comment #7 from Albert Hensel --- Created attachment 851615 --> http://bugzilla.opensuse.org/attachment.cgi?id=851615&action=edit valgrind --smc-check=all (In reply to Aaron Puchert from comment #6)

it seems you need to run valgrind with --smc-check=all when using sljit

Running valgrind with --smc-check=all gives a lot of output. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1188353 http://bugzilla.opensuse.org/show_bug.cgi?id=1188353#c8 --- Comment #8 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. -- You are receiving this mail because: You are on the CC list for the bug.