Last few days I am trying to fix a bug in ddn.adam. I assumed (as usual) it is some bug in my code, tried different changes and none of them helped, so I firmly believe I am hitting some bug in DMD.
I found this bug while trying to fix some issues on Windows that someone reported to me, and realised that I am hitting it on my Fedora 43 workstation too.
Compiler: DMD64 D Compiler v2.112.1-rc.1
ddn.adam module source:
https://codeberg.org/ddn/ddn/src/branch/main/src/ddn/adam.d
It depends on nothing but standard library so you can simply just copy it somewhere and reproduce the bug:
» wget https://codeberg.org/ddn/ddn/raw/branch/main/src/ddn/adam.d
Saving 'adam.d'
HTTP response 200 [https://codeberg.org/ddn/ddn/raw/branch/main/src/ddn/adam.d]
adam.d 100% [=======================================================>] 52.70K --.-KB/s
[Files: 1 Bytes: 52.70K [151.89KB/s] Redirects: 0 Todo:]
» dmd -unittest -main adam.d
» ./adam
1 modules passed unittests
Segmentation fault (core dumped) ./adam
With LDC2 it works:
» ldc2 -unittest -main adam.d
» ./adam
1 modules passed unittests
GDB backtrace:
#0 0x0000000000443d35 in rt_finalize2 ()
#1 0x000000000046b5e3 in rt_finalizeFromGC ()
#2 0x0000000000461d71 in core.internal.gc.impl.conservative.gc.Gcx.sweep() ()
#3 0x0000000000462e9e in core.internal.gc.impl.conservative.gc.Gcx.fullcollect(bool, bool) ()
#4 0x0000000000467abf in core.internal.gc.impl.conservative.gc.ConservativeGC.runLocked!(core.internal.gc.impl.conservative.gc.ConservativeGC.fullCollect().go(core.internal.gc.impl.conservative.gc.Gcx*), core.internal.gc.impl.conservative.gc.Gcx*).runLocked(ref core.internal.gc.impl.conservative.gc.Gcx*) ()
#5 0x000000000045f388 in core.internal.gc.impl.conservative.gc.ConservativeGC.fullCollect() ()
#6 0x000000000045f366 in core.internal.gc.impl.conservative.gc.ConservativeGC.collect() ()
#7 0x0000000000457824 in gc_term ()
#8 0x000000000044c44b in rt_term ()
#9 0x0000000000442e0d in rt.dmain2._d_run_main2(char[][], ulong, extern(C) int(char[][]) function).runAll() ()
#10 0x0000000000442cf6 in rt.dmain2._d_run_main2(char[][], ulong, extern(C) int(char[][]) function).tryExec(scope void() delegate) ()
#11 0x0000000000442c6c in _d_run_main2 ()
#12 0x0000000000442a74 in _d_run_main ()
--Type <RET> for more, q to quit, c to continue without paging--
#13 0x0000000000435978 in main ()
#14 0x00007ffff7c7d5b5 in __libc_start_call_main (main=main@entry=0x435968 <main>, argc=argc@entry=1,
argv=argv@entry=0x7fffffffd9c8) at ../sysdeps/nptl/libc_start_call_main.h:58
#15 0x00007ffff7c7d668 in __libc_start_main_impl (main=0x435968 <main>, argc=1, argv=0x7fffffffd9c8, init=<optimized out>,
fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd9b8) at ../csu/libc-start.c:360
#16 0x00000000004009e5 in _start ()
Last few days I am trying to fix a bug in ddn.adam. I assumed (as usual) it is some bug in my code, tried different changes and none of them helped, so I firmly believe I am hitting some bug in DMD.
I found this bug while trying to fix some issues on Windows that someone reported to me, and realised that I am hitting it on my Fedora 43 workstation too.
Compiler: DMD64 D Compiler v2.112.1-rc.1
ddn.adam module source:
https://codeberg.org/ddn/ddn/src/branch/main/src/ddn/adam.d
It depends on nothing but standard library so you can simply just copy it somewhere and reproduce the bug:
With LDC2 it works:
GDB backtrace: