Bug 18481 – demangling error in stacktrace

Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
x86
OS
Mac OS X
Creation time
2018-02-20T23:41:23Z
Last change time
2020-05-15T03:14:22Z
Assigned to
No Owner
Creator
Timothee Cour

Comments

Comment #0 by timothee.cour2 — 2018-02-20T23:41:23Z
dmd --version DMD64 D Compiler v2.079.0-beta.1-54-g670d0ad29-dirty see reproducing test case in https://issues.dlang.org/show_bug.cgi?id=18480: all symbols are demangled except for D3dmd6access19mostVisibleOverloadFCQBi7dsymbol7DsymbolZQv at frame #!
Comment #1 by razvan.nitu1305 — 2018-03-27T08:05:20Z
Is this still available or has it been fixed once 18480 was fixed?
Comment #2 by greensunny12 — 2018-03-29T02:35:35Z
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 ```
Comment #3 by greensunny12 — 2018-03-29T02:39:11Z
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] ```
Comment #4 by pro.mathias.lang — 2020-05-15T03:14:22Z
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).