bugs/issues in jhc-0.7.6
Hello, I just wanted to report some bugs & issues with jhc using SDL bindings (https://patch-tag.com/r/snk_kid) I've put links to the original Haskell code and generated C (which was outputted from compile-time error) at the end of this email. C Compile-time errors: This one comes up quite lot, and happens quite randomly: test_code.c:4136: error: ‘v74’ undeclared (first use in this function) test_code.c:4136: error: (Each undeclared identifier is reported only once test_code.c:4136: error: for each function it appears in.) This is generated for the code: failWithError :: String -> IO a failWithError msg = do err <- fmap (fromMaybe "No SDL error") getError ioError $ userError $ msg ++ "\nSDL message: " ++ err Sometimes it goes away just by shuffling some code, even just commenting a line and uncomment it again can make it go away but it happens a lot and sometimes it's really hard to make it go for a long period of time. The problem is there is a function called but the argument given is not defined in the scope it's used in. test_code.c:5182: error: expected expression before ‘;’ token test_code.c: In function ‘fW$__fInstance$__iForeign_Storable_pokeByteOff_default’: This is caused by the code generated for the "whileEvents" in the Haskell source I've attached. It just generates incorrect C code, like it was a serious failure. jhc issues: The action "pollEvent" defined as: foreign import ccall "SDL_PollEvent" sdlPollEvent :: Ptr Event -> IO Int -- | Polls for currently pending events. pollEvent :: IO Event pollEvent = alloca poll where poll ptr = do ret <- sdlPollEvent ptr case ret of 0 -> return NoEvent _ -> do event <- peek ptr case event of NoEvent -> poll ptr _ -> return event When used, while compiling with jhc, when it reaches the compile stage "-- Boxy WorkWrap" jhc consumes a lot of memory and takes a large amount time to finish. Next jhc crashed with the message: "jhc: internal error: evacuate: strange closure type 65350" This happened using the loop function and cross-compiling. Program Runtime issues: When you do get this code to compile (by not using the loop function, use delay), if you comment out the lines I've marked there is a bug where (foreign) pointers in the same scope some how overwrite the values of previously defined pointers even though there is no re-assignment going on so they end up all being the same address value, this code works correctly in ghc. I haven't checked this yet but it feels like a C name-hiding bug from nested scopes. Minor issue, ForeignPtr is missing a Show instance. Test.hs: http://www.mediafire.com/?e93sbeaoib26539 test_code.c: http://www.mediafire.com/?16mj8agucypvp1x
On Sat, Aug 07, 2010 at 11:27:10AM +0000, Korcan Hussein wrote:
Hello, I just wanted to report some bugs & issues with jhc using SDL bindings (https://patch-tag.com/r/snk_kid) I've put links to the original Haskell code and generated C (which was outputted from compile-time error) at the end of this email.
Thanks for the report! I'll look into these. One of the main thing jhc needs right now is people actually attempting to use it and reporting their experiences :)
C Compile-time errors: This one comes up quite lot, and happens quite randomly: test_code.c:4136: error: ‘v74’ undeclared (first use in this function) ... Sometimes it goes away just by shuffling some code, even just commenting a line and uncomment it again can make it go away but it happens a lot and sometimes it's really hard to make it go for a long period of time. The problem is there is a function called but the argument given is not defined in the scope it's used in.
Hmmm.. I have noticed this too on occasion, A problem is that it is a general symptom of bugs in pretty much any grin transformation, I actualyl fixed a major one that was causing this issue in 0.7.6. I believe I need to improve the grin linter (Grin.Lint) to catch these bugs as they occur to get better diagnostic info. Once I narrow it down to a specifc pass and dump before and after code, it is usually easy to find issues like this.
test_code.c:5182: error: expected expression before ‘;’ token test_code.c: In function ‘fW$__fInstance$__iForeign_Storable_pokeByteOff_default’: This is caused by the code generated for the "whileEvents" in the Haskell source I've attached. It just generates incorrect C code, like it was a serious failure. jhc issues: The action "pollEvent" defined as: foreign import ccall "SDL_PollEvent" sdlPollEvent :: Ptr Event -> IO Int -- | Polls for currently pending events. pollEvent :: IO Event pollEvent = alloca poll where poll ptr = do ret <- sdlPollEvent ptr case ret of 0 -> return NoEvent _ -> do event <- peek ptr case event of NoEvent -> poll ptr _ -> return event When used, while compiling with jhc, when it reaches the compile stage "-- Boxy WorkWrap" jhc consumes a lot of memory and takes a large amount time to finish. Next jhc crashed with the message: "jhc: internal error: evacuate: strange closure type 65350" yikes. that means it is hitting a ghc bug, actually ghc behaves strangely sometimes when pushed too far, so it is likely a resource bug in jhc that is triggering it.
This happened using the loop function and cross-compiling. Program Runtime issues: When you do get this code to compile (by not using the loop function, use delay), if you comment out the lines I've marked there is a bug where (foreign) pointers in the same scope some how overwrite the values of previously defined pointers even though there is no re-assignment going on so they end up all being the same address value, this code works correctly in ghc. I haven't checked this yet but it feels like a C name-hiding bug from nested scopes.
Hmm.. could be related to one of the earlier bugs. clearly there is something going wrong in one of the grin transformations.
Minor issue, ForeignPtr is missing a Show instance.
Test.hs: http://www.mediafire.com/?e93sbeaoib26539 test_code.c: http://www.mediafire.com/?16mj8agucypvp1x
Thanks for the report! John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
----------------------------------------
Date: Sun, 8 Aug 2010 18:23:38 -0700 From: john@repetae.net To: jhc@haskell.org Subject: Re: [jhc] bugs/issues in jhc-0.7.6
On Sat, Aug 07, 2010 at 11:27:10AM +0000, Korcan Hussein wrote:
Hello, I just wanted to report some bugs & issues with jhc using SDL bindings (https://patch-tag.com/r/snk_kid) I've put links to the original Haskell code and generated C (which was outputted from compile-time error) at the end of this email.
Thanks for the report! I'll look into these. One of the main thing jhc needs right now is people actually attempting to use it and reporting their experiences :)
I'm glad to hear it :) I really think this project is awesome and has huge potential. I really wanted to submit bug fixes, I tried looking at jhc source but I wasn't sure where to look at except for C.FromGrin, C.Generate but I still wasn't sure where to begin. I have very little knowledge and no experience with PLT & compiler technology.
Next jhc crashed with the message:
"jhc: internal error: evacuate: strange closure type 65350" yikes. that means it is hitting a ghc bug, actually ghc behaves strangely sometimes when pushed too far, so it is likely a resource bug in jhc that is triggering it.
I think I might be confusing things, the crash message isn't related to the previous issue well maybe it is indirectly but the crash happened another time. It only happened once. By the way, when I was building jhc from source I noticed that while building the libraries, compiling Data.Sequence started to consume lots of memory and took a significant amount of time to finish before moving on.
Out of curiosity, were you compiling with '-flint'? when you suspect a bug in the compiler, it is best to do a run with it, it will be much slower but do a full internal typecheck after each pass. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
I didn't try that, I'll have a look at later on today. ----------------------------------------
Date: Tue, 10 Aug 2010 19:47:42 -0700 From: john@repetae.net To: korcan_h@hotmail.com CC: jhc@haskell.org Subject: Re: [jhc] bugs/issues in jhc-0.7.6
Out of curiosity, were you compiling with '-flint'? when you suspect a bug in the compiler, it is best to do a run with it, it will be much slower but do a full internal typecheck after each pass.
John
-- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
Hello, I've now tried compiling with -flint, I've attached the .grin files generated and here is the error message I get: [korcan@localhost jhc_test_case]$ jhc -p SDL -p SDL-image -flint Test.hs -o test --optc='-lSDL' --optc='-lSDL_image' jhc -p SDL -p SDL-image -flint Test.hs -o test --optc=-lSDL --optc=-lSDL_image jhc 0.7.6 (0.7.6-0) Finding Dependencies... Using Ho Cache: '/home/korcan/.jhc/cache' Main [Test.hs] <~/.jhc/cache/sk1vb331e44fj3buqg067ao352.ho> Fresh: <~/.jhc/cache/sk1vb331e44fj3buqg067ao352.ho> Typechecking... Compiling... Collected Compilation... -- typeAnalyzeMethods -- BoxifyProgram -- Boxy WorkWrap -- LambdaLift E ├─case: 642 ├─case-alt: 1134 ├─error: 8 ├─lambda: 142 ├─let-binding: 148 ├─lit: 2257 ├─other: 313 ├─prim: 201 └─var-use: 1253 Converting to Grin... Found 0 CAFs to convert to constants, 0 of which are recursive. Recursive Constant CAFS -- eval ni70382562 WHNF-[CJhc.Addr.Ptr] -- eval ni21451946 WHNF-[CJhc.Order.Bool#] -- eval ni70773738 WHNF-[CJhc.Order.Bool#] -- eval ni1295127577 WHNF-[P2_theMain$8,P2_theMain$9] -- eval ni240266248 WHNF-[CGraphics.UI.SDL.Events.SDLVideoResize,CGraphics.UI.SDL.Events.SDLSysWMEvent,CGraphics.UI.SDL.Events.SDLQuit,CGraphics.UI.SDL.Events.SDLJoyButtonUp,CGraphics.UI.SDL.Events.SDLJoyButtonDown,CGraphics.UI.SDL.Events.SDLJoyHatMotion,CGraphics.UI.SDL.Events.SDLJoyBallMotion,CGraphics.UI.SDL.Events.SDLJoyAxisMotion,CGraphics.UI.SDL.Events.SDLMouseButtonUp,CGraphics.UI.SDL.Events.SDLMouseButtonDown,CGraphics.UI.SDL.Events.SDLMouseMotion,CGraphics.UI.SDL.Events.SDLKeyUp,CGraphics.UI.SDL.Events.SDLKeyDown,CGraphics.UI.SDL.Events.SDLActiveEvent,CGraphics.UI.SDL.Events.SDLNoEvent,CGraphics.UI.SDL.Events.SDLUserEvent] -- eval ni8985014 WHNF-[CGraphics.UI.SDL.Keysym.Keysym] -- eval ni53831604 WHNF-[CGraphics.UI.SDL.Keysym.Keysym] -- eval ni899420229 WHNF-[P3_W@.fInstance@.iForeign.Storable.peek.Graphics.UI.SDL.Events.Event$2,P3_W@.fInstance@.iForeign.Storable.peek.Graphics.UI.SDL.Events.Event$3] -- eval ni166760994 WHNF-[CInt#] -- eval ni139817886 WHNF-[CJhc.Prim.[],CJhc.Prim.:] -- eval ni36780836 WHNF-[CJhc.Maybe.Nothing,CJhc.Maybe.Just] -- eval ni191777968 WHNF-[P2_theMain$5,P2_theMain$3,P2_theMain$2] -- eval ni1042810937 WHNF-[P2_theMain$6,P2_Foreign.C.String.withCString$2,P2_Graphics.UI.SDL.Events.223_poll] -- eval ni2300728 WHNF-[CJhc.Addr.Ptr] -- eval ni1383605275 WHNF-[?] -- eval ni2996210 WHNF-[CJhc.Prim.[],CJhc.Prim.:] -- eval ni103540822 WHNF-[CGraphics.UI.SDL.Events.Focus#,CGraphics.UI.SDL.Keysym.Modifier#] -- eval ni7946072 WHNF-[CGraphics.UI.SDL.Events.Focus#,CGraphics.UI.SDL.Keysym.Modifier#] -- eval ni101149094 WHNF-[CWord8#,CWord32#] -- eval ni101149094 WHNF-[CWord8#,CWord32#] -- eval ni1773802053 WHNF-[CWord8#,CWord32#] -- eval ni1773802053 WHNF-[CWord8#,CWord32#] -- eval ni41382390 WHNF-[CGraphics.UI.SDL.Events.Focus#,CGraphics.UI.SDL.Keysym.Modifier#] -- eval ni71352712 WHNF-[CGraphics.UI.SDL.Events.Focus#,CGraphics.UI.SDL.Keysym.Modifier#] -- eval ni132079112 WHNF-[CWord8#] -- eval ni15034878 WHNF-[CJhc.Addr.Ptr]
Before Simplify-Grin Writing: test_lint-before-Simplify-Grin.grin Simplify-Grin ├─Grin │ └─Simplify │ ├─Assign │ │ ├─tuple-tuple: 70 │ │ └─unit-unit: 8 │ ├─Subst │ │ ├─const: 23 │ │ └─var: 33 │ ├─Unbox.case-return: 10 │ ├─error-discard: 1 │ └─tail-return-omit: 172 ├─Optimize.optimize.let-shrink-tail: 5 └─Simplify ├─CSE.demote: 34 ├─Omit.Bind: 8 ├─ZeroVar │ ├─bp254: 1 │ ├─bp353: 1 │ ├─bp557: 1 │ ├─bp575: 1 │ ├─h842: 1 │ ├─h867: 1 │ ├─l590: 1 │ ├─nd475: 1 │ ├─nd503: 1 │ ├─nd510: 1 │ ├─ni340: 1 │ ├─ni341: 1 │ ├─ni545: 1 │ ├─ni546: 1 │ ├─ni715: 1 │ ├─o317: 1 │ ├─o376: 1 │ ├─o394: 1 │ ├─w1062: 1 │ ├─w224: 1 │ ├─w500: 1 │ ├─w552: 1 │ ├─w813: 1 │ └─w96: 1 └─simplify.let-shrink-head: 4
After Simplify-Grin Writing: test_lint-after-Simplify-Grin.grin Type Errors variable not in scope: bp74 fGraphics.UI.SDL.General.failWithError ni1444155455 = do bp419 <- (HsPtr)SDL_GetError() ni166760994 <- nd347 <- let* fW@.fForeign.Marshal.Array.139_loop w41997188 = do ni1 <- nd302 <- dstore (CInt# w41997188) ni231367164 <- demote nd302 w99674760 <- w41997188 * sizeof(bits8)::bits32 bp60138236 <- (bits<ptr>)ConvOp Sx bits32 w99674760 bp20609280 <- bp74 + bp60138236 o5225520 <- bits8[bp20609280] case o5225520 of 0 -> return ni231367164 o317 -> do w194322548 <- 1 + w41997188 w1 <- return w194322548 nd1 <- fW@.fForeign.Marshal.Array.139_loop w1 ni2 <- demote nd1 return ni2 nd2 <- promote ni1 return nd2 in fW@.fForeign.Marshal.Array.139_loop 0 demote nd347 nd100084 <- promote ni166760994 (CInt# w8575516) <- return nd100084 h100086 <- 0 `Gte` w8575516 ni139817886 <- nd1 <- case h100086 of 1 -> return [] 0 -> do w139403250 <- w8575516 - 1 ni364 <- return &[] let* fW@.fForeign.C.String.7_loop nd36833818 w265732834 = do ni36834187 <- demote nd36833818 w252616262 <- w265732834 * sizeof(bits8)::bits32 bp157021598 <- (bits<ptr>)ConvOp Sx bits32 w252616262 bp61426846 <- bp419 + bp157021598 o43070828 <- bits8[bp61426846] w81608550 <- (bits32)ConvOp Zx bits8 o43070828 nd641 <- dstore (Char w81608550) ni155208920 <- demote nd641 h100088 <- 0 `Gte` w265732834 ni387 <- nd1 <- case h100088 of 1 -> do nd644 <- dstore (CJhc.Prim.: ni155208920 ni36834187) return nd644 0 -> do w108926542 <- w265732834 - 1 nd646 <- dstore (CJhc.Prim.: ni155208920 ni36834187) ni190326150 <- demote nd646 ni383 <- return ni190326150 w385 <- return w108926542 nd769 <- promote ni383 nd386 <- fW@.fForeign.C.String.7_loop nd769 w385 return nd386 demote nd1 promote ni387 in w366 <- return w139403250 nd731 <- promote ni364 nd367 <- fW@.fForeign.C.String.7_loop nd731 w366 return nd367 demote nd1 nd100090 <- promote ni139817886 nd331 <- case nd100090 of (CJhc.Prim.: ni0 ni0) -> dstore (CJhc.Maybe.Just ni139817886) [] -> return (CJhc.Maybe.Nothing) ni184969258 <- demote nd331 nd787 <- return nd331 ni68875450 <- istore (FGraphics.UI.SDL.General.failWithError$2 nd787) ni396 <- return &"\nSDL message: " ni398 <- return ni68875450 ni209621540 <- istore (FJhc.Basics.++ ni396 ni398) ni399 <- return ni1444155455 ni401 <- return ni209621540 nd100092 <- fJhc.Basics.++ ni399 ni401 ni134591876 <- demote nd100092 nd403 <- return nd100092 nd404 <- fJhc.IO.putErrLn nd403 exitFailure
----------------------------------------
Date: Tue, 10 Aug 2010 19:47:42 -0700 From: john@repetae.net To: korcan_h@hotmail.com CC: jhc@haskell.org Subject: Re: [jhc] bugs/issues in jhc-0.7.6
Out of curiosity, were you compiling with '-flint'? when you suspect a bug in the compiler, it is best to do a run with it, it will be much slower but do a full internal typecheck after each pass.
John
-- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
Thanks! that allowed me to track down the bug, the 'let-shrink-tail' simplification had a bug in it where the function bodies of a tail-shrunk let wern't simplified. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
That sounds really awesome! thanks, I'm really looking forward to it! ----------------------------------------
Date: Wed, 11 Aug 2010 22:47:11 -0700 From: john@repetae.net To: jhc@haskell.org Subject: Re: [jhc] bugs/issues in jhc-0.7.6
Thanks! that allowed me to track down the bug, the 'let-shrink-tail' simplification had a bug in it where the function bodies of a tail-shrunk let wern't simplified.
John
-- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/ _______________________________________________ jhc mailing list jhc@haskell.org http://www.haskell.org/mailman/listinfo/jhc
participants (2)
-
John Meacham -
Korcan Hussein