Opened 11 years ago

Closed 9 years ago

#3165 closed bug (fixed)

:history throws "Irrefutable pattern failed" exception

Reported by: greenrd Owned by:
Priority: normal Milestone: 7.4.1
Component: GHCi Version: 6.10.2
Keywords: Cc: mnislaih
Operating System: Linux Architecture: x86
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

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

Attachments (2)

fix.patch (203.5 KB) - added by mnislaih 9 years ago.
fixRegression.patch (211.7 KB) - added by mnislaih 9 years ago.

Download all attachments as: .zip

Change History (19)

comment:1 Changed 11 years ago by greenrd

Version: 6.10.16.10.2

Also occurs on 6.10.2 - updating version.

comment:2 Changed 11 years ago by 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.

comment:3 Changed 11 years ago by igloo

difficulty: Unknown
Milestone: 6.12.1

Thanks for the report

comment:4 Changed 10 years ago by igloo

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

comment:5 Changed 10 years ago by igloo

Resolution: invalid
Status: newclosed
Type of failure: None/Unknown

No response from submitter, so closing.

comment:6 Changed 9 years ago by mnislaih

Resolution: invalid
Status: closednew

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.

Changed 9 years ago by mnislaih

Attachment: fix.patch added

comment:7 Changed 9 years ago by mnislaih

Status: newpatch

comment:8 Changed 9 years ago by igloo

Owner: set to igloo

comment:9 Changed 9 years ago by igloo

Cc: mnislaih added

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)

comment:10 Changed 9 years ago by 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.

comment:11 Changed 9 years ago by igloo

Resolution: fixed
Status: patchclosed

Thanks; applied.

comment:12 in reply to:  10 ; Changed 9 years ago by 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?

comment:13 in reply to:  12 Changed 9 years ago by 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.

comment:14 Changed 9 years ago by simonmar

Owner: igloo deleted
Resolution: fixed
Status: closednew

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

comment:15 Changed 9 years ago by simonmar

Milestone: 6.12.17.2.1

Changed 9 years ago by mnislaih

Attachment: fixRegression.patch added

comment:16 Changed 9 years ago by mnislaih

Status: newpatch

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

comment:17 Changed 9 years ago by igloo

Resolution: fixed
Status: patchclosed

Applied, thanks!

Note: See TracTickets for help on using tickets.