[LLVMbugs] [Bug 22750] New: Non-determinism causes assertion failure in llvm::DwarfCompileUnit::constructImportedEntityDie

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=22750

            Bug ID: 22750
           Summary: Non-determinism causes assertion failure in
                    llvm::DwarfCompileUnit::constructImportedEntityDie
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: dario.domizioli at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13973
  --> http://llvm.org/bugs/attachment.cgi?id=13973&action=edit
Imported namespaces stress test

The attached file is a stress test for imported namespaces. It contains a lot
of statements of the type:
  // ...
  {
    namespace A = base;
    namespace B = A;
    namespace C = B;
    // ...
  }

When generating debug information, the function
llvm::DwarfCompileUnit::constructImportedEntityDie has to construct the DIEs
for each imported namespace in order, because each one depends on the previous
one. For imported entities, the function assumes it can call getDie() and
receive a valid pointer.

However, there is a non-determinism in the order in which these imported
namespaces are processed. This leads to them possibly being processed
out-of-order and this causes the assertion in DwarfCompileUnit:661 to fail.

To reproduce, just compile with -g:
    clang -g ns_stress.cpp

I'm using Clang/LLVM trunk r230945 with triple x86_64-unknown-linux.
It also reproduces with the released Clang 3.6.

I spotted it's a non-determinism issue because:
(a) with smaller tests it seemed to happen randomly, and
(b) when I did some "printf debugging" on the asserting function I verified
that the processing order is actually non-deterministic.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150302/ebace317/attachment.html>