- ghc-tickets - Haskell.org

Re: [GHC] #5909: Segfault with multi-threaded retainer profiling
by GHC 07 Feb '13

07 Feb '13

#5909: Segfault with multi-threaded retainer profiling -------------------------------+-------------------------------------------- Reporter: akio | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.6.2 Component: Runtime System | Version: 7.4.1 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------------+-------------------------------------------- Comment(by simonmar): Interesting, thanks for the patch, I'll take a look. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5909#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5909: Segfault with multi-threaded retainer profiling
by GHC 07 Feb '13

07 Feb '13

#5909: Segfault with multi-threaded retainer profiling -------------------------------+-------------------------------------------- Reporter: akio | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.6.2 Component: Runtime System | Version: 7.4.1 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------------+-------------------------------------------- Changes (by akio): * status: new => patch Comment: I think I have found a bug. Segfaults often happen in the isMember function in rts/RetainerSet.h. It gets a segfault when tries to dereference rs, whose value is 0x4 or 0x6: {{{ (gdb) run aaaaaaaaaaaaaaaaaaaaaaa +RTS -hr -N5 -V -A512K Starting program: /home/akio/src/test/segfault aaaaaaaaaaaaaaaaaaaaaaa +RTS -hr -N5 -V -A512K [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff6acd700 (LWP 14398)] [New Thread 0x7ffff62cc700 (LWP 14399)] [New Thread 0x7fffe7fff700 (LWP 14400)] [New Thread 0x7fffeffff700 (LWP 14401)] [New Thread 0x7ffff56ff700 (LWP 14402)] [New Thread 0x7ffff4efe700 (LWP 14403)] Program received signal SIGSEGV, Segmentation fault. isMember (rs=<optimized out>, r=0xd46640) at rts/RetainerSet.h:140 140 if (rs->num < BINARY_SEARCH_THRESHOLD) { (gdb) bt #0 isMember (rs=<optimized out>, r=0xd46640) at rts/RetainerSet.h:140 #1 retainClosure (c0=<optimized out>, cp0=<optimized out>, r0=<optimized out>) at rts/RetainerProfile.c:1625 #2 0x0000000000946c4e in retain_PAP_payload (pap=0x7ffff5768190, c_child_r=0xd46640, fun=<optimized out>, payload=0x7ffff57681b8, n_args=1) at rts/RetainerProfile.c:1413 #3 0x0000000000946674 in retainClosure (c0=<optimized out>, cp0=<optimized out>, r0=<optimized out>) at rts/RetainerProfile.c:1686 #4 0x0000000000951e4f in markStablePtrTable (evac=0x946a60 <retainRoot>, user=0x0) at rts/Stable.c:364 #5 0x00000000009471b5 in computeRetainerSet () at rts/RetainerProfile.c:1775 #6 retainerProfile () at rts/RetainerProfile.c:1979 #7 0x0000000000943be0 in heapCensus (t=<optimized out>) at rts/ProfHeap.c:1086 #8 0x000000000095bd0a in GarbageCollect (collect_gen=<optimized out>, do_heap_census=rtsTrue, gc_type=<optimized out>, cap=0xd57240) at rts/sm/GC.c:735 #9 0x000000000094e7a8 in scheduleDoGC (pcap=<optimized out>, task=0xdc7740, force_major=rtsFalse) at rts/Schedule.c:1643 #10 0x000000000094f4b2 in schedule (initialCapability=<optimized out>, task=0xdc7740) at rts/Schedule.c:553 #11 0x0000000000950a15 in scheduleWaitThread (tso=<optimized out>, ret=<optimized out>, pcap=0x7fffffffe040) at rts/Schedule.c:2345 #12 0x00000000009498ee in real_main () at rts/RtsMain.c:63 #13 0x00000000009499ea in hs_main (argc=7, argv=0x7fffffffe1a8, main_closure=0xcb99b0, rts_config=...) at rts/RtsMain.c:114 #14 0x0000000000407f47 in main () (gdb) f 1 #1 retainClosure (c0=<optimized out>, cp0=<optimized out>, r0=<optimized out>) at rts/RetainerProfile.c:1625 1625 if (isMember(r, retainerSetOfc)) (gdb) p c->header.prof.hp $4 = {rs = 0x5, ldvw = 5} (gdb) p flip $5 = 1 }}} The attached patch seems to fix this. Probably it can be made more efficient by using the fact that biographical profiling and retainer profiling are never turned on at the same time, but I'm not sure exactly how it should be implemented. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5909#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7480: Proposal: Add Functor instances for ArgOrder, OptDescr and ArgDescr
by GHC 07 Feb '13

