1. 20 Jul, 2010 2 commits
  2. 16 Jul, 2010 1 commit
    • Simon Marlow's avatar
      Use a separate mutex to protect all_tasks, avoiding a lock-order-reversal · ed301949
      Simon Marlow authored
      In GHC 6.12.x I found a rare deadlock caused by this
      AQ cap->lock
            AQ sched_mutex
        AQ sched_mutex
            AQ cap->lock
      so sched_mutex and cap->lock are taken in a different order in two
      This doesn't happen in the HEAD because we don't have
      scheduleCheckBlackHoles, but I thought it would be prudent to make
      this less likely to happen in the future by using a different mutex in
      newTask.  We can clearly see that the all_tasks mutex cannot be
      involved in a deadlock, becasue we never call anything else while
      holding it.
  3. 15 Jul, 2010 1 commit
  4. 19 Jul, 2010 2 commits
  5. 18 Jul, 2010 1 commit
  6. 15 Jul, 2010 1 commit
  7. 17 Jul, 2010 5 commits
  8. 16 Jul, 2010 6 commits
  9. 15 Jul, 2010 6 commits
  10. 14 Jul, 2010 4 commits
  11. 13 Jul, 2010 6 commits
  12. 07 Jul, 2010 2 commits
  13. 01 Jul, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Fix second bug in Trac #4127 · 2c183f9b
      simonpj@microsoft.com authored
      This bug concerned the awkward shadowing we do for 
      Template Haskell declaration brackets.  Lots of
      comments in 
        Note [Top-level Names in Template Haskell decl quotes]
  14. 09 Jul, 2010 2 commits
    • Sergei Trofimovich's avatar
      ia64: switch handling of 'foreign import wrapper' (FIW) to libffi · e025c94f
      Sergei Trofimovich authored
      I tried to build darcs-2.4.4 with ghc-6.12.3 and got coredumps when darcs is used
      in interactive mode. I tried test from ticket #3516 and found out FIW code is broken.
      Instead of fixing it I just switched to libffi. Result built successfully, passed
      'foreign import wrapper' test from ticket #3516 and builds working darcs.
    • Sergei Trofimovich's avatar
      * storage manager: preserve upper address bits on 64bit machines (thanks to zygoloid) · d12690d5
      Sergei Trofimovich authored
      Patch does not touch amd64 as it's address lengts is 48 bits at most, so amd64 is unaffected.
      the issue: during ia64 ghc bootstrap (both 6.10.4 and 6.12.3) I
      got the failure on stage2 phase:
          "inplace/bin/ghc-stage2"   -H32m -O -H64m -O0 -w ...
          ghc-stage2: internal error: evacuate: strange closure type 15
              (GHC version 6.12.3 for ia64_unknown_linux)
              Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
          make[1]: *** [libraries/dph/dph-base/dist-install/build/Data/Array/Parallel/Base/Hyperstrict.o] Aborted
      gdb backtrace (break on 'barf'):
      Breakpoint 1 at 0x400000000469ec31: file rts/RtsMessages.c, line 39.
      (gdb) run -B/var/tmp/portage/dev-lang/ghc-6.12.3/work/ghc-6.12.3/inplace/bin --info
      Starting program: /var/tmp/portage/dev-lang/ghc-6.12.3/work/ghc-6.12.3/inplace/lib/ghc-stage2 -B/var/tmp/portage/dev-lang/ghc-6.12.3/work/ghc-6.12.3/inplace/bin --info
      [Thread debugging using libthread_db enabled]
      Breakpoint 1, barf (s=0x40000000047915b0 "evacuate: strange closure type %d") at rts/RtsMessages.c:39
      39        va_start(ap,s);
      (gdb) bt
      #0  barf (s=0x40000000047915b0 "evacuate: strange closure type %d") at rts/RtsMessages.c:39
      #1  0x400000000474a1e0 in evacuate (p=0x6000000000147958) at rts/sm/Evac.c:756
      #2  0x40000000046d68c0 in scavenge_srt (srt=0x6000000000147958, srt_bitmap=7) at rts/sm/Scav.c:348
      > 16:52:53 < zygoloid> slyfox: i'm no ghc expert but it looks like HEAP_ALLOCED_GC(q)
      >                      is returning true for a FUN_STATIC closure
      > 17:18:43 < zygoloid> try: p HEAP_ALLOCED_miss((unsigned long)(*p) >> 20, *p)
      > 17:19:12 < slyfox> (gdb) p HEAP_ALLOCED_miss((unsigned long)(*p) >> 20, *p)
      > 17:19:12 < slyfox> $1 = 0
      > 17:19:40 < zygoloid> i /think/ that means the mblock_cache is broken
      > 17:22:45 < zygoloid> i can't help further. however i am suspicious that you seem to have pointers with similar-looking low 33
      >                      bits and different high 4 bits, and it looks like such pointers get put into the same bucket in
      >                      mblock_cache.
      > 17:36:16 < zygoloid> slyfox: try changing the definition of MbcCacheLine to StgWord64, see if that helps
      > 17:36:31 < zygoloid> that's in includes/rts/storage/MBlock.h
      And it helped!