Subject: [ ghc-Bugs-1234239 ] Bad location for violation of functional dependency - msg#00058

Previous Message by Date: click to view message preview

[ ghc-Bugs-1219920 ] socketToHandle, hGetContents cause errors in ghci

Bugs item #1219920, was opened at 2005-06-13 19:34 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1219920&group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libraries/network Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Andrew Pimlott (pimlott) Assigned to: Simon Marlow (simonmar) Summary: socketToHandle, hGetContents cause errors in ghci Initial Comment: I wrote a server using socketToHandle and hGetContents. The first request worked fine, but the second request crashed with "internal error: scavenge_stack: weird activation record found on stack: 9". I tried to create a test case. I couldn't reproduce the same problem, but I did get an intermittent "Bad file descriptor". I think it may be a related problem, and it may have to do with garbage collection (based on a strace showing a call to getrusage). The program is below, and when I run it with runghc and feed it a line of input with nc, it crashes on the 17th request. It's not important to me that you fix it; in fact I only tried this as an experiment to simplify some working code. But if you would like more information, let me know. I am using the Debian package ghc6 6.4-4. import Network.Socket import System.IO main = do s <- socket AF_INET Stream 0 h <- inet_addr "127.0.0.1" bindSocket s (SockAddrInet 1236 h) listen s 5 loop s loop listenSock = do (s,_) <- accept listenSock h <- socketToHandle s ReadMode input <- hGetContents h putStrLn (take 10 input) send s "got it\n" sClose s loop listenSock ---------------------------------------------------------------------- >Comment By: Simon Marlow (simonmar) Date: 2005-07-07 15:00 Message: Logged In: YES user_id=48280 It looks like a bug, but it has a rationale explanation. After you call sClose, there is still a finalizer in the system waiting to close the Handle. However, since the file descriptor has been closed, it can be re-used by the next call to accept, at which point the finalizer can run and close a file descriptor that is in use again, leading to the lazyRead error you see. I've added some code to Network.Socket to prevent the use of sClose and other socket operations after socketToHandle. ---------------------------------------------------------------------- Comment By: Andrew Pimlott (pimlott) Date: 2005-07-06 17:00 Message: Logged In: YES user_id=498741 I should have detailed my test scenario, but what I see when I run "echo hello world | nc localhost 1236" repeatedly is that "hello worl" is printed 16 times, then *** Exception: <socket: 5>: lazyRead: invalid argument (Bad file descriptor) So the error happens while trying to print out "input". As I understand, input should keep a reference to h, which should keep a reference to s, so nothing should get garbage collected too soon. Moreover, something that happens later (sClose) shouldn't be able to affect it. That said, when I use hClose, or remove the close, I can't reproduce the problem. So I'm perplexed. Can I ask you to explain in more detail? ---------------------------------------------------------------------- Comment By: Simon Marlow (simonmar) Date: 2005-07-06 10:57 Message: Logged In: YES user_id=48280 The "Bad file descriptor" error messages are to be expected: when you turn a Socket into a Handle, it gets a finalizer attached which closes the socket when the Handle is no longer referenced. You want to call hClose h rather than sClose s in the code above. I've added some documentation for socketToHandle to reflect this. If you can reproduce the "scavenge_stack" error, please follow up with more info, for now I'll close this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1219920&group_id=8032

Next Message by Date: click to view message preview

[ ghc-Bugs-1234256 ] instance of synonym

Bugs item #1234256, was opened at 2005-07-07 09:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1234256&group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler (Type checker) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: instance of synonym Initial Comment: The following non-Haskell 98 instance is accepted even without -fglasgow-exts: type Foo = Double instance Bounded Foo The error message quotes the relevant part of the Report (The instance type must be of form (T a b c) where T is not a synonym, and a,b,c are distinct type variables) and the code expresses this, but it seems that type synonyms have already been expanded, so only non-saturated ones are left at this stage. ross@xxxxxxxxxxxxxx ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1234256&group_id=8032

Previous Message by Thread: click to view message preview

[ ghc-Bugs-1186431 ] mkGraph Stack Overflow

