RE: SegFault caused by some IO+Arrays+GC interaction
On 27 June 2004 23:37, Tomasz Zielonka wrote: The attached program uses no unsafe operations and yet it segfaults from time to time. Try it on some file of moderate size, like: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.2.1 $ ghc -O --make Bug -o Bug Chasing modules from: Bug Compiling Main ( Bug.hs, Bug.o ) Linking ... $ ls -l /etc/termcap -rw-r--r--1 root root 737535 lip 20 2001 /etc/termcap $ ./Bug /etc/termcap /dev/null Segmentation fault (core dumped) $ ./Bug /etc/termcap /dev/null $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.2.1 $ gcc --version gcc (GCC) 3.3.3 Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ uname -a Linux green.local.gem.pl 2.4.18-10 #1 Wed Aug 7 10:26:48 EDT 2002 i686 unknown Thanks for a superb bug report. This bug appears to be another incarnation of a bug that has been fixed since 6.2.1. I used the 6.2.1 compiler but linked the program against the latest runtime on the 6.2 branch, which is identical except for this single fix, and the crash went away. So you can either wait for 6.2.2 (shouldn't be too long), use a nightly snapshot of the 6.2 branch, or build from source. Or if you have an existing 6.2.1 build locally, I can put together a patch for this fix - let me know. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: SegFault caused by some IO+Arrays+GC interaction
On Mon, Jun 28, 2004 at 12:07:32PM +0100, Simon Marlow wrote: Thanks for a superb bug report. This bug appears to be another incarnation of a bug that has been fixed since 6.2.1. I used the 6.2.1 compiler but linked the program against the latest runtime on the 6.2 branch, which is identical except for this single fix, and the crash went away. I am pleased to see that it's already fixed. Anyway, next time I will test with a development version of the compiler before sending a bug report. So you can either wait for 6.2.2 (shouldn't be too long), use a nightly snapshot of the 6.2 branch, or build from source. Or if you have an existing 6.2.1 build locally, I can put together a patch for this fix - let me know. Sure, I'll test the snapshot in a moment. Thanks, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: SegFault caused by some IO+Arrays+GC interaction
On Mon, Jun 28, 2004 at 01:38:42PM +0200, Tomasz Zielonka wrote: On Mon, Jun 28, 2004 at 12:07:32PM +0100, Simon Marlow wrote: So you can either wait for 6.2.2 (shouldn't be too long), use a nightly snapshot of the 6.2 branch, or build from source. Or if you have an existing 6.2.1 build locally, I can put together a patch for this fix - let me know. Sure, I'll test the snapshot in a moment. OK, now it doesn't crash. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-978107 ] arrow notation example can't be parsed
Bugs item #978107, was opened at 2004-06-23 11:11 Message generated for change (Settings changed) made by rosspaterson You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=978107group_id=8032 Category: Compiler (Parser) Group: 6.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: John Hughes (rjmh) Assigned to: Nobody/Anonymous (nobody) Summary: arrow notation example can't be parsed Initial Comment: This expression can't be parsed: bug f g = proc x - f g - x Brackets are needed around fg to get it through the parser. Can't see any justification for this -- the documentation suggests any expression is allowed before -, and indeed, cannot be confused with a command operator because f is not a command. Are you parsing - as an operator with a precedence greater than ? Hard to see otherwise why this doesn't parse. John -- Comment By: Nobody/Anonymous (nobody) Date: 2004-06-23 13:17 Message: Logged In: NO The grammar in the documentation is imprecise. In essence, this problem is another instance of the old if/lambda/let/case vs infix ambiguity (complicated because GHC parses cmd as exp). I was ducking the conflicts by having cmd ::= fexp - exp but I'll change that to cmd ::= exp0 - exp (adding 4 shift/reduce conflicts) because the default conflict resolution in favour of shift is the sensible thing here. And I'll fix the documentation. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=978107group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-978068 ] arrow syntax example can't be parsed
Bugs item #978068, was opened at 2004-06-23 10:08 Message generated for change (Settings changed) made by rosspaterson You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=978068group_id=8032 Category: Documentation Group: 6.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: John Hughes (rjmh) Assigned to: Nobody/Anonymous (nobody) Summary: arrow syntax example can't be parsed Initial Comment: This example from section 7.6 of the user guide can't be parsed by the compiler: expr' = proc x - returnA - x + do symbol Plus - () y - term - () expr' - x + y + do symbol Minus - () y - term - () expr' - x - y The reason is that the first + is wrongly parsed as part of the previous expression (x + ...) rather than as a command operator. The fix is either to enclose the first command (returnA - x) in parentheses, or precede it with do so that the layout rule terminates the command before the +. (The second use of + is OK precisely because the layout rule terminates the previous command before it). Apart from fixing the example, I think it would be worth commenting the problem -- this is a syntax gotcha that is easy to stumble over. Maybe add this just after the example above: Note that a command operator risks being interpreted as a part of the expression at the end of the preceding command. To prevent this, such a command should either be enclosed in parentheses, or terminated by the layout rule before the operator. The example above would be parsed wrongly if the do before the returnA were omitted. This assumes it's fixed by inserting a do, of course! John -- Comment By: Nobody/Anonymous (nobody) Date: 2004-06-23 15:25 Message: Logged In: NO Indeed I thought I could simplify the example by removing the do. The error is obvious in retrospect, and the same gotcha exists with ordinary expressions, but I'll add a warning. Ross -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=978068group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
