I believe I'm hitting exactly this, and when I run with +RTS -DS -DZ
I fairly consistently get a seg fault in about 15s. This is a private work codebase which I can't easily share (but may be able to when I talk to people higher up). This is with the debug runtime (that is, without -threaded
). In the meantime, what can I do to help debug this? I'm running GHC 9.4.5, and the relevant tail of gdb
is:
Thread 1 "ch-fiducials-te" received signal SIGSEGV, Segmentation fault.
0x00000000024c1fac in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=2139095040) at rts/include/rts/storage/ClosureMacros.h:259
259 rts/include/rts/storage/ClosureMacros.h: No such file or directory.
(gdb) bt
#0 0x00000000024c1fac in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=2139095040)
at rts/include/rts/storage/ClosureMacros.h:259
#1 0x00000000024c1ffb in LOOKS_LIKE_INFO_PTR (p=2139095040) at rts/include/rts/storage/ClosureMacros.h:264
#2 0x00000000024c203b in LOOKS_LIKE_CLOSURE_PTR (p=0x420046a818)
at rts/include/rts/storage/ClosureMacros.h:270
#3 0x00000000024c2d52 in evacuate (p=0x42005f6eb0) at rts/sm/Evac.c:694
#4 0x000000000248e5ef in scavenge_block (bd=0x4200503d80) at rts/sm/Scav.c:532
#5 0x0000000002490910 in scavenge_find_work () at rts/sm/Scav.c:2102
#6 0x00000000024909f5 in scavenge_loop () at rts/sm/Scav.c:2178
#7 0x000000000247eccb in scavenge_until_all_done () at rts/sm/GC.c:1324
#8 0x000000000247d611 in GarbageCollect (config=..., cap=0x2d6bcc0 <MainCapability>, idle_cap=0x0)
at rts/sm/GC.c:552
#9 0x000000000246c723 in scheduleDoGC (pcap=0x7ffffffddf80, task=0x2dc5ab0, force_major=false,
is_overflow_gc=true, deadlock_detect=false, nonconcurrent=false) at rts/Schedule.c:1877
#10 0x000000000246bc59 in schedule (initialCapability=0x2d6bcc0 <MainCapability>, task=0x2dc5ab0)
at rts/Schedule.c:583
#11 0x000000000246d106 in scheduleWaitThread (tso=0x4200405388, ret=0x0, pcap=0x7ffffffde080)
at rts/Schedule.c:2647
#12 0x0000000002462cd2 in rts_evalLazyIO (cap=0x7ffffffde080, p=0x274d838, ret=0x0) at rts/RtsAPI.c:566
#13 0x00000000024664f1 in hs_main (argc=1, argv=0x7ffffffde298, main_closure=0x274d838, rts_config=...)
at rts/RtsMain.c:72
#14 0x00000000004201c6 in main ()
Edit: Sorry, ignore my previous comment - I re-read what you wrote.
That seems reasonable, but I still think the .hie
should be mentioning (&&)
.
The use of a section doesn't produce a corresponding reference in the generated .hie
file.
Take the following as Wat.hs
:
module Wat where
wat x = (x &&)
Then compile this using:
ghc --make -fwrite-ide-info -XGHC2021 Wat.hs
Finally inspect the generated Wat.hie
using hiedb dump
:
$ hiedb dump Wat.hie
Node@Wat.hs:2:1-14: Source: From source
{(annotations: {(Module, Module), (AbsBinds, HsBindLR),
(FunBind, HsBindLR), (Match, Match)}),
(types: [3]), (identifier info: {})}
Node@Wat.hs:2:1-3: Source: From source
{(annotations: {}), (types: []),
(identifier info: {(name wat, Details: Just 3 {LHS of a match group,
regular value bound with scope: ModuleScope bound at: Wat.hs:2:1-14})})}
Node@Wat.hs:2:5: Source: From source
{(annotations: {(VarPat, Pat)}), (types: [0]),
(identifier info: {(name x, Details: Just 0 {bound in a pattern with scope: LocalScope Wat.hs:2:7-14 , NoScope })})}
Node@Wat.hs:2:7-14: Source: From source
{(annotations: {(GRHS, GRHS)}), (types: []),
(identifier info: {})}
Node@Wat.hs:2:9-14: Source: From source
{(annotations: {(HsPar, HsExpr)}), (types: []),
(identifier info: {})}
Node@Wat.hs:2:10-13: Source: From source
{(annotations: {(XExpr, HsExpr), (HsApp, HsExpr)}), (types: [2]),
(identifier info: {})}
Node@Wat.hs:2:10: Source: From source
{(annotations: {(HsVar, HsExpr)}), (types: [0]),
(identifier info: {(name x, Details: Just 0 {usage})})}
Notice that there is a {usage}
for x, but no usage for &&
.
If we change `wat to be a right section:
wat x = (&& x)
Then we get
Node@Wat.hs:2:1-14: Source: From source
{(annotations: {(Module, Module), (AbsBinds, HsBindLR),
(FunBind, HsBindLR), (Match, Match)}),
(types: [3]), (identifier info: {})}
Node@Wat.hs:2:1-3: Source: From source
{(annotations: {}), (types: []),
(identifier info: {(name wat, Details: Just 3 {LHS of a match group,
regular value bound with scope: ModuleScope bound at: Wat.hs:2:1-14})})}
Node@Wat.hs:2:5: Source: From source
{(annotations: {(VarPat, Pat)}), (types: [0]),
(identifier info: {(name x, Details: Just 0 {bound in a pattern with scope: LocalScope Wat.hs:2:7-14 , NoScope })})}
Node@Wat.hs:2:7-14: Source: From source
{(annotations: {(GRHS, GRHS)}), (types: []),
(identifier info: {})}
Node@Wat.hs:2:9-14: Source: From source
{(annotations: {(HsPar, HsExpr)}), (types: []),
(identifier info: {})}
Node@Wat.hs:2:10-13: Source: From source
{(annotations: {(XExpr, HsExpr), (HsApp, HsExpr)}), (types: [2]),
(identifier info: {})}
Node@Wat.hs:2:10-11: Source: From source
{(annotations: {(HsVar, HsExpr)}), (types: [3]),
(identifier info: {(name &&, Details: Just 3 {usage})})}
Node@Wat.hs:2:13: Source: From source
{(annotations: {(HsVar, HsExpr)}), (types: [0]),
(identifier info: {(name x, Details: Just 0 {usage})})}
which clearly mentions &&
.
If we compile with -XHaskell2010
, all is well:
ghc --make -fwrite-ide-info -XGHC2021 Wat.hs
Node@Wat.hs:2:1-14: Source: From source
{(annotations: {(Module, Module), (AbsBinds, HsBindLR),
(FunBind, HsBindLR), (Match, Match)}),
(types: [3]), (identifier info: {})}
Node@Wat.hs:2:1-3: Source: From source
{(annotations: {}), (types: []),
(identifier info: {(name wat, Details: Just 3 {LHS of a match group,
regular value bound with scope: ModuleScope bound at: Wat.hs:2:1-14})})}
Node@Wat.hs:2:5: Source: From source
{(annotations: {(VarPat, Pat)}), (types: [0]),
(identifier info: {(name x, Details: Just 0 {bound in a pattern with scope: LocalScope Wat.hs:2:7-14 , NoScope })})}
Node@Wat.hs:2:7-14: Source: From source
{(annotations: {(GRHS, GRHS)}), (types: []),
(identifier info: {})}
Node@Wat.hs:2:9-14: Source: From source
{(annotations: {(HsPar, HsExpr)}), (types: []),
(identifier info: {})}
Node@Wat.hs:2:10-13: Source: From source
{(annotations: {(XExpr, HsExpr), (HsApp, HsExpr)}), (types: [2]),
(identifier info: {})}
Node@Wat.hs:2:10: Source: From source
{(annotations: {(HsVar, HsExpr)}), (types: [0]),
(identifier info: {(name x, Details: Just 0 {usage})})}
Node@Wat.hs:2:12-13: Source: From source
{(annotations: {(HsVar, HsExpr)}), (types: [3]),
(identifier info: {(name &&, Details: Just 3 {usage})})}
If we change wat
to have two arguments:
wat x y = (x && y)
``
Then we get
... Node@Wat.hs:2:12: Source: From source {(annotations: {(HsVar, HsExpr)}), (types: [0]), (identifier info: {(name x, Details: Just 0 {usage})})}
Node@Wat.hs:2:14-15: Source: From source
{(annotations: {(HsVar, HsExpr)}), (types: [3]),
(identifier info: {(name &&, Details: Just 3 {usage})})}
Node@Wat.hs:2:17: Source: From source
{(annotations: {(HsVar, HsExpr)}), (types: [0]),
(identifier info: {(name y, Details: Just 0 {usage})})}
Likewise, if we remove all arguments from `wat`:
```haskell
wat = (&&)
We get
Node@Wat.hs:2:1-10: Source: From source
{(annotations: {(Module, Module), (AbsBinds, HsBindLR),
(FunBind, HsBindLR), (Match, Match)}),
(types: [3]), (identifier info: {})}
Node@Wat.hs:2:1-3: Source: From source
{(annotations: {}), (types: []),
(identifier info: {(name wat, Details: Just 3 {LHS of a match group,
regular value bound with scope: ModuleScope bound at: Wat.hs:2:1-10})})}
Node@Wat.hs:2:5-10: Source: From source
{(annotations: {(GRHS, GRHS)}), (types: []),
(identifier info: {})}
Node@Wat.hs:2:7-10: Source: From source
{(annotations: {(HsVar, HsExpr)}), (types: [3]),
(identifier info: {(name &&, Details: Just 3 {usage})})}
The expression
wat x = (x &&)
should produce {usage}
nodes mentioning both x
and (&&)
.
Optional:
Correct, I think I've fixed that.
Ollie Charles (fa559c28) at 07 Mar 20:56
Add Data.Functor.unzip
Sorry about that, I've added a changelog entry and rebased to master.
@Bodigrim Rebased onto master
@Bodigrim I believe this is ready to go now. Please let me know if I need to do anything else.
Ollie Charles (8498a5f1) at 19 Jan 15:27
Add Data.Functor.unzip
Ollie Charles (4c98e154) at 19 Jan 14:04
Restrict Data.List.NonEmpty.unzip to operate on NonEmpty lists, rat...
Ollie Charles (74ca6191) at 19 Jan 14:02
ncg/aarch64: Don't use x18 register on AArch64/Darwin
... and 718 more commits
@Bodigrim more than happy to, but I was planning to reach an agreement on https://github.com/haskell/core-libraries-committee/issues/86 before we merged this (with the plan that both would merge in the same GHC release)
Ollie Charles (31053de4) at 07 Dec 21:44
Update Functor.hs
It does, but I don't know why - as far as I can see the latest commit doesn't have any trailing whitespace.
Edit: doh, it's the line above.
Ollie Charles (e1154b0d) at 07 Dec 09:06
Update Functor.hs
@Bodigrim without any further input from the CLC, no. Of the CLC wants what phadej asks for then I'll happily oblige.