Thread overview
[Issue 18481] demangling error in stacktrace
Mar 27, 2018
RazvanN
Mar 29, 2018
Seb
Mar 29, 2018
Seb
May 15, 2020
Mathias LANG
March 27, 2018
https://issues.dlang.org/show_bug.cgi?id=18481

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |razvan.nitu1305@gmail.com

--- Comment #1 from RazvanN <razvan.nitu1305@gmail.com> ---
Is this still available or has it been fixed once 18480 was fixed?

--
March 29, 2018
https://issues.dlang.org/show_bug.cgi?id=18481

Seb <greensunny12@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |greensunny12@gmail.com

--- Comment #2 from Seb <greensunny12@gmail.com> ---
Well it seems to be an issue with the mangling in gdb (maybe the new backreferencing mangling isn't supported yet?). I would guess that it's a similar issue on OSX with LLDB?

How to reproduce:

1) pick a random ICE
2) compile dmd with ENABLE_DEBUG=1
3) get the stacktrace


```
gdbbt ../generated/linux/release/64/dmd -dip1000 foo.d
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
DMD v2.079.0-285-g5bdf4078c DEBUG

Program received signal SIGSEGV, Segmentation fault.
0x0000555555806135 in
_D3dmd6escape13escapeByValueFCQBc10expression10ExpressionPSQCfQCe15EscapeByResultsZv
(er=0x7fffffffb730, e=0x0) at dmd/escape.d:1293
1293        e.accept(v);
#0  0x0000555555806135 in
_D3dmd6escape13escapeByValueFCQBc10expression10ExpressionPSQCfQCe15EscapeByResultsZv
(er=0x7fffffffb730, e=0x0) at dmd/escape.d:1293
#1  0x00005555558052b9 in
_D3dmd6escape14checkNewEscapeFPSQBe6dscope5ScopeCQBv10expression10ExpressionbZb
(gag=false, e=0x0, sc=0x7ffff6971120) at dmd/escape.d:592
#2  0x000055555581f676 in ExpressionSemanticVisitor::visit(NewExp*)
(this=0x7fffffffbc78, exp=0x7ffff7e9f2f0) at dmd/expressionsem.d:2363
#3  0x0000555555810d66 in NewExp::accept(Visitor*) (this=0x7ffff7e9f2f0,
v=0x7fffffffbc78) at dmd/expression.d:4155
#4  0x000055555583461f in expressionSemantic(Expression*, Scope*)
(e=0x7ffff7e9f2f0, sc=0x7ffff6971120) at dmd/expressionsem.d:9367
#5  0x00005555558c5042 in StatementSemanticVisitor::visit(ExpStatement*)
(this=0x7fffffffbd48, s=0x7ffff7e9f360) at dmd/statementsem.d:177
#6  0x00005555558a771a in ExpStatement::accept(Visitor*) (this=0x7ffff7e9f360,
v=0x7fffffffbd48) at dmd/statement.d:715
#7  0x00005555558c4f2b in statementSemantic(Statement*, Scope*)
(s=0x7ffff7e9f360, sc=0x7ffff6971120) at dmd/statementsem.d:126
#8  0x00005555558c52f0 in StatementSemanticVisitor::visit(CompoundStatement*)
(this=0x7fffffffc048, cs=0x7ffff7e9f380) at dmd/statementsem.d:235
#9  0x00005555558a7ece in CompoundStatement::accept(Visitor*)
(this=0x7ffff7e9f380, v=0x7fffffffc048) at dmd/statement.d:908
#10 0x00005555558c4f2b in statementSemantic(Statement*, Scope*)
(s=0x7ffff7e9f380, sc=0x7ffff6971120) at dmd/statementsem.d:126
#11 0x00005555558d9d38 in Semantic3Visitor::visit(FuncDeclaration*)
(this=0x7fffffffc990, funcdecl=0x7ffff7e9efa0) at dmd/semantic3.d:581
#12 0x000055555583b80a in FuncDeclaration::accept(Visitor*)
(this=0x7ffff7e9efa0, v=0x7fffffffc990) at dmd/func.d:2277
#13 0x00005555558d862d in semantic3(Dsymbol*, Scope*) (dsym=0x7ffff7e9efa0,
sc=0x7ffff6970e30) at dmd/semantic3.d:82
#14 0x00005555558d8a24 in Semantic3Visitor::visit(Module*)
(this=0x7fffffffca40, mod=0x7ffff7e9eb60) at dmd/semantic3.d:195
#15 0x00005555557cfbf2 in Module::accept(Visitor*) (this=0x7ffff7e9eb60,
v=0x7fffffffca40) at dmd/dmodule.d:1322
#16 0x00005555558d862d in semantic3(Dsymbol*, Scope*) (dsym=0x7ffff7e9eb60,
sc=0x0) at dmd/semantic3.d:82
#17 0x000055555587268b in dmd.mars.tryMain(ulong, const(char)**)
(argv=0x7fffffffd628, argc=3) at dmd/mars.d:836
#18 0x000055555587380f in D main () at dmd/mars.d:1098
```

