- ghc-devs - Haskell.org

Re: [GHC] #8736: GHCi doesn't load .dyn_o files appropriately
by George Colpitts 31 May '14

31 May '14

Please ignore my previous message, I was compiling with -DYNAMIC instead of -dynamic On Sat, May 31, 2014 at 12:39 PM, GHC <ghc-devs(a)haskell.org> wrote: > #8736: GHCi doesn't load .dyn_o files appropriately > -------------------------------------+------------------------------------ > Reporter: thoughtpolice | Owner: thoughtpolice > Type: bug | Status: new > Priority: high | Milestone: 7.8.3 > Component: Compiler | Version: 7.8.1-rc2 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: Unknown/Multiple > Type of failure: None/Unknown | Difficulty: Unknown > Test Case: | Blocked By: > Blocking: | Related Tickets: > -------------------------------------+------------------------------------ > > Comment (by George): > > Replying to [comment:4 simonpj]: > > Summarising the behaviour. If you say `:load Foo` in GHCi > > * `Foo` was compiled with `-dynamic`: loads `Foo.o` > > * `Foo` was compiled without any dynamic flag: does not find object > files, so interprets. > > * `Foo` was compiled with `-dynamic-too`: fails as above. > > > > Not a release blocker. > > > > The first case > > > * `Foo` was compiled with `-dynamic`: loads `Foo.o` > > does not seem to be the case in 7.8.2, at least on the Mac where the .o > file does not get loaded > > {{{ > ghc --make -O2 -DYNAMIC pfp1.hs > [1 of 1] Compiling Main ( pfp1.hs, pfp1.o ) > Linking pfp1 ... > bash-3.2$ ghci -ignore-dot-ghci > GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Prelude> :load pfp1 > [1 of 1] Compiling Main ( pfp1.hs, interpreted ) > Ok, modules loaded: Main. > }}} > > Should I file a bug? > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8736#comment:9> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

segfault in RTS - can anyone help me tracking this bug down?
by Ömer Sinan Ağacan 30 May '14

30 May '14

Hi all, I'm suffering from a RTS bug(probably GC related) that makes making progress in my GSoC project impossible. I have very limited knowledge of GHC internals and I currently have no idea how to produce a minimal program that demonstrates the bug. I wrote how to reproduce it and gdb backtrace when segfault happens in a short blog post: http://osa1.net/posts/2014-05-27-worst-bug.html . As also written in the blog post, changing generation count of generational GC will makes the bug disappear in some cases, but it's not a solution. I also pasted backtrace output below for those who don't want to click links. GHC version used is 7.8.2. If anyone give me some pointers to understand what's going wrong or how can I produce a simple program that demonstrates the bug, I'd like to work on that. I'm basically stuck and I can't make any progress with this bug. Thanks, Ömer [ 5 of 202] Compiling GHC.Unicode[boot] ( GHC/Unicode.hs-boot, dist/build/GHC/Unicode.js_p_o-boot ) Detaching after fork from child process 3382. [ 6 of 202] Compiling GHC.IO[boot] ( GHC/IO.hs-boot, dist/build/GHC/IO.js_p_o-boot ) Detaching after fork from child process 3383. [ 7 of 202] Compiling GHC.Exception[boot] ( GHC/Exception.lhs-boot, dist/build/GHC/Exception.js_p_o-boot ) Detaching after fork from child process 3384. [ 51 of 202] Compiling GHC.Fingerprint[boot] ( GHC/Fingerprint.hs-boot, dist/build/GHC/Fingerprint.js_p_o-boot ) Detaching after fork from child process 3385. [ 55 of 202] Compiling GHC.IO.Exception[boot] ( GHC/IO/Exception.hs-boot, dist/build/GHC/IO/Exception.js_p_o-boot ) Detaching after fork from child process 3386. [ 75 of 202] Compiling Foreign.C.Types ( Foreign/C/Types.hs, dist/build/Foreign/C/Types.js_p_o ) Program received signal SIGSEGV, Segmentation fault. 0x000000000425d5c4 in LOOKS_LIKE_CLOSURE_PTR (p=0x0) at includes/rts/storage/ClosureMacros.h:258 258 includes/rts/storage/ClosureMacros.h: No such file or directory. (gdb) bt #0 0x000000000425d5c4 in LOOKS_LIKE_CLOSURE_PTR (p=0x0) at includes/rts/storage/ClosureMacros.h:258 #1 0x000000000425f776 in scavenge_mutable_list1 (bd=0x7fffe5c02a00, gen=0x4d1fd48) at rts/sm/Scav.c:1400 #2 0x000000000425fa13 in scavenge_capability_mut_Lists1 (cap=0x4cfe5c0 <MainCapability>) at rts/sm/Scav.c:1493 #3 0x0000000004256b66 in GarbageCollect (collect_gen=0, do_heap_census=rtsFalse, gc_type=2, cap=0x4cfe5c0 <MainCapability>) at rts/sm/GC.c:342 #4 0x00000000042454a3 in scheduleDoGC (pcap=0x7fffffffc198, task=0x4d32b60, force_major=rtsFalse) at rts/Schedule.c:1650 #5 0x0000000004243de4 in schedule (initialCapability=0x4cfe5c0 <MainCapability>, task=0x4d32b60) at rts/Schedule.c:553 #6 0x0000000004246436 in scheduleWaitThread (tso=0x7ffff6708d60, ret=0x0, pcap=0x7fffffffc2c0) at rts/Schedule.c:2346 #7 0x000000000423e9b4 in rts_evalLazyIO (cap=0x7fffffffc2c0, p=0x477f850, ret=0x0) at rts/RtsAPI.c:500 #8 0x0000000004241666 in real_main () at rts/RtsMain.c:63 #9 0x0000000004241759 in hs_main (argc=237, argv=0x7fffffffc448, main_closure=0x477f850, rts_config=...) at rts/RtsMain.c:114 #10 0x0000000000408ea7 in main ()

