In a backtrace, the following symbols were outputted as mangled symbols, rather than demangled:
_D8serenity9persister6Sqlite7__arrayZ
_D8serenity9persister6Sqlite70__T15SqlitePersisterTS8serenity9persister6Sqlite11__unittest6FZv4TestZ15SqlitePersister12__T7opIndexZ7opIndexMFmZS8serenity9persister6Sqlite11__unittest6FZv4Test
Comment #1 by kennytm — 2011-05-22T14:55:05Z
The 1st symbol cannot be demangled because 'Z' is not a valid type. It could be demangled if that 'Z' is valid, e.g. replacing it with 'i':
_D8serenity9persister6Sqlite7__arrayi
-> int serenity.persister.Sqlite.__array
The same goes for vtbl (e.g. _D10TypeInfo_C6__vtblZ), module info (e.g. _D2rt3aaA12__ModuleInfoZ), etc.
The 2nd symbol cannot be demangled probably because pull #15 is not completely merged (because my local copy of druntime is able to demangle that) due to 64-bit issue.
void serenity.persister.Sqlite.__unittest6().Test serenity.persister.Sqlite.SqlitePersister!(void serenity.persister.Sqlite.__unittest6().Test).SqlitePersister.opIndex!().opIndex(ulong)
Comment #2 by sean — 2011-09-06T12:13:06Z
Is that second symbol really valid? Here's a brief run-down of one pertinent portion of the parse, given:
70__T15SqlitePersisterTS8serenity9persister6Sqlite11__unittest6FZ
The format for a TemplateInstanceName is:
Number __T LName TemplateArgs Z
So we pick off '70' as Number, match the '__T', pick out the LName of "SqlitePersister", then match a template arg (which begin with a 'T', 'V', or 'S') to get "serenity.persister.Sqlite.__unittest6". At this point we expect a 'T', 'V', or 'S' if there's another template arg to parse... there isn't one, so we jump back to parsing the TemplateInstance name and expect a 'Z' to terminate the name. We find an 'F' instead, so this isn't a template name and so we assume that this is a weird qualified name instead.
Is there some use of the 'F' that the ABI doesn't mention? Otherwise I think core.demangle is currently correct in its treatment of the second symbol.
Comment #3 by hoganmeier — 2012-01-03T10:51:46Z
Guess it's a good idea to use this issue as a gathering point for demangling problems.
Here's another one:
_D3std11parallelism8TaskPool28__T6reduceVAyaa5_61202b2062Z130__T6reduceTS4test4mainFZv39__T3mapS28_D4test4mainFZv7getTermMFiZeZ49__T3mapTS3std5range15__T4iotaTyiTyiZ4iota6ResultZ3mapM6ResultZ6reduceMFS4test4mainFZv39__T3mapS28_D4test4mainFZv7getTermMFiZeZ49__T3mapTS3std5range15__T4iotaTyiTyiZ4iota6ResultZ3mapMFS3std5range15__T4iotaTyiTyiZ4iotaFyiyiZS3std5range15__T4iotaTyiTyiZ4iota6Result6ResultZS4test4mainFZv39__T3mapS28_D4test4mainFZv7getTermMFiZeZ49__T3mapTS3std5range15__T4iotaTyiTyiZ4iota6ResultZ3mapM6Result6ResultZe
from the std.parallel example:
import std.algorithm, std.parallelism, std.range;
void main() {
immutable n = 1_000_000_000;
immutable delta = 1.0 / n;
real getTerm(int i) {
immutable x = ( i - 0.5 ) * delta;
return delta / ( 1.0 + x * x ) ;
}
immutable pi = 4.0 * taskPool.reduce!"a + b"(
std.algorithm.map!getTerm(iota(n))
);
}
Comment #4 by github-bugzilla — 2013-09-21T06:15:13Z
Comment #6 by andrej.mitrovich — 2013-09-28T03:04:56Z
I guess this is fixed now?
Comment #7 by ibuclaw — 2015-05-11T19:17:17Z
(In reply to Andrej Mitrovic from comment #6)
> I guess this is fixed now?
It's hard to say. I've found problems with the format of the mangled string. It's looking to be non-conformant.
See https://github.com/D-Programming-Language/druntime/pull/1264