Repl hanging

[MichaelXavier]

Fair warning: this isn't going to have great details on how to reproduce this issue. I'm mostly looking for some guidance on how to tease out what's going on here.

I use the interactive haskell process in a large project. Pretty consistently now if I haskell-process-load-or-reload it will load the file fine, but then the repl will essentially get stuck. Subsequent calls to haskell-process-load-or-reload will just put in the minibuffer "No changes need to be saved" and not do anything. I also can't enter any commands on the repl. When I strace the repl process I see it hanging on a wait4.

This doesn't seem to really happen on smaller project, which makes this hard to reproduce.

Some system info:

The Glorious Glasgow Haskell Compilation System, version 7.6.3
cabal-install version 1.20.0.3
using version 1.20.0.0 of the Cabal library
haskell-mode version 20141130.1012

Any ideas on how I can troubleshoot this/get you more info?

Thanks!

[karljs]

I would start by setting haskell-process-log to t via customize or in your init file and then seeing what the log output looks like.

[MichaelXavier]

I'm not sure if this is it but I just had a session fail and the last thing in the log is the usage for hasktags:

:!cd /home/michael/src/whatever && find . -name '*.hs' -or -name '*.lhs' -or -name '*.hsc' -print0 | xargs -0 hasktags -e -x
<- Usage: hasktags [OPTION...] [files or directories...]
   directories will be replaced by DIR/**/*.hs DIR/**/*.lhs
   Thus hasktags . tags all important files in the current
   directory.

   If directories are symlinks they will not be followed
   unless you pass -L.

<- 
   A special file "STDIN" will make hasktags read the line separated file
   list to be tagged from STDIN.

     -c            --ctags                        generate CTAGS file (ctags)
     -e            --etags                        generate ETAGS file (etags)
     -b            --both                         generate both CTAGS and ETAGS
     -a            --append                       append to existing CTAGS and/or ETAGS file(s). After this file will no longer be sorted!
                   --ignore-close-implementation  ignores found implementation if its closer than 7 lines  - so you can jump to definition in one shot
     -o            --output=                      output to given file, instead of 'tags', '-' file is stdout
     -f            --file=                        same as -o, but used as compatibility with ctags
     -x            --extendedctag                 Generate additional information in ctag file.
                   --cache                        Cache file data.
     -L            --follow-symlinks              follow symlinks when recursing directories
     -S[.hs,.lhs]  --suffixes[=.hs,.lhs]          list of hs suffixes including "."
     -R            --tags-absolute                make tags paths absolute. Useful when setting tags files in other directories
     -h            --help                         This help

I find that if I just execute that find command, find . -name '*.hs' -or -name '*.lhs' -or -name '*.hsc' -print0 with -print0 at the end, it produces nothing. Omitting it, it produces many lines of results. I've tried moving that -print0 around to no effect. I don't understand find's strange expression language. However, it looks like with hasktags we could eliminate print0 and xargs: find . -name '*.hs' -or -name '*.lhs' -or -name '*.hsc' | hasktags -e -x STDIN since according to the docs, the special filename STDIN will use stdin and expect line-delimited filenames, which is what find produces!

I'm going to modify my local copy of haskell-mode and see if this helps. Either way though, I think this would be a good change. I'd be happy to submit a PR for it if people agreed that it was appropriate.

[MichaelXavier]

Unfortunately this didn't resolve the issue. The hanging seems to be at random. It happens to me often enough that if you need any diagnostics on the running process I should be able to get them. Right now its locked up in my session and the last entries in the log seem pretty uninteresting:

-> :info Milliseconds
<- newtype TrackerPacker.Types.Duration = Milliseconds Int
        -- Defined in `TrackerPacker.Types'
   �
-> :info n
<- 
   Top level: Not in scope: `n'

[chrisdone]

It would be good if you clear your process log buffer and do a session from scratch and reproduce the problem. Everything you've pasted so far seems fine.

[MichaelXavier]

The only problem there is that this doesn't seem to happen deterministically. Sometimes I can get through 20+ minutes of normal work before it crops up. Right now I'm actually (attempting to) debugger step through haskell-process-load-file. I wonder if there's any reflection I can do on the session or haskell process state that may illuminate things.

[chrisdone]

It'll usually happen if some commmand (like tags) or whatever locks up the queue. Any subsequent commands in the queue won't be run, including any REPL commands. You can see what it was trying to do when it looks up by looking at the contents of (haskell-process)

[MichaelXavier]

Ah now this is getting interesting. That produced about 3400 lines of output but I see several times this snippet:

   (inferior-process . #<process dynaweb>)
   (is-restarting)
   (current-command .
                    [cl-struct-haskell-command
                     (#0)
                     (lambda
                       (state)
                       (haskell-process-send-string
                        (car state)
                        (if
                            (string-match "^[A-Za-z_]"
                                          (cdr state))
                            (format ":info %s"
                                    (cdr state))
                          (format ":info (%s)"
                                  (cdr state)))))
                     nil
                     (lambda
                       (state response)
                       (if
                           (or
                            (string-match "^Top level" response)
                            (string-match "^<interactive>" response))
                           nil
                         (haskell-mode-message-line response)))])
   (suggested-imported)
   (sent-stdin)
   (evaluating)

[MichaelXavier]

Is there some way a command can either be timed out or aborted by the repl? I'm kind of at a loss here. When this feature is working well it saves me tons of time.

[chrisdone]

C-c C-c?

[MichaelXavier]

On a whim when watching the log I saw that i was using flymake-haskell-multi, which in turn was using flymake alongside flycheck on my haskell code. I saw interleaved calls from haskell-mode and flymake and figured this could be the source of a race condition. I've uninstalled that package and so far so good. I figure by the end of the day if I don't get any lockups, that must have been the issue.

[MichaelXavier]

Damn. Unfortunately the problem still persists. Is there anything I can do to provide more info? I'm happy to do as much work as necessary to get this figured out, its just that my elisp debugging skills aren't where they need to be at yet to debug it myself.

[zovt]

I'm having the same problem myself. For me at least, it would seem that I can

1. Load a haskell file into a new GHCi session using C-c C-l
2. Use the REPL at this point to evaluate functions, etc.
3. Switch back to the source code using either C-c C-z or C-x o
4. Make some changes, save source. Use C-c C-b to switch to the REPl

It's after 4 when it locks up with no indication

[sritchie]

I'm seeing this issue as well. It looks like #536 might be a duplicate. (haskell-process-clear)unhangs my repl; I've bound that command tof7` for now so I can at least keep moving. This happens a lot, and seems to be triggered by hasktags in my case.