07 Feb '13

#7480: Proposal: Add Functor instances for ArgOrder, OptDescr and ArgDescr -----------------------------+---------------------------------------------- Reporter: basvandijk | Owner: Type: feature request | Status: patch Priority: normal | Component: libraries/base Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Changes (by monoidal): * status: new => patch -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7480#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7663: consider free variables as well as parameters in inline discounts
by GHC 06 Feb '13

06 Feb '13

#7663: consider free variables as well as parameters in inline discounts -----------------------------+---------------------------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The inliner assigns discount values for scrutinized parameters but not for scrutinized free variables. Experimenting with an aggressive lambda float at the end of the core2core pipeline identified a situation where (effectively) assigning discounts to free variables gives a performance boost. (The free variables become parameters during the float and hence are then assigned discounts.) For spectral/boyer2, doing the late lambda float and then simplifying results in a -7% improvement in allocation. Without the simplifications, the late lambda float alone does not change allocation: thus the lion's share of the -7% could be attained simply by assigning discounts to scrutinized free variables. For reference: the function in boyer2 that gets inlined is a join point that arises near the top of the worker for "Rewritefns.onewayunify". -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7663> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7664: consider free variables as well as parameters in inline discounts
by GHC 06 Feb '13

06 Feb '13

#7664: consider free variables as well as parameters in inline discounts -----------------------------+---------------------------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The inliner assigns discount values for scrutinized parameters but not for scrutinized free variables. Experimenting with an aggressive lambda float at the end of the core2core pipeline identified a situation where (effectively) assigning discounts to free variables gives a performance boost. (The free variables become parameters during the float and hence are then assigned discounts.) For spectral/boyer2, doing the late lambda float and then simplifying results in a -7% improvement in allocation. Without the simplifications, the late lambda float alone does not change allocation: thus the lion's share of the -7% could be attained simply by assigning discounts to scrutinized free variables. For reference: the function in boyer2 that gets inlined is a join point that arises near the top of the worker for "Rewritefns.onewayunify". -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7664> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #3781: Improve inlining for local functions
by GHC 06 Feb '13

06 Feb '13

#3781: Improve inlining for local functions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.12.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by nfrisby): For the record, we re-discovered this while investigating a late lambda float. If we move forward with that, it would partially achieve the functionality of discounting FVs, as discussed in #7664 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3781#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3990: UNPACK doesn't unbox data families
by GHC 06 Feb '13

06 Feb '13

#3990: UNPACK doesn't unbox data families ---------------------------------+------------------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: See #7647 re polymorphic unpacking. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3990#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7657: "unsafePerfromIO" typo in Safe Haskell user's guide
by GHC 06 Feb '13

06 Feb '13

#7657: "unsafePerfromIO" typo in Safe Haskell user's guide ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Documentation bug | Blockedby: Blocking: | Related: ------------------------------+--------------------------------------------- In http://www.haskell.org/ghc/docs/7.6.2/html/users_guide/safe-haskell.html it says: > This includes disallowing `unsafePerfromIO` [...] It should say `unsafePerformIO` instead. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7657> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5793: make nofib awesome
by GHC 06 Feb '13

