*** Exception: Unknown opcode 0

[mf59816]

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. (-:

{-

If this file is ./y.hs, this is what happens:

$ echo -ne ':load y.hs\n:printHeap x\n' | ghci
GHCi, version 7.6.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
(0.00 secs, 0 bytes)
(0.00 secs, 0 bytes)
(0.00 secs, 0 bytes)
(0.00 secs, 513936 bytes)
(0.00 secs, 0 bytes)
(0.00 secs, 0 bytes)
(0.00 secs, 0 bytes)
Prelude> [1 of 1] Compiling Main             ( y.hs, interpreted )
Ok, modules loaded: Main.
(0.05 secs, 22011784 bytes)
*Main> Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
[..]
Loading package ghc-heap-view-0.5.3 ... linking ... done.
let t1 = (_bco (_bco x2 f1) (_sel t2))()
    x1 = toArray (30 words) 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,(and more)
    x2 = D:Enum _fun _fun _fun _fun _fun _fun _fun _fun
    f1 = _fun
    t2 = _thunk (_sel t3)
    t3 = _thunk (_sel t4)
    t4 = _thunk (_sel t5)
    t5 = _thunk (_thunk _fun{MVar [_bco (_bco _fun) (_bco (_bco *** Exception: Unknown opcode 0
*Main> Leaving GHCi.

If I remove the definition of `p`, this happens instead:

[...] (as above)
    t3 = _thunk (_sel t4)
    t4 = _thunk (_thunk _fun{MVar [_bco (_bco _bco() (_bco (_bco t5) (_bco (_bco t5) x4 f2) (_bco (_bco t5) x4 f2))),(_bco (_bco x5 _fun) x5 _fun)(),(_bco (_bco _fun _fun) x5 _fun)(),_bco (_bco (_bco (_bco f3) (_bco (_bco f4) f5) f6) (_bco x6 f7) f8 (_bco (_bco f3) (_bco (_bco f4) f5) f6) (_bco x6 f7) f8 (_bco (_bco f3) (_bco (_bco f4) f5) f6) (_bco x6 f7) f8),_bco (_bco (_sel t6)) (_bco (_sel t9)) (_bco (_sel t8)),_bco (_bco (_bco *** Exception: Prelude.(!!): index too large

*Main> Leaving GHCi.

If I remove the line 'deriving (Eq, Show)' and the definition of p,
everything works.

-}

rev  = foldl (flip (:)) []
rev' = foldr (\ x r -> r ++ [x]) []
x = rev [1..6]
y = rev' [1..6]

data E a = E a
   deriving (Eq, Show)

c :: [E a] -> Int
c _ = 0

p :: Eq a => [a] -> [E a] -> Maybe [a]
p _ _ = Nothing

[def-]

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.

[sheganinans]

Hey guys, maybe my error might shed some light on the situation?

[nmattia]

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?

[nomeata]

Confirmed, using 7.10.3 in Debian (although I get a segmentation fault). No further investigation yet.

[code5hot]

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?

[hansroland]

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 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.

[code5hot]

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, [email protected] 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 .