Bugs item #1186431, was opened at 2005-04-20 14:50 Message generated for change (Comment added) made by dons You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1186431&group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libraries (other) Group: 6.4 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: mkGraph Stack Overflow Initial Comment: module Data.Graph.Inductive.Graph mkGraph :: [LNode a] -> [LEdge b] -> gr a b mkGraph dies on large graphs. 'mkGraph nodes edges' gives stack overflow error. length nodes -> 20000 length edges -> 400000 ---------------------------------------------------------------------- Comment By: Don Stewart (dons) Date: 2005-07-07 14:49 Message: Logged In: YES user_id=880987 Here's a test program: ------------------------------------------------------------------------ module Main where import Data.Graph.Inductive ( Gr, mkGraph ) import Control.Exception ( evaluate ) type Graph = Gr () () main = do let nodes = [ (n,()) | n <- [1 .. 20000] ] edges = [ (n,m,()) | (n,_) <- nodes, (m,_) <- nodes, n /= m ] g = mkGraph nodes edges :: Graph _ <- Control.Exception.evaluate g putStrLn "done" ------------------------------------------------------------------------ Which will overflow: $ ghc -O -package fgl Test.hs $ ./a.out Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize' to increase it. Now, we can squash this bug by replacing the foldr in insEdges in Data.Graph.Inductive.Tree with a foldl': ------------------------------------------------------------------------ --- /home/dons/fptools/libraries/fgl/Data/Graph/Inductive/Tree.hs Thu Jul 7 11:58:34 2005 +++ ./Tree2.hs Thu Jul 7 14:07:38 2005 @@ -3,6 +3,7 @@ module Data.Graph.Inductive.Tree (Gr,UGr) where +import Data.List (foldl') import Data.Graph.Inductive.Graph import Data.Graph.Inductive.Internal.FiniteMap @@ -44,7 +45,10 @@ empty = Gr emptyFM isEmpty (Gr g) = case g of {Empty -> True; _ -> False} match = matchGr - mkGraph vs es = (insEdges es . insNodes vs) empty + mkGraph vs es = (insEdges' es . insNodes vs) empty + where + insEdges' es g = foldl' (flip insEdge) g es + labNodes (Gr g) = map (\(v,(_,l,_))->(v,l)) (fmToList g) -- more efficient versions of derived class members -- ------------------------------------------------------------------------ However, we'll still run out of heap after a couple of minutes anyway. (this is for n=200 by the way) $ time ./a.out a.out: out of memory (requested 1048576 bytes) ./a.out 21.47s user 7.94s system 14% cpu 3:17.98 total Down to n=50, some profiling reveals: COST CENTRE MODULE %time %alloc updFM Tree2 56.2 70.2 updAdj Tree2 37.5 9.3 clearPred Tree2 6.2 10.3 Adding some `seq`s to updFM helps a little bit, knocking 25% off the allocs: COST CENTRE MODULE %time %alloc updFM Tree2 35.7 61.1 updAdj Tree2 42.9 12.2 clearPred Tree2 21.4 13.5 Now n=200 still runs out of heap, just takes 25% longer. Here's updFM, from Data/Graph/Inductive/Internal/FiniteMap.hs: updFM :: Ord a => FiniteMap a b -> a -> (b -> b) -> FiniteMap a b updFM (Node h l (j,x) r) i f | i<j = Node h (updFM l i f) (j,x) r | i>j = Node h l (j,x) (updFM r i f) | otherwise = Node h l (j,f x) r versus: updFM (Node h l (j,x) r) i f | i<j = let l' = updFM l i f in l' `seq` Node h l' (j,x) r | i>j = let r' = updFM r i f in r' `seq` Node h l (j,x) r' | otherwise = Node h l (j,f x) r I wonder if a Graph implemented as a Data.Map would make any difference. -- Don Stewart ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1186431&group_id=8032

Next Message by Thread: click to view message preview

[ ghc-Bugs-1234239 ] Bad location for violation of functional dependency