However, with ddemangle everything is properly demangle:

```
gdbbt ../generated/linux/release/64/dmd -dip1000 foo.d | ddemangle
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
DMD v2.079.0-285-g5bdf4078c DEBUG

Program received signal SIGSEGV, Segmentation fault.
0x0000555555806135 in void dmd.escape.escapeByValue(dmd.expression.Expression,
dmd.escape.EscapeByResults*) (er=0x7fffffffb730, e=0x0) at dmd/escape.d:1293
1293        e.accept(v);
#0  0x0000555555806135 in void
dmd.escape.escapeByValue(dmd.expression.Expression,
dmd.escape.EscapeByResults*) (er=0x7fffffffb730, e=0x0) at dmd/escape.d:1293
#1  0x00005555558052b9 in bool dmd.escape.checkNewEscape(dmd.dscope.Scope*,
dmd.expression.Expression, bool) (gag=false, e=0x0, sc=0x7ffff6971120) at
dmd/escape.d:592
#2  0x000055555581f676 in ExpressionSemanticVisitor::visit(NewExp*)
(this=0x7fffffffbc78, exp=0x7ffff7e9f2f0) at dmd/expressionsem.d:2363
```

--
March 29, 2018
https://issues.dlang.org/show_bug.cgi?id=18481

--- Comment #3 from Seb <greensunny12@gmail.com> ---
Oh and exploring a bit when I look at the ICE in https://issues.dlang.org/show_bug.cgi?id=18136, I get the following stack trace with only partial demangling:

```
core.exception.AssertError@dmd/statement.d(425): Assertion failure
----------------
??:? _d_assertp [0xdc37fbf5]
??:? dmd.statement.ErrorStatement dmd.statement.ErrorStatement.__ctor()
[0xdc25ec05]
??:? _ZN16Semantic3Visitor5visitEP15FuncDeclaration [0xdc291e83]
??:? _ZN16ParseTimeVisitorI10ASTCodegenE5visitEP22FuncLiteralDeclaration
[0xdc275ef1]
??:? _ZN22FuncLiteralDeclaration6acceptEP7Visitor [0xdc1f5739]
??:? _Z9semantic3P7DsymbolP5Scope [0xdc29062c]
??:? _ZN25ExpressionSemanticVisitor5visitEP7FuncExp [0xdc1d80be]
??:? _ZN7FuncExp6acceptEP7Visitor [0xdc1ca119]
??:? _Z18expressionSemanticP10ExpressionP5Scope [0xdc1ec61e]
??:? _ZN14ResolveVisitor5visitEP10TypeTypeof [0xdc26a43a]
...
??:? int dmd.dtemplate.functionResolve(dmd.declaration.Match*,
dmd.dsymbol.Dsymbol, dmd.globals.Loc, dmd.dscope.Scope*,
dmd.root.array.Array!(dmd.root.rootobject.RootObject).Array*, dmd.mtype.Type,
dmd.root.array.Array!(dmd.expression.Expression).Array*,
const(char)**).applyTemplate(dmd.dtemplate.TemplateDeclaration) [0xdc1af047]
??:?
_Z15resolveFuncCallRK3LocP5ScopeP7DsymbolP5ArrayIP10RootObjectEP4TypePS6_IP10ExpressionEi
[0xdc1f3ffe]
??:? _ZN25ExpressionSemanticVisitor5visitEP7CallExp [0xdc1dad73]
```

--
May 15, 2020
https://issues.dlang.org/show_bug.cgi?id=18481

Mathias LANG <pro.mathias.lang@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |pro.mathias.lang@gmail.com
         Resolution|---                         |FIXED

--- Comment #4 from Mathias LANG <pro.mathias.lang@gmail.com> ---
Regarding the original report, it is indeed a lack of backreference support.
This will be fixed once
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543278.html is accepted.
In the meantime, nothing we can do.
Regarding Seb's backtrace, the non-demangled symbols are C++ symbols. That's
another issue entirely (there's an open PR for it) so closing this as FIXED
(since there's an upstream patch).

--