Open mf59816 opened 10 years ago
As @mantkiew noted in https://github.com/def-/ghc-vis/issues/4 , there are easier ways to trigger this. This works fine:
> data Pair1 = Pair1 Int Int
> let p1 = Pair1 (1+2) (3+4)
> :printHeap p1
But this causes the Unknown opcode
exception:
> data Pair2 = Pair2 !Int !Int
> let p2 = Pair2 (1+2) (3+4)
> :printHeap p2
It seems like the parsing of the initial closure is already wrong, as the arity makes no sense:
> getClosureData p2
APClosure {info = StgInfoTable {ptrs = 0, nptrs = 0, tipe = AP, srtlen = 0}, arity = 674261441, n_args = 0, fun = 0x00007fdf28fe21d0, payload = []}
I haven't figured out anything else so far.
Hey guys, maybe my error might shed some light on the situation?
I got an even simpler one:
> data Foo = Bar Int
> let a = Bar 2
> :printHeap a
I'm using stack ghci
, ghc 7.10.3.
Any news on the issue?
Confirmed, using 7.10.3 in Debian (although I get a segmentation fault). No further investigation yet.
After getting a fault similar to this which was reported to be fixed in later GHC versions, I upgraded ubuntu, extended the various version dependencies in xdot, ghc-vis and possibly others, deleted .cabal and .ghc/platform folders several times, reinstalled packages, just managed to stop various package installations that would break things, and I managed to eliminate the previous similar fault and replaced it with this fault. I'm not sure if this is the correct way to understand Haskell memory leaks ... I may have been misadvised. Is this the correct tool and is it correct to continue this endeavour or should I be using something else?
PR 23 deleted the code of ghc-heap-view to read the heap. instead ghc-heap-view now uses the standard GHC library GHC.Exts.Heap. Since this change, I could NOT reproduce any of the Unknown opcode 0
exceptions. So I think, PR 23 also fixed this issue.
However, the issue is only fixed in GHC with version >= 8.6. Nothing was done for older versions.
I'll just wait until stack, ubuntu and cabal have a full set of mutually inter compatible packages then
On Wed, 4 Dec 2019, 17:06 Hans Roland Senn, notifications@github.com wrote:
PR 23 https://github.com/nomeata/ghc-heap-view/pull/23 deleted the code of ghc-heap-view to read the heap. instead ghc-heap-view now uses the standard GHC library GHC.Exts.Heap https://github.com/ghc/ghc/tree/master/libraries/ghc-heap/GHC/Exts. Since this change, I could NOT reproduce any of the Unknown opcode 0exceptions. So I think, PR 23 also fixed this issue.
However, the issue is only fixed in GHC with version >= 8.6. Nothing was done for older versions.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nomeata/ghc-heap-view/issues/3?email_source=notifications&email_token=AHZ4ZZPOTIJITR2YC4Z33ZDQW7PSTA5CNFSM4AVS4FCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF5XNXI#issuecomment-561739485, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHZ4ZZKDURZGKQWDCJL6733QW7PSTANCNFSM4AVS4FCA .
Sorry, I got another one. This time the behavior seems deterministic. I wonder if you can see it, too?
Same setup as in #2. In fact, the second error looks suspiciously similar, too.
Somehow I feel I should be looking for QuickCheck instances of the TemplateHaskell source types now. (-: