On Monday, 31 July 2023 at 14:38:52 UTC, ryuukk_ wrote:
Your problem lies at line 1541
You can use `ddemangle` executable to make mangled names
readable, i don't know if it comes with the compiler
```
_platform_memmove
pure nothrow ref @trusted wchar[]
core.internal.array.appending._d_arrayappendT!(wchar[],
char)._d_arrayappendT(scope return ref wchar[], scope wchar[])
void
asm_parse.AsmTransformTemplate!(wchar).__unittest_L1541_C1_1()
asm_parse.__unittest
asm_parse.__unittest
asm_parse.__unittest
asm_parse.__unittest
int
core.runtime.runModuleUnitTests().__foreachbody6(object.ModuleInfo*)
int rt.minfo.moduleinfos_apply(scope int
delegate(immutable(object.ModuleInfo*))).__foreachbody2(ref
rt.sections_elf_shared.DSO)
int rt.sections_elf_shared.DSO.opApply(scope int delegate(ref
rt.sections_elf_shared.DSO))
int rt.minfo.moduleinfos_apply(scope int
delegate(immutable(object.ModuleInfo*)))
int object.ModuleInfo.opApply(scope int
delegate(object.ModuleInfo*))
runModuleUnitTests
void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int
function(char[][])*).runAll()
_d_run_main2
_d_run_main
start
```
Thank you all for your help. In the real code I have a struct
(object) in the heap but in the unittests I first of all had it
in place in the stack, then tried changing to the heap to see if
that would fix the problem. That didn’t work. I first ran the
struct initialisation routine in each one of the unittests, but I
still suspect that the thing is not completely initialised. Maybe
I forgot to set something in the init routine and it gets set to
a sensible value in subsequent code, but all that code is not
running in the unittests. An uninitialised field would be my best
guess. I can see the AAarch64 instruction that it dies on and my
AAarch64 is non-existent but I’ve done so much asm over the years
that I can hazard a guess. It is doing something like p->field
and it looks like a read instruction but I’m not sure about the
operand ordering as we probably have the stupid ATT asm to deal
with. Of course a write instruction is more likely to cause a
crash. I could try and work out how to see all the relevant
registers, could be p is a null pointer or perhaps just out of
range.
Really annoying as that code seems to work perfectly in normal
use, and disabling that unittest block restores sanity. I really
am going to have to go off and do a lot of reading.