06 Feb '13

#5793: make nofib awesome --------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: _|_ Component: NoFib benchmark suite | Version: Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: 5794 Related: | --------------------------------------+------------------------------------- Description changed by dterei: Old description: > Nofib is the standard tool GHC developers use to benchmark changes to the > compiler. Its a known fact though that nofib sucks. Its overall design is > OK but it's had no love and care for many years and has bittrotted into > near uselessness in a lot of situations. > > This task isn't to implement an awesome, really useful benchmark suite > for Haskell. That would be great but is a huge undertaking. This task is > just about making nofib useful again. > > The breakdown for this is something like: > > 1. Think and maybe fix nofib framework design. It has 'ways' which I > think correspond to compilation method but more in the sense of 'dynamic' > vs 'static', seems it may not suite being able to use ways for 'fasm' vs > 'fllvm'. There is also the concept of 'modes' which corresponds to > different benchmark input. So 'normal' and 'slow' for getting different > run-times. At moment no easy way to select which benchmark groups to run, > so may want to change that. I guess we should just decide, what knobs do > we want to be able to easily tweak, and see how well the current design > allows that. > > 2. Fixup the runtimes for benchmarks to be significant. (A lot of them > run in < 1 or < 0.1 seconds). I think trying to get all of them to run in > around 10s is a good target. > > 3. Above task is to fix normal but we may want to fixup slow as well and > perhaps add a 'fast' mode where benchmarks run in around 1 second. > > 4. Maybe add more benchmarks to the suite (text, bytestring, performance > regressions from ghc testsuite, vector....) New description: Nofib is the standard tool GHC developers use to benchmark changes to the compiler. Its overall design is OK but it's had no love and care for many years and has bittrotted such that it isn't useful in a lot of situations. This task is about making nofib useful again. The breakdown for this is something like: 1. Think and maybe fix nofib framework design. It has 'ways' which I think correspond to compilation method but more in the sense of 'dynamic' vs 'static', seems it may not suite being able to use ways for 'fasm' vs 'fllvm'. There is also the concept of 'modes' which corresponds to different benchmark input. So 'normal' and 'slow' for getting different run-times. At moment no easy way to select which benchmark groups to run, so may want to change that. I guess we should just decide, what knobs do we want to be able to easily tweak, and see how well the current design allows that. 2. Fixup the runtimes for benchmarks to be significant. (A lot of them run in < 1 or < 0.1 seconds). I think trying to get all of them to run in around 10s is a good target. 3. Above task is to fix normal but we may want to fixup slow as well and perhaps add a 'fast' mode where benchmarks run in around 1 second. 4. Maybe add more benchmarks to the suite (text, bytestring, performance regressions from ghc testsuite, vector....) -- -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5793#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7639: Fix installation issues with cross compiling + honour Stage1Only properly
by GHC 05 Feb '13

05 Feb '13

#7639: Fix installation issues with cross compiling + honour Stage1Only properly ----------------------------------+----------------------------------------- Reporter: StephenBlackheath | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Installing GHC failed | Blockedby: Blocking: | Related: ----------------------------------+----------------------------------------- This patch fixes three problems that occur during a cross compile to embedded Linux (details below): 1. arm-ldu-linux-gnueabi-ghc-pkg gets a symlink but no wrapper script upon installation, and this causes the installation to break later when it tries to run it. 2. hp2ps doesn't get the prefix like the other commands do (i.e. arm-ldu- linux-gnueabi-ghc- is missing from the name of the executable). This is just for consistency. 3. The stage2 compiler is built when Stage1Only is set to YES (though it does not get installed). This makes the build take longer than it needs to. mk/build.mk: SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO INTEGER_LIBRARY = integer-simple Stage1Only = YES configure command: ./configure --target=arm-ldu-linux-gnueabi --prefix=/usr/local/ghc-ldu -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7639> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7