Admin message

Due to a large amount of spam we do not allow new users to create repositories, they are "external" users. If you are a new user and want to create a repository, for example for forking GHC, open a new issue on ghc/ghc using the "get-verified" issue template

Segfault in GHC 9.2.7/9.4.5/9.6.1 with aligned pinned byte arrays
## Summary Use of aligned pinned byte arrays appears to be giving us a segmentation fault. We don't see any issues if we use unpinned byte arrays or only use unaligned pinned byte arrays. Compiling with GHC 9.2.7: ``` Thread 1 "segfault" received signal SIGSEGV, Segmentation fault. 0x00000000017bd668 in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=198) at includes/rts/storage/ClosureMacros.h:253 253 includes/rts/storage/ClosureMacros.h: No such file or directory. (gdb) bt #0 0x00000000017bd668 in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=198) at includes/rts/storage/ClosureMacros.h:253 #1 0x00000000017bd6b7 in LOOKS_LIKE_INFO_PTR (p=198) at includes/rts/storage/ClosureMacros.h:258 #2 0x00000000017bd6f7 in LOOKS_LIKE_CLOSURE_PTR (p=0x42005d5000) at includes/rts/storage/ClosureMacros.h:264 #3 0x00000000017c00fc in scavenge_mutable_list1 (bd=0x4200401280, gen=0x1971910) at rts/sm/Scav.c:1606 #4 0x00000000017c0450 in scavenge_capability_mut_Lists1 (cap=0x195c240 <MainCapability>) at rts/sm/Scav.c:1715 #5 0x0000000001795cf9 in GarbageCollect (collect_gen=0, do_heap_census=false, is_overflow_gc=true, deadlock_detect=false, gc_type=2, cap=0x195c240 <MainCapability>, idle_cap=0x1985a20) at rts/sm/GC.c:505 #6 0x000000000176ab06 in scheduleDoGC (pcap=0x7fffffffd9e8, task=0x1983690, force_major=false, is_overflow_gc=true, deadlock_detect=false) at rts/Schedule.c:1860 #7 0x0000000001768b57 in schedule (initialCapability=0x195c240 <MainCapability>, task=0x1983690) at rts/Schedule.c:579 #8 0x000000000176b4df in scheduleWaitThread (tso=0x4200406ce8, ret=0x0, pcap=0x7fffffffdb10) at rts/Schedule.c:2630 #9 0x000000000176c924 in rts_evalLazyIO (cap=0x7fffffffdb10, p=0x1834d40, ret=0x0) at rts/RtsAPI.c:566 #10 0x0000000001783ee2 in hs_main (argc=1, argv=0x7fffffffdd38, main_closure=0x1834d40, rts_config=...) at rts/RtsMain.c:72 #11 0x0000000000406f01 in main () ``` Compiling with GHC 9.4.5: ``` segfault: internal error: ASSERTION FAILED: file rts/sm/Storage.c, line 1605 (GHC version 9.4.5 for x86_64_unknown_linux) Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug Thread 1 "segfault" received signal SIGABRT, Aborted. __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737349969728) at ./nptl/pthread_kill.c:44 44 ./nptl/pthread_kill.c: No such file or directory. (gdb) bt #0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737349969728) at ./nptl/pthread_kill.c:44 #1 __pthread_kill_internal (signo=6, threadid=140737349969728) at ./nptl/pthread_kill.c:78 #2 __GI___pthread_kill (threadid=140737349969728, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 #3 0x00007ffff7c4b476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #4 0x00007ffff7c317f3 in __GI_abort () at ./stdlib/abort.c:79 #5 0x0000000002047ea6 in rtsFatalInternalErrorFn (s=0x2125e40 "ASSERTION FAILED: file %s, line %u\n", ap=0x7fffffffd4c8) at rts/RtsMessages.c:192 #6 0x0000000002047aae in barf (s=0x2125e40 "ASSERTION FAILED: file %s, line %u\n") at rts/RtsMessages.c:48 #7 0x0000000002047b11 in _assertFail (filename=0x212f55d "rts/sm/Storage.c", linenum=1605) at rts/RtsMessages.c:63 #8 0x000000000207feb2 in countOccupied (bd=0x4200402c00) at rts/sm/Storage.c:1605 #9 0x000000000206586f in GarbageCollect (config=..., cap=0x2447000 <MainCapability>, idle_cap=0x246dae0) at rts/sm/GC.c:778 #10 0x000000000204f97f in scheduleDoGC (pcap=0x7fffffffd9f0, task=0x246b750, force_major=false, is_overflow_gc=true, deadlock_detect=false, nonconcurrent=false) at rts/Schedule.c:1875 #11 0x000000000204dc13 in schedule (initialCapability=0x2447000 <MainCapability>, task=0x246b750) at rts/Schedule.c:583 #12 0x0000000002050b0e in scheduleWaitThread (tso=0x4200406ce8, ret=0x0, pcap=0x7fffffffdb10) at rts/Schedule.c:2647 #13 0x00000000020435b8 in rts_evalLazyIO (cap=0x7fffffffdb10, p=0x2154ec8, ret=0x0) at rts/RtsAPI.c:566 #14 0x000000000204796e in hs_main (argc=1, argv=0x7fffffffdd38, main_closure=0x2154ec8, rts_config=...) at rts/RtsMain.c:72 #15 0x0000000000406eab in main () ``` Compiling with GHC 9.6.1: ``` [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff7290640 (LWP 1316306)] Thread 1 "segfault" received signal SIGSEGV, Segmentation fault. LOOKS_LIKE_CLOSURE_PTR (p=0xc0) at rts/include/rts/storage/ClosureMacros.h:289 289 rts/include/rts/storage/ClosureMacros.h: No such file or directory. (gdb) bt #0 LOOKS_LIKE_CLOSURE_PTR (p=0xc0) at rts/include/rts/storage/ClosureMacros.h:289 #1 0x00000000016e986e in scavenge_mutable_list (bd=0x4200402440, gen=0x19f48e8) at rts/sm/Scav.c:1636 #2 0x00000000016e9b9c in scavenge_capability_mut_lists (cap=0x19f2500 <MainCapability>) at rts/sm/Scav.c:1745 #3 0x00000000016d66bd in GarbageCollect (collect_gen=0, do_heap_census=false, is_overflow_gc=true, deadlock_detect=false, gc_type=0, cap=0x19f2500 <MainCapability>, idle_cap=0x0) at rts/sm/GC.c:512 #4 0x00000000016c4e09 in scheduleDoGC (pcap=0x7fffffffda08, task=0x1a023c0, force_major=false, is_overflow_gc=true, deadlock_detect=false) at rts/Schedule.c:1883 #5 0x00000000016c42ae in schedule (initialCapability=0x19f2500 <MainCapability>, task=0x1a023c0) at rts/Schedule.c:575 #6 0x00000000016c5831 in scheduleWaitThread (tso=0x4200405380, ret=0x0, pcap=0x7fffffffdb10) at rts/Schedule.c:2651 #7 0x000000000171248c in rts_evalLazyIO (cap=0x7fffffffdb10, p=0x18abec8, ret=0x0) at rts/RtsAPI.c:562 #8 0x00000000016be90d in hs_main (argc=1, argv=0x7fffffffdd38, main_closure=0x18abec8, rts_config=...) at rts/RtsMain.c:72 #9 0x00000000004078e3 in main () ``` ## Steps to reproduce Don't have a shareable example yet. Can someone suggest some ways to try and get a minimal reproducable example? The code at the momemnt is large and complex with multiple reads/writes/copies/moves but there doesn't seem to be a consistent point of failure. ## Expected behavior n/a ## Environment * GHC version used: GHC-9.2.7 / GHC 9.4.5 / GHC 9.6.1 Optional: * Operating System: Ubuntu * System Architecture: x86-64
issue