RE: [Haskell-cafe] How to debug GHC
On 10 September 2005 21:15, Frederik Eaton wrote:
On Fri, Sep 02, 2005 at 04:40:05PM +0400, Bulat Ziganshin wrote:
Hello Nils,
Friday, September 02, 2005, 10:47:05 AM, you wrote:
Compile your program with -prof -auto-all (make sure you have the
I tried this out under GHC 6.4/Linux and got a segmentation fault instead of a stack trace. Under GHC 6.2.2 it seemed to work, though.
this error is already fixed in current pre-6.4.1 version
I'm using a 2005/9/3 version of 6.4.1 and running into situations where the "stack trace" has function A calling function B, where when I look at the code, A never calls B. Is this normal? Is it some side-effect of laziness? It sure makes the traces a lot less useful.
It could be a bug - can you reduce the example and report it? GHC's profiler tries to overlay a lexical call graph on to the dynamic execution of the program. It does this more or less in the way you described before: every function gets an extra argument describing the call context. However, there are some tricky areas: notably CAFs. We don't as yet have a principled description of the mechanism, and I know of various cases where odd results are obtained with the current system. Also, the optimiser has to be careful not to change the shape of the call graph, and I suspect there are cases where it goes wrong. Cheers, Simon
On Wed, Sep 14, 2005 at 02:44:11PM +0100, Simon Marlow wrote:
On 10 September 2005 21:15, Frederik Eaton wrote:
On Fri, Sep 02, 2005 at 04:40:05PM +0400, Bulat Ziganshin wrote:
Hello Nils,
Friday, September 02, 2005, 10:47:05 AM, you wrote:
Compile your program with -prof -auto-all (make sure you have the
I tried this out under GHC 6.4/Linux and got a segmentation fault instead of a stack trace. Under GHC 6.2.2 it seemed to work, though.
this error is already fixed in current pre-6.4.1 version
I'm using a 2005/9/3 version of 6.4.1 and running into situations where the "stack trace" has function A calling function B, where when I look at the code, A never calls B. Is this normal? Is it some side-effect of laziness? It sure makes the traces a lot less useful.
It could be a bug - can you reduce the example and report it?
GHC's profiler tries to overlay a lexical call graph on to the dynamic execution of the program. It does this more or less in the way you described before: every function gets an extra argument describing the call context. However, there are some tricky areas: notably CAFs. We don't as yet have a principled description of the mechanism, and I know of various cases where odd results are obtained with the current system. Also, the optimiser has to be careful not to change the shape of the call graph, and I suspect there are cases where it goes wrong.
I see. Well, I'm afraid I've lost the example, but I'll keep my eyes open in case it happens again. It's good to know what the correct behavior is supposed to be. Frederik -- http://ofb.net/~frederik/
It could be a bug - can you reduce the example and report it?
GHC's profiler tries to overlay a lexical call graph on to the dynamic execution of the program. It does this more or less in the way you described before: every function gets an extra argument describing the call context. However, there are some tricky areas: notably CAFs. We don't as yet have a principled description of the mechanism, and I know of various cases where odd results are obtained with the current system. Also, the optimiser has to be careful not to change the shape of the call graph, and I suspect there are cases where it goes wrong.
I see. Well, I'm afraid I've lost the example, but I'll keep my eyes open in case it happens again. It's good to know what the correct behavior is supposed to be.
While I was finishing a project for somebody I ran into this problem again, as well as some other bugs, and made several copies of the code so that the problems could be reproduced. In addition to the stack trace problems, I found: (1) a problem where output freezes when it is being piped through 'tee' and the user presses ^S and then ^Q and (2) an issue where a "trace" statement is not being printed correctly by ghc (but is being printed correctly by runghc). However, I don't have time to reduce these to minimal test cases. Do you want to look at them anyway? Frederik -- http://ofb.net/~frederik/
Frederik Eaton wrote:
In addition to the stack trace problems, I found: (1) a problem where output freezes when it is being piped through 'tee' and the user presses ^S and then ^Q
That's the terminal driver; use "stty -ixon" to disable that.
If your program requires "raw" keyboard input, you should explicitly
disable canonical mode on the terminal using setTerminalAttributes.
However, note that this will also disable ^C, ^Z etc.
The GHC runtime *might* do this implicitly if you make stdin
unbuffered (I know it messes around with the terminal state if you
change the buffering for a handle which is associated with a terminal,
but I don't remember the specifics).
--
Glynn Clements
On Mon, Sep 19, 2005 at 02:22:10PM +0100, Glynn Clements wrote:
Frederik Eaton wrote:
In addition to the stack trace problems, I found: (1) a problem where output freezes when it is being piped through 'tee' and the user presses ^S and then ^Q
That's the terminal driver; use "stty -ixon" to disable that.
That will sure prevent ^S and ^Q having any effect, but it won't make the bug go away. With other programs, e.g. if I run seq 100000 | tee foo and press ^S and then ^Q, then suspend and resume work as expected, there is no freezing shortly after resume as I am observing with my ghc-compiled program. The program should resume its output when ^Q is pressed, rather than freezing. Frederik -- http://ofb.net/~frederik/
participants (3)
-
Frederik Eaton -
Glynn Clements -
Simon Marlow