This query: https://crash-stats.mozilla.com/search/?signature=~%40%40&product=Firefox&date=%3E%3D2018-05-16T13%3A55%3A50.000Z&date=%3C2018-11-16T12%3A55%3A50.000Z&_sort=-date&_facets=signature&_columns=signature#facet-signature shows a lot of signatures containing a '@@'. Few examples (the demangled names are got from https://demangler.com/): ?huge_dalloc@@YAXPEAXPEAUarena_t@@@Z.llvm.8645364724699276900 => void __cdecl huge_dalloc(void * __ptr64,struct arena_t * __ptr64) ?arena_dalloc@@YAXPEAX_KPEAUarena_t@@@Z.llvm.9345198527561597992 => void __cdecl arena_dalloc(void * __ptr64,unsigned __int64,struct arena_t * __ptr64)

This sometimes happens because of impedence mismatch between clang-cl producing symbol names and the Microsoft's DIA SDK which we use in dump_syms for demangling. It's possible that updating the version of MSVC that our build machines have installed would fix this.

(In reply to Ted Mielczarek [:ted] [:ted.mielczarek] from comment #1) > This sometimes happens because of impedence mismatch between clang-cl > producing symbol names and the Microsoft's DIA SDK which we use in dump_syms > for demangling. It's possible that updating the version of MSVC that our > build machines have installed would fix this. Would it help if we switched to llvm-undname? Also I'm pretty sure this topic of `.llvm.` in mangled symbols has come up before, but I can't remember who I was discussing it with (mw?) or in what context.

Oh right, the context was bug 1489094. At the time I had asked in LLVM's IRC and was told that it should be safe to cut the string off at the `.` before demangling, as most demanglers will do this anyway.

Actually I suppose this is basically the same issue.