http://blog.gmane.org/gmane.comp.lang.haskell.glasgow.bugs hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43355 <pre>#7919: Heap corruption (segfault) from large 'let' expression -------------------------------+-------------------------------------------- Reporter: duncan | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------------+-------------------------------------------- Comment(by igloo): Ah, something more sinister is going on. Andres pointed out that if you change 511 to 512 in `Large.hs`, then the assert still happens. In that case, we get `size == 513`, but `bd.blocks == 1` and `BLOCK_SIZE_W` is only 512. </pre> GHC 2013-05-18T15:26:50 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43354 <pre>#7914: base library's MD5 symbols clash with others ---------------------------------+------------------------------------------ Reporter: bos | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: =&gt; simonmar * difficulty: =&gt; Unknown * priority: normal =&gt; high * milestone: =&gt; 7.8.1 </pre> GHC 2013-05-18T06:31:28 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43353 <pre>#7919: Heap corruption (segfault) from large 'let' expression -------------------------------+-------------------------------------------- Reporter: duncan | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: =&gt; simonmar * priority: normal =&gt; high * milestone: =&gt; 7.8.1 Comment: I'll take a look at this next week. &lt; at &gt;igloo's fix looks like it might avoid breaking assumptions that the later code relies on, but I want to take a proper look at what's going on. </pre> GHC 2013-05-18T06:29:30 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43352 <pre>#7919: Heap corruption (segfault) from large 'let' expression -------------------------------+-------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new =&gt; patch * difficulty: =&gt; Unknown Comment: The program works with this patch: {{{ diff --git a/rts/sm/GCUtils.c b/rts/sm/GCUtils.c index 996b5f6..97d07ea 100644 --- a/rts/sm/GCUtils.c +++ b/rts/sm/GCUtils.c &lt; at &gt;&lt; at &gt; -180,7 +180,7 &lt; at &gt;&lt; at &gt; todo_block_full (nat size, gen_workspace *ws) // the limit. if (!looksEmptyWSDeque(ws-&gt;todo_q) || (ws-&gt;todo_free - bd-&gt;u.scan &lt; WORK_UNIT_WORDS / 2)) { - if (ws-&gt;todo_free + size &lt; bd-&gt;start + bd-&gt;blocks * BLOCK_SIZE_W) { + if (ws-&gt;todo_free + size &lt;= bd-&gt;start + bd-&gt;blocks * BLOCK_SIZE_W) { ws-&gt;todo_lim = stg_min(bd-&gt;start + bd-&gt;blocks * BLOCK_SIZE_W, ws-&gt;todo_lim + stg_max(WORK_UNIT_WORDS,size)); debugTrace(DEBUG_gc, "increasing limit for %p to %p", bd-&gt;start, ws-&gt;todo_lim); }}} (note that the comment says "It cannot be empty, because then there would be enough room to copy the current object", but the comment and this guard don't agree when the size exactly fills the available space). I haven't looked at what exactly is going on, so want to check that this really looks right before committing, though. </pre> GHC 2013-05-17T21:27:30 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43351 <pre>#7919: Heap corruption (segfault) from large 'let' expression --------------------------+------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.6.3 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime crash | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- Changes (by kosmikus): * cc: mail&lt; at &gt;… (added) </pre> GHC 2013-05-17T20:46:04 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43350 <pre>#7919: Heap corruption (segfault) from large 'let' expression --------------------------+------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.6.3 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime crash | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- The attached test program reliably triggers an assertion in the storage manager with the `-debug` rts. {{{ LargeUse: internal error: ASSERTION FAILED: file rts/sm/GCUtils.c, line 208 (GHC version 7.6.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This behaviour is reproducible with many recent ghc versions (tried 7.6.3, 7.4.2, 6.12.3) and all fail at the same assertion when using the `-debug` rts. (Without `-debug` we get a more random variety of segfaults and GC errors.) It looks like a pretty clear case of heap corruption. I'll explain why... The test program uses TH to generate a program that looks like this: {{{ data Large = Large Int Int ... -- 512 non-strict Int fields test = let step (Large i1 i2 ... i512) = let j1 = i1 + i4 j2 = i2 + i7 ... j511 = i511 + i510 j512 = i512 + i1 in Large j1 j2 ... j512 in runSteps step 100000 (Large 1 1 ... 1) -- basically an unfoldr: runSteps :: (state -&gt; (state, Int)) -&gt; Int -&gt; state -&gt; [Int] runSteps f n i | n &lt;= 0 = [] | otherwise = case f i of (i', r) -&gt; r : runSteps f (n - 1) i' }}} We use TH to generate this program, and we use a "size" parameter that determines size of the data constructor (and corresponding letrec). This makes it easy to find the size threshold where it fails. For small sizes this program works fine, and for larger values it triggers the assert. With ghc 7.6.3 on a x86-64 machine, the magic threshold is 511: that is, the program works fine with size 510 and hits the assertion at size 511. This is suspiciously close to 512. And of course on a 64bit machine 512 * 8 is 4k, which is the storage manager's block size. And the failing assertion is in a bit of the storage manager that is dealing with blocks... {{{ // If this block does not have enough space to allocate the // current object, but it also doesn't have any work to push, then // push it on to the scanned list. It cannot be empty, because // then there would be enough room to copy the current object. if (bd-&gt;u.scan == bd-&gt;free) { ASSERT(bd-&gt;free != bd-&gt;start); push_scanned_block(bd, ws); } }}} So it looks very much like we have a situation where something is writing over the end of a block and messing up the SM's data structures. But, it is not nearly as simple as the data constructor being too big. We can demonstrate other programs that use much larger data constructors without any problem at all. Our suspicion falls on the big letrec. Indeed with this program if we change the data constructor to have strict fields then it no longer fails, and we can run it with much larger data constructor sizes. What would be different between strict and non-strict fields here? Well, one observation is that when it is strict then ghc can (and does) turn the code into a big cascade of case expressions, while when it is non-strict then the STG code is all 'let's. {{{ case tpl_s6jQ of tpl_s6Ak { __DEFAULT -&gt; case tpl_s6jS of tpl_s6Al { __DEFAULT -&gt; case tpl_s6jU of tpl_s6Am { -- etc for all 500+ elements }}} versus {{{ let { sat_s5UK :: GHC.Types.Int [LclId] = \u [] GHC.Num.$fNumInt_$c+ i511_s5Ly i1_s5E9; } in let { sat_s62X :: GHC.Types.Int [LclId] = \u [] GHC.Num.$fNumInt_$c+ i510_s5R2 i509_s5UG; } in let { sat_s62W :: GHC.Types.Int [LclId] = \u [] GHC.Num.$fNumInt_$c+ i509_s5UG i506_s5UC; } in -- etc for all 500+ elements }}} Note also, that it is nothing to do with the obvious space leak here. If we modify the code to generate an NFData instance and to use deepseq at each iteration then we eliminate the space leak, but we keep the big stg 'let', and it still fails. </pre> GHC 2013-05-17T20:31:16 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43349 <pre>#7916: PolyKinds without type signatures ----------------------------------------+----------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHC rejects valid program Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ----------------------------------------+----------------------------------- Changes (by simonpj): * difficulty: =&gt; Unknown Comment: Crumbs. Absolutely right. Your example identifies a real bug in the quantification over kinds. I've spent part of today fixing it, happily by simplifying the type inference engine! Patch coming, but not till Monday. </pre> GHC 2013-05-17T16:30:00 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43348 <pre>#7918: SrcSpan's associated with expanded quasi-quotes are inconsistent -----------------------------+---------------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Consider {{{ {-# LANGUAGE TemplateHaskell #-} module A where import Language.Haskell.TH.Quote qq = QuasiQuoter { quoteExp = \str -&gt; case str of "a" -&gt; [| True |] "b" -&gt; [| id True |] "c" -&gt; [| True || False |] "d" -&gt; [| False |] , quotePat = undefined , quoteType = undefined , quoteDec = undefined } {-# LANGUAGE QuasiQuotes #-} module B where import A ex1 = [qq|a|] ex2 = [qq|b|] ex3 = [qq|c|] ex4 = [qq|d|] }}} In the expansion of `[qq|a|]` the source span for `True` is reported as 4:7-4:14 and 7:7-7:14 respectively -- i.e., the span of the entire quasi- quote. However, for the expansion of `[qq|b|]` and `[qq|c|]` the source span for `id`, `True`, `False`, and `(||)` are all reported as 5:11-5:14 / 6:11-6:14, i.e., starting at the "contents" of the quasi-quote. </pre> GHC 2013-05-17T14:24:38 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43347 <pre>#7917: update documentation of InstalledPackageInfo -----------------------------+---------------------------------------------- Reporter: Lemming | Owner: Type: task | Status: new Priority: normal | Component: Documentation Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- When writing a binding to a foreign package that does not support pkg- config, it seems to be essential to know what the fields of InstalledPackageInfo precisely mean. I find the current description in section 4.9.8 of the GHC doc too short. What does extra-ghci-libraries mean? It is undocumented. In which field I should list shared objects? In which field I should enumerate static link libraries? Which libraries are used when compiling with -dynamic option and which ones are used for static linking? Are the library paths used both for static and dynamic link libraries? Which fields affect compilation of included C files? Which fields affect GHCi and which ones affect GHC? </pre> GHC 2013-05-17T12:07:36 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43346 <pre>#7898: SpecConstr explodes when compiling module BSP of frag-1.1.2 ---------------------------------+------------------------------------------ Reporter: tinctorius | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Compile-time crash Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: =&gt; Unknown Comment: Amos, it sounds as if you are onto something! Great. If you can boil it down to something I can reproduce without massive heroics, and if you are stuck, I'll willingly take a look. Simon </pre> GHC 2013-05-17T07:46:44 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43345 <pre>#7898: SpecConstr explodes when compiling module BSP of frag-1.1.2 -------------------------------+-------------------------------------------- Reporter: tinctorius | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by amosrobinson): Haha! if you remove the export list is compiles immediately! </pre> GHC 2013-05-17T01:03:31 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43344 <pre>#7898: SpecConstr explodes when compiling module BSP of frag-1.1.2 -------------------------------+-------------------------------------------- Reporter: tinctorius | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by amosrobinson): This is strange. I managed to get OpenGL to install on head (had to comment out the Typeable instances). Head still has the same blowup problem. Then I split BSP into two modules: reading and rendering. Then, bizarrely, neither of those modules blew up. I don't understand how splitting it into two modules could stop specialisation from happening, but it seems to. Same behaviour on head &amp; 7.4.2. I'm going to try selectively removing/undefining parts of the original BSP until I get something small enough that still blows up but the core is readable. </pre> GHC 2013-05-17T00:57:49 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43343 <pre>#7916: PolyKinds without type signatures --------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- Consider {{{ {-# LANGUAGE PolyKinds, ExplicitForAll #-} f :: forall (m :: k -&gt; *) (a :: k). m a -&gt; m a f = id g = f }}} I would expect GHC to infer the same type for `g` as for `f`. However, it gives the AnyK kind, and `g` is not possible to use: {{{ ghci -Wall X.hs ... X.hs:5:1: Warning: Top-level binding with no type signature: g :: forall (m :: AnyK -&gt; *) (a :: AnyK). m a -&gt; m a Ok, modules loaded: Main. *Main&gt; g "a" &lt;interactive&gt;:2:1: Kind incompatibility when matching types: a0 :: AnyK Char :: * In the first argument of ‛print’, namely ‛it’ In a stmt of an interactive GHCi command: print it }}} </pre> GHC 2013-05-16T17:30:36 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43342 <pre>#7915: Documentation uses deprecated record GADT syntax --------------------------------+------------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Documentation bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- Comment(by krz.gogolewski&lt; at &gt;…): commit 9fc2778cf20990524b13705a519b0c337ad197fe {{{ Author: Krzysztof Gogolewski &lt;krz.gogolewski&lt; at &gt;gmail.com&gt; Date: Thu May 16 15:54:59 2013 +0200 Documentation: use new syntax for record GADTs (#7915) docs/users_guide/glasgow_exts.xml | 33 ++++++++++++++++----------------- 1 files changed, 16 insertions(+), 17 deletions(-) }}} </pre> GHC 2013-05-16T16:19:44 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43341 <pre>#7915: Documentation uses deprecated record GADT syntax --------------------------------+------------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Documentation bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- Changes (by simonpj): * status: patch =&gt; closed * difficulty: =&gt; Unknown * resolution: =&gt; fixed Comment: Thank you! I've pushed it. Simon </pre> GHC 2013-05-16T16:19:44 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43340 <pre>#7915: Documentation uses deprecated record GADT syntax ------------------------------+--------------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: patch Priority: normal | Component: Documentation Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Documentation bug | Blockedby: Blocking: | Related: ------------------------------+--------------------------------------------- Changes (by monoidal): * status: new =&gt; patch </pre> GHC 2013-05-16T13:57:33 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43339 <pre>#7915: Documentation uses deprecated record GADT syntax ------------------------------+--------------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Documentation bug | Blockedby: Blocking: | Related: ------------------------------+--------------------------------------------- Trivial patch attached. </pre> GHC 2013-05-16T13:52:32 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43338 <pre>#7268: Explicit type signatures for top level record pattern matches polymorphism fail ---------------------------------------------+------------------------------ Reporter: TristanAllwood | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.4.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Difficulty: Unknown Testcase: typecheck/should_compile/T7268 | Blockedby: Blocking: | Related: ---------------------------------------------+------------------------------ Changes (by simonpj): * status: new =&gt; closed * resolution: =&gt; fixed Comment: I'm glad it's helpful. Thanks for pointing out the bug in the regression test...I've just pushed a fix. Simon </pre> GHC 2013-05-16T11:14:41 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43337 <pre>#7268: Explicit type signatures for top level record pattern matches polymorphism fail ---------------------------------------------+------------------------------ Reporter: TristanAllwood | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.4.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Difficulty: Unknown Testcase: typecheck/should_compile/T7268 | Blockedby: Blocking: | Related: ---------------------------------------------+------------------------------ Changes (by MartijnVanSteenbergen): * owner: simonpj =&gt; * status: closed =&gt; new * resolution: fixed =&gt; Comment: Hi Simon, looking at testcase T7891, wouldn't it be better to uncomment line 12 so that it becomes an actual regression test? </pre> GHC 2013-05-16T09:44:26 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43336 <pre>#7268: Explicit type signatures for top level record pattern matches polymorphism fail ---------------------------------------------+------------------------------ Reporter: TristanAllwood | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.4.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Difficulty: Unknown Testcase: typecheck/should_compile/T7268 | Blockedby: Blocking: | Related: ---------------------------------------------+------------------------------ Comment(by MartijnVanSteenbergen): I'm really happy with this fix, thank you very much! </pre> GHC 2013-05-16T09:36:48 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43335 <pre>#7892: GHC accepts multiple conflicting kind signatures in type class declarations ------------------------------------------+--------------------------------- Reporter: MartijnVanSteenbergen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Difficulty: Unknown Testcase: typecheck/should_fail/T7892 | Blockedby: Blocking: | Related: ------------------------------------------+--------------------------------- Comment(by MartijnVanSteenbergen): Excellent, thank you! </pre> GHC 2013-05-16T09:35:01 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.haskell.glasgow.bugs