Bugs item #1234239, was opened at 2005-07-07 15:44 Message generated for change (Comment added) made by simonpj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1234239&group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler (Type checker) Group: 6.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mike Gunter (magunter) Assigned to: Nobody/Anonymous (nobody) Summary: Bad location for violation of functional dependency Initial Comment: The code below produces an error message which gives no clue that the actual source of the error is on the line marked L3 (pointing instead to L1 and L2): .../BadWarningLoc.hs:1:0: Couldn't match `S Z' against `Z' Expected type: S Z Inferred type: Z When using functional dependencies to combine MinMax a Z Z a, arising from the instance declaration at .../BadWarningLoc.hs:10:0 MinMax (S Z) Z _c d, arising from use of `t' at .../BadWarningLoc.hs:21:8-10 With the type signature, marked L4, uncommented the error message does indeed point to the culprit, L3. (With L3 commented-out, the code compiles.) thanks, mike {-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances #-} data Z = Z data S a = S a n0 = Z n1 = S n0 class MinMax a b c d | a b -> c d, a c d -> b, b c d -> a instance MinMax Z Z Z Z instance MinMax a Z Z a -- L1: wrongly flagged as error src. instance MinMax Z b Z b instance MinMax a b c d => MinMax (S a) (S b) (S c) (S d) class Extend a b where extend :: a -> b -> b instance Extend Z b where Z `extend` b = b instance MinMax a b _c b => Extend a b where _a `extend` b = b t :: MinMax a b _c d => a -> b -> d t _ _ = (undefined :: d) t1 = n1 `t` n0 -- L2 t2 = n1 `extend` n0 -- L3: uncommenting just this line produces -- an error message pointing at L1 and L2 -- with no mention of the real culprit, L3. --t1 :: S Z -- L4: uncommenting this and L3 produces an -- error message rightly pointing at L2 and L3. ---------------------------------------------------------------------- >Comment By: Simon Peyton Jones (simonpj) Date: 2005-07-13 10:14 Message: Logged In: YES user_id=50165 Here's what is happening. Lacking the type signature t1 :: S Z, we get n0 :: Z n1 :: S v1 t1 :: d1 with constraint ([L2] MinMax (S v1) Z c1 d1) t2 :: Z with constraint ([L3] Extend (S v1) Z) [L2] MinMax (S v1) Z c1 d1, [L3] Extend (S v1) Z ---> <by instance for Extend a b> [L2] MinMax (S v1) Z c1 d1, [L3] MinMax (S v1) Z c2 Z} ---> <combining these two constraints using (a b -> c d) [L2] MinMax (S v1) Z c1 Z, [L3] MinMax (S v1) Z c1 Z} Now there are the two constraints are indistinguishable, and both give rise to the same error: ---> <combining first with [L1] instance MinMax a Z Z a> c1=Z, Z=S v1 ERROR In either case, the error points to L1. A different sequence leads to a different error: [L2] MinMax (S v1) Z c1 d1, [L3] Extend (S v1) Z ---> <by instance for Extend a b> [L2] MinMax (S v1) Z c1 d1, [L3] MinMax (S v1) Z c2 Z} ---> <combining first with [L1] instance MinMax a Z Z a> [L2] MinMax (S v1) Z Z (S2 v1), [L3] MinMax (S v1) Z c2 Z} Now combining the two constraints gives rise to the error, but this time pointing to L2,L3. I can't explain exactly why adding the type signature for t1 changes the order. Hmm. Perhaps a good improvement strategy would be: - first do improvement against the instance declartions - and only then do pairwise improvement between constraints I've implemented that, and indeed it improves the result. Instead of: Foo.hs:1:0: Couldn't match `S Z' against `Z' Expected type: S Z Inferred type: Z When using functional dependencies to combine MinMax a Z Z a, arising from the instance declaration at Foo.hs:10:0 MinMax (S Z) Z _c d, arising from use of `t' at Foo.hs:25:8-10 we get Foo.hs:1:0: Couldn't match `S Z' against `Z' Expected type: S Z Inferred type: Z When using functional dependencies to combine MinMax a Z Z a, arising from the instance declaration at Foo.hs:10:0 MinMax (S Z) Z _c Z, arising from use of `extend' at Foo.hs:27:8-15 And this error in t2 is perfectly correct. You get it even if you comment out the entire definition of t1. tcfail143 tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1234239&group_id=8032