:history throws "Irrefutable pattern failed" exception

[greenrd]

I am trying to use the GHCi debugger to find out why my code has a StackOverflow? exception - but GHCi itself seems to be throwing an exception when I type :history:

(temp)[greenrd@localhost megaslurp]$ ghci Web.Twitter.Slurp               
GHCi, version 6.10.1: http://www.haskell.org/ghc/  :? for help            
Loading package ghc-prim ... linking ... done.                            
Loading package integer ... linking ... done.                             
Loading package base ... linking ... done.                                
[1 of 1] Compiling Web.Twitter.Slurp ( Web/Twitter/Slurp.hs, interpreted )
Loading package syb ... linking ... done.                                 
Loading package array-0.2.0.0 ... linking ... done.
Loading package packedstring-0.1.0.1 ... linking ... done.
Loading package containers-0.2.0.0 ... linking ... done.
Loading package pretty-1.0.1.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package mtl-1.1.0.2 ... linking ... done.
Loading package filepath-1.1.0.1 ... linking ... done.
Loading package old-locale-1.0.0.1 ... linking ... done.
Loading package old-time-1.0.0.1 ... linking ... done.
Loading package unix-2.3.1.0 ... linking ... done.
Loading package directory-1.0.0.2 ... linking ... done.
Loading package process-1.0.1.0 ... linking ... done.
Loading package random-1.0.0.1 ... linking ... done.
Loading package derive-0.1.4 ... linking ... done.
Ok, modules loaded: Web.Twitter.Slurp.
*Web.Twitter.Slurp> :set -fbreak-on-error
*Web.Twitter.Slurp> :trace slurpRetry "/host/twitter-groups.csv"
Loading package base-3.0.3.0 ... linking ... done.
Loading package bytestring-0.9.1.4 ... linking ... done.
Loading package parsec-2.1.0.1 ... linking ... done.
Loading package network-2.2.0.1 ... linking ... done.
Loading package utf8-string-0.3.4 ... linking ... done.
Loading package json-0.4.3 ... linking ... done.
Loading package HTTP-4000.0.5 ... linking ... done.
Loading package binary-0.5.0.1 ... linking ... done.
Loading package mime-0.3.0 ... linking ... done.
Loading package csv-0.1.1 ... linking ... done.
Loading package hs-twitter-0.2.5 ... linking ... done.
Stopped at <exception thrown>
_exception ::
  e = GHC.Exception.SomeException (GHC.Exception.:DException _
                                                             (GHC.Show.:DShow ...) ....)
                                  GHC.IOBase.StackOverflow
[<exception thrown>] *Web.Twitter.Slurp> :history
*** Exception: main/InteractiveEval.hs:(179,13)-(183,46): Irrefutable pattern failed for pattern Data.Maybe.Just decl

[greenrd]

Also occurs on 6.10.2 - updating version.

[greenrd]

It turns out that this was one of those cases where increasing the maximum stack size solves the original StackOverflow? problem. So it was not an infinite loop that I was trying to debug.

[igloo]

Thanks for the report

[igloo]

Can you attach a testcase so that we can reproduce the problem, please?

[igloo]

No response from submitter, so closing.

[mnislaih]

Actually the bug exists still in HEAD (7.0). I ran across it and took the time to fix it, closing a long standing TODO in InteractiveEval?.hs

I am attaching the fix for merging to HEAD. The patch is lightweight enough to include it in 7.01 imho. Instead of looking around to find the enclosing declaration of a tick, this patch makes use of the information already collected during the coverage desugaring phase.

[igloo]

This makes hist001 fail; is the new output OK?:

=====> hist001(ghci) 72 of 74 [0, 0, 0]
cd . && HC='/home/ian/ghc/darcs/ghc/inplace/bin/ghc-stage2' HC_OPTS='-dcore-lint
 -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts  ' '/home/ian/ghc/d
arcs/ghc/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore-lint 
-dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts   -ignore-dot-ghci  
 <hist001.script >hist001.run.stdout 2>hist001.run.stderr
Actual stdout output differs from expected:
--- ./hist001.stdout.normalised 2010-11-21 18:48:24.000000000 +0000
+++ ./hist001.run.stdout.normalised     2010-11-21 18:48:24.000000000 +0000
@@ -1,15 +1,15 @@
 Breakpoint 0 activated at ../Test3.hs:1:14-15
 [2,3Stopped at ../Test3.hs:1:14-15
 _result :: [a] = _
--1  : mymap (../Test3.hs:(1,1)-(2,31))
+-1  : (../Test3.hs:(1,1)-(2,31))
 -2  : mymap (../Test3.hs:2:22-31)
 -3  : mymap (../Test3.hs:2:18-20)
 -4  : mymap (../Test3.hs:2:18-31)
--5  : mymap (../Test3.hs:(1,1)-(2,31))
+-5  : (../Test3.hs:(1,1)-(2,31))
 -6  : mymap (../Test3.hs:2:22-31)
 -7  : mymap (../Test3.hs:2:18-20)
 -8  : mymap (../Test3.hs:2:18-31)
--9  : mymap (../Test3.hs:(1,1)-(2,31))
+-9  : (../Test3.hs:(1,1)-(2,31))
 <end of history>
 Logged breakpoint at ../Test3.hs:(1,1)-(2,31)
 _result :: [a]
*** unexpected failure for hist001(ghci)

[mnislaih]

Previously the enclosing function for a tick wrapping an entire function definition f was f itself. With this patch, the enclosing function is attributed to be the module itself.

The previous output was nicer to the user, but one could argue that the new output is more correct. In my opinion it is not a big deal, and changing it to behave as before would involve having a hybrid approach to resolving the enclosing decl of a tick, which does not sound appealing at all.

So I would say the new output is OK.

[igloo]

Thanks; applied.

[simonmar]

Replying to mnislaih:

The previous output was nicer to the user, but one could argue that the new output is more correct. In my opinion it is not a big deal, and changing it to behave as before would involve having a hybrid approach to resolving the enclosing decl of a tick, which does not sound appealing at all. So I would say the new output is OK.

I think it's a bit of a shame to lose that, since the breakpoint really is on the top-level function, not the module. Why are these outer breakpoints not attributed to the function any more?

[mnislaih]

Replying to simonmar:

Replying to mnislaih:

The previous output was nicer to the user, but one could argue that the new output is more correct. In my opinion it is not a big deal, and changing it to behave as before would involve having a hybrid approach to resolving the enclosing decl of a tick, which does not sound appealing at all. So I would say the new output is OK.

I think it's a bit of a shame to lose that, since the breakpoint really is on the top-level function, not the module. Why are these outer breakpoints not attributed to the function any more?

They are not attributed anymore because they are not "below" the outer function when traversing the AST. I don't know how to restore the previous behaviour for every non-attributed breakpoint, but probably the common case of a breakpoint surrounding a top-level function can be dealt with easily. I will look at this as soon as I find some time, hopefully this week.

[simonmar]

Great, thanks. Re-opening so we don't forget.

[mnislaih]

Attached a patch that restores the previous behaviour for top level binds and was trivial to implement.

[igloo]

Applied, thanks!