5 8

RE: [GHC] #9153: TcCoercible test is failing with context reduction stack overflow
by Simon Peyton Jones 30 May '14

30 May '14

Thanks for this. I've improved Note [Order of Coercible Instances] in TcInteract Generally, it's much better to give an actual, concrete example in the Note, and refer to the ticket for additional background. It took me a few minutes to re-read the long #9117 to reconstruct the example that precisely illustrates the Note. Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | GHC | Sent: 30 May 2014 01:35 | Cc: ghc-tickets(a)haskell.org | Subject: [GHC] #9153: TcCoercible test is failing with context reduction | stack overflow | | #9153: TcCoercible test is failing with context reduction stack overflow | ------------------------------------+----------------------------------- | ------------------------------------+-- | Reporter: ezyang | Owner: | Type: bug | Status: new | Priority: low | Milestone: | Component: Test Suite | Version: 7.9 | Keywords: | Operating System: | Unknown/Multiple | Architecture: Unknown/Multiple | Type of failure: None/Unknown | Difficulty: Unknown | Test Case: | Blocked By: | Blocking: | Related Tickets: | | ------------------------------------+----------------------------------- | ------------------------------------+-- | Here is the error: | | {{{ | TcCoercible.hs:62:12: | Context reduction stack overflow; size = 21 | Use -fcontext-stack=N to increase stack size to N | Coercible Int Int | In the expression: coerce | In the first argument of ‘print’, namely | ‘(coerce $ (FixEither (Left age) :: FixEither Age) :: | Either Int (FixEither Int))’ | In a stmt of a 'do' block: | print | (coerce $ (FixEither (Left age) :: FixEither Age) :: | Either Int (FixEither Int)) | }}} | | I do not know enough to know if bumping the stack size is correct. | | Additionally, when run as GHCi I get: | | {{{ | =====> TcCoercible(ghci) 2784 of 3970 [0, 7, 0] cd | ./typecheck/should_run && '/home/hs01/ezyang/ghc-validate/inplace/bin | /ghc-stage2' -fforce-re | comp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db - | rtsopts -fno-ghci-history Tc Coercible.hs --interactive -v0 -ignore- | dot-ghci +RTS -I0.1 -RTS <TcCoercible.genscript 1>TcCo | ercible.interp.stdout 2>TcCoercible.interp.stderr Actual stderr output | differs from expected: | --- /dev/null 2014-02-15 17:35:19.578872448 -0800 | +++ ./typecheck/should_run/TcCoercible.run.stderr 2014-05-29 | 16:27:30.476701835 -0700 | @@ -0,0 +1,2 @@ | + | +TcCoercible:7:30: Not in scope: ‘Main.main’ | }}} | | -- | Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9153> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-tickets

2 1

NondecreasingIndentation (& de-tabbing several .hs files)
by Herbert Valerio Riedel 29 May '14

29 May '14

Hello GHC devs, While I refactored the ghc code base to declare LANGUAGE pragmas locally, rather than via -X-flags on the GHC commandline, I've noticed there were a couple of places where NondecreasingIndentation grammar was used. What's the current consensus on the use of NondecreasingIndentation? Is its use still encouraged? ---- Moreover, I touched several files (over 300) while refactoring, would that qualify as "working on this module" in the sense of | While working on this module you are encouraged to remove it and detab | the module (please do the detabbing in a separate patch). or would that overreach wrt the original intent of the guideline quoted above? Cheers, hvr

4 7

Parallelizing the Weak Pointer Lock
by Edward Kmett 29 May '14

29 May '14

How hard *would* it be to replace the global weak pointer lock with something that scales better? I'm looking at switching some of my older BDD code into Haskell. To do so I'd love to be able to use an "intuitive" weak-pointer based cache management scheme, but I have to confess the notion of a global lock getting in the way basically damns whatever solution I come up with to be a single-threaded toy. =/ If I'm trying to sell Haskell's parallelism to others, it seems my only winning moves right now are: 1.) play less satisfying games with typed regions, which scale less well than the tried and tested solutions of GCing hash-consed BDD structures. 2.) just tackle the problem that allocating a weak pointer grabs a global lock. 3.) not to play the game -Edward

4 4

Ghc 7.8 branch broken
by Simon Peyton Jones 27 May '14

27 May '14

Austin, the ghc-7.8 branch does not build. See below. Simon inplace/bin/mkUserGuidePart docs/users_guide/users_guide.xml inplace/bin/mkUserGuidePart docs/users_guide/what_glasgow_exts_does.gen.xml "rm" -rf docs/users_guide/users_guide/ "/usr/bin/xsltproc" --stringparam base.dir docs/users_guide/users_guide/ --stringparam use.id.as.filename 1 --stringparam html.stylesheet fptools.css --nonet --stringparam toc.section.depth 3 --stringparam section.autolabel 1 --stringparam section.label.includes.component.label 1 http://docbook.sourceforge.net/release/xsl/current/html/chunk.xsl docs/users_guide/users_guide.xml docs/users_guide/intro.xml:312: parser error : Entity 'relnotes3' not defined &relnotes3; ^ docs/users_guide/intro.xml:321: parser error : chunk is not well balanced ^ docs/users_guide/ug-book.xml:11: parser error : Failure to process entity intro &intro; ^ docs/users_guide/ug-book.xml:11: parser error : Entity 'intro' not defined &intro; ^ docs/users_guide/users_guide.xml:10: parser error : Failure to process entity ug-book &ug-book; ^ docs/users_guide/users_guide.xml:10: parser error : Entity 'ug-book' not defined &ug-book; ^ unable to parse docs/users_guide/users_guide.xml "cp" -p ghc/stage2/build/tmp/ghc-stage2 inplace/lib/bin/ghc-stage2 make[1]: *** [docs/users_guide/users_guide/index.html] Error 6 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 simonpj@cam-05-unx:~/5builds/ghc-7.8-branch$

4 5

Re: GHC 7.8.3 release
by Johan Tibell 27 May '14

27 May '14

I would say "sooner". Here are still unmerged things that I think we could merge before (i.e. easy to merge): https://ghc.haskell.org/trac/ghc/ticket/9001 https://ghc.haskell.org/trac/ghc/ticket/9078 https://ghc.haskell.org/trac/ghc/ticket/8475 https://ghc.haskell.org/trac/ghc/ticket/8783 https://ghc.haskell.org/trac/ghc/ticket/9068

2 2

Weak reference semantics - why does a dead weak ref keep its value alive?
by Luite Stegeman 27 May '14

27 May '14

Hi all, I'm reviewing and improving my weak references implementation for GHCJS, among other things to make sure that the profiling/stack trace support, currently being implemented by Ömer Sinan Ağacan as a GSoC project has the correct heap information to work with. JavaScript does not have weak references with 'observable deadness', so we have to walk the heap data structures from time to time to test reachability, schedule finalizers and break the weak links. I'm trying to find a design that keeps GHC's semantics, but where JavaScript's own garbage collector can get rid of as much data as possible, even before we run our own heap scan. Now I ran into the following peculiarity, from the semantics (System.Mem.Weak documentation): A heap object is reachable if: - It is a member of the root set. - It is directly pointed to by a reachable object, other than a weak pointer object. - It is a weak pointer object whose key is reachable. - It is the value or finalizer of a weak pointer object whose key is reachable. This says that even if nothing has a reference to a weak pointer, as long as there are references to its key, the value is considered to be reachable. For example in this program import Data.Maybe import System.Mem.Weak import System.Mem import Control.Exception import System.IO import Control.Concurrent gc = performGC >> threadDelay 1000000 main = do hSetBuffering stdout NoBuffering k <- evaluate "k" v <- evaluate "v" addFinalizer v (putStrLn "fv") w <- evaluate =<< mkWeak k v (Just $ putStrLn "fkv") putStrLn =<< fmap (fromMaybe ".") (deRefWeak w) addFinalizer w (putStrLn "fw") gc putStrLn k gc there is no way to reach 'v' after `w` has been finalized, but still it's kept alive. This agrees with the semantics in the documentation, but what's the reason for this? luite

3 4

Constructing coercions for associated type?
by Conal Elliott 25 May '14

25 May '14

I'm working on a GHC plugin in which I need to programmatically construct a coercion for an associated type, given the type function name and the type argument. For instance, I have the following class: > class Encodable a where > type Encode a > encode :: a -> Encode a > decode :: Encode a -> a along with a type instance, say `Int -> Bool`. In a GHC plugin, how can I apply a type function to an argument type to get back the resulting type and the associated coercion? (Given the latter, I think the former comes from `coercionKind`). -- Conal

2 2

Haddock repo doesn't accept pushes?
by Dr. ERDI Gergo 25 May '14

25 May '14

Hi, I've just tried pushing a commit to the Haddock repo on git.haskell.org: 14:45:36 [cactus@galaxy haddock]$ git push -u origin HEAD Counting objects: 9, done. Delta compression using up to 4 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (5/5), 462 bytes | 0 bytes/s, done. Total 5 (delta 4), reused 0 (delta 0) remote: W refs/heads/master haddock gergo DENIED by refs/.* remote: error: hook declined to update refs/heads/master To ssh://git@git.haskell.org/haddock.git ! [remote rejected] HEAD -> master (hook declined) error: failed to push some refs to 'ssh://git@git.haskell.org/haddock.git' So, OK, maybe I don't remember correctly and I can't push to master, let's push to my branch so that I can ask someone to move it over: 14:46:47 [cactus@galaxy haddock]$ git push --force -u origin HEAD:wip/pattern-synonyms Counting objects: 9, done. Delta compression using up to 4 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (5/5), 462 bytes | 0 bytes/s, done. Total 5 (delta 4), reused 0 (delta 0) remote: + refs/heads/wip/pattern-synonyms haddock gergo DENIED by refs/.* remote: error: hook declined to update refs/heads/wip/pattern-synonyms To ssh://git@git.haskell.org/haddock.git ! [remote rejected] HEAD -> wip/pattern-synonyms (hook declined) error: failed to push some refs to 'ssh://git@git.haskell.org/haddock.git' I could try merging origin/master into the existing wip/pattern-synonyms branch but there wouldn't be much point in resolving all the merge conflicts, since my local branch (which is just one commit on top of origin/master) is already exactly what I'd want to push to master. So how do I get my commit (which is needed for a patch to GHC proper) into the Haddock repo? Thanks, Gergo

2 2