http://bugzilla.suse.com/show_bug.cgi?id=1092425 Weihua Du <whdu@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bnc-team-screening@forge.pr |msrb@suse.com |ovo.novell.com | -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1092425 http://bugzilla.suse.com/show_bug.cgi?id=1092425#c2 --- Comment #2 from Fabian Vogt <fvogt@suse.com> --- (In reply to Michal Srb from comment #1)

It could be the same bug as was fixed by this commit: https://reviews.llvm.org/D42588

I will test that...

Got any (positive) results? Qt 5.11 got submitted to TW now, so libqt5-qtdoc depends on this getting fixed. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1092425 http://bugzilla.suse.com/show_bug.cgi?id=1092425#c4 --- Comment #4 from Michal Srb <msrb@suse.com> --- Created attachment 771790 --> http://bugzilla.suse.com/attachment.cgi?id=771790&action=edit Patch for Qt that prevents the issue. I have found that the issue is caused by `qfloat::operator float()` in qtbase/src/corelib/global/qfloat16.h. For some reason the declaration is omitted when building the documentation using `#ifndef Q_QDOC`, but its definition is there unconditionally. Omitting the definition prevents the qdoc failure. See the attached patch. I don't know yet why it behaves differently on x86 and x86_64, perhaps it has something to do with the body of the method, which is different depending on the architecture. Also, even with broken code, it should not crash with assertion failure. So there must be something broken in either libclang or qdoc, but I did not yet find what. Perhaps we could use this patch for the time being. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1092425 http://bugzilla.suse.com/show_bug.cgi?id=1092425#c7 Fabian Vogt <fvogt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msrb@suse.com Flags| |needinfo?(msrb@suse.com) --- Comment #7 from Fabian Vogt <fvogt@suse.com> --- (In reply to Michal Srb from comment #4)

Created attachment 771790 [details] Patch for Qt that prevents the issue.

I have found that the issue is caused by `qfloat::operator float()` in qtbase/src/corelib/global/qfloat16.h.

For some reason the declaration is omitted when building the documentation using `#ifndef Q_QDOC`, but its definition is there unconditionally. Omitting the definition prevents the qdoc failure. See the attached patch.

I don't know yet why it behaves differently on x86 and x86_64, perhaps it has something to do with the body of the method, which is different depending on the architecture.

Also, even with broken code, it should not crash with assertion failure. So there must be something broken in either libclang or qdoc, but I did not yet find what. Perhaps we could use this patch for the time being.

This seems to happen in a different place for Qt 5.12 alpha again, can you have a look? Maybe it helps debugging what causes the issue: https://build.opensuse.org/package/live_build_log/KDE:Qt:5.12/libqt5-qtdoc/o... [ 578s] cd icns/ && ( test -e Makefile || /home/abuild/rpmbuild/BUILD/qt-everywhere-src-5.12.0-alpha/qtbase/bin/qmake -o Makefile /home/abuild/rpmbuild/BUILD/qt-everywhere-src-5.12.0-alpha/qtimageformats/src/plugins/imageformats/icns/icns.pro ) && /usr/bin/make -f Makefile prepare_docs [ 579s] qdoc: ../tools/clang/lib/Serialization/ASTWriter.cpp:4046: void clang::ASTWriter::GenerateNameLookupTable(const clang::DeclContext *, llvm::SmallVectorImpl<char> &): Assertion `ConversionNameSet.empty() && "Failed to find all of the visible " "conversion functions by walking all " "the lexical members of the context."' failed. [ 579s] libclang: crash detected during AST saving: { [ 579s] 'filename' : '/tmp/qdoc_pch.EjWLDp/ActiveQtDoc.pch' [ 579s] 'options' : 0, [ 579s] } [ 579s] qdoc: ../include/llvm/Bitcode/BitstreamWriter.h:90: llvm::BitstreamWriter::~BitstreamWriter(): Assertion `BlockScope.empty() && CurAbbrevs.empty() && "Block imbalance"' failed. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1092425 Stefan Dirsch <sndirsch@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|msrb@suse.com | -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1092425 https://bugzilla.suse.com/show_bug.cgi?id=1092425#c14 Fabian Vogt <fvogt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(aaronpuchert@alic | |e-dsl.net) --- Comment #14 from Fabian Vogt <fvogt@suse.com> --- (In reply to Aaron Puchert from comment #13)

(In reply to Michal Srb from comment #4)

...

I don't know yet why it behaves differently on x86 and x86_64, perhaps it has something to do with the body of the method, which is different depending on the architecture. That I can answer: before https://build.opensuse.org/request/show/822399 we were accidentally building LLVM without -DNDEBUG on 32-bit architectures.

But I can't say if that's a bug in Clang, it might also be how qtdoc is using it. If you can reproduce the failure with something like "clang -emit-pch" (that runs the same AST serialization), perhaps also -DQ_QDOC it should be worth looking at.

Can the issue still be reproduced with clang/llvm in the repos? If they're built with NDEBUG meanwhile it might not assert anymore. I gave it a quick try with the latest libqt5-qtdoc and the workaround reverted, and there was no assertion failure.

Otherwise I suggest we close this bug, chances are that the code has changed so much that the issues today are totally different.

-- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1092425 https://bugzilla.suse.com/show_bug.cgi?id=1092425#c16 Fabian Vogt <fvogt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(aaronpuchert@alic | |e-dsl.net) --- Comment #16 from Fabian Vogt <fvogt@suse.com> --- (In reply to Aaron Puchert from comment #15)

(In reply to Fabian Vogt from comment #14)

...

Can the issue still be reproduced with clang/llvm in the repos? If they're built with NDEBUG meanwhile it might not assert anymore. We're building consistently with -DNDEBUG now. So to reproduce the assertion failure, you'd have to change the spec file or build LLVM locally.

Is -DLLVM_ENABLE_ASSERTIONS=ON enough to reproduce the assert fail? If so, then I am unable to reproduce this bug, at least in a x86_64 build with the Q_QDOC workaround undone. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1092425 https://bugzilla.suse.com/show_bug.cgi?id=1092425#c18 Fabian Vogt <fvogt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #18 from Fabian Vogt <fvogt@suse.com> --- (In reply to Aaron Puchert from comment #17)

(In reply to Fabian Vogt from comment #16)

...

Is -DLLVM_ENABLE_ASSERTIONS=ON enough to reproduce the assert fail? If so, then I am unable to reproduce this bug, at least in a x86_64 build with the Q_QDOC workaround undone. Yes, LLVM_ENABLE_ASSERTIONS controls assertions. Then it seems to be fixed.

Ok, so this can finally be closed. -- You are receiving this mail because: You are on the CC list for the bug.