diff options
| author | Sergei Trofimovich <slyfox@community.haskell.org> | 2010-07-09 11:59:17 +0000 |
|---|---|---|
| committer | Sergei Trofimovich <slyfox@community.haskell.org> | 2010-07-09 11:59:17 +0000 |
| commit | d12690d5995de055d7e9b8ed04946bbb609b6e98 (patch) | |
| tree | 9ddc3c6c64e9ced9a94118a8196259688ac9a2e1 /includes | |
| parent | 615d88d1912a81ca3bef44010285424f6c454449 (diff) | |
| download | haskell-d12690d5995de055d7e9b8ed04946bbb609b6e98.tar.gz | |
* storage manager: preserve upper address bits on 64bit machines (thanks to zygoloid)
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!
Diffstat (limited to 'includes')
| -rw-r--r-- | includes/rts/storage/MBlock.h | 12 |
1 files changed, 11 insertions, 1 deletions
diff --git a/includes/rts/storage/MBlock.h b/includes/rts/storage/MBlock.h index 0943d4cec3..739ac6852a 100644 --- a/includes/rts/storage/MBlock.h +++ b/includes/rts/storage/MBlock.h @@ -126,7 +126,17 @@ extern StgWord8 mblock_map[]; #define MBC_LINE_BITS 0 #define MBC_TAG_BITS 15 -typedef StgWord32 MbcCacheLine; // could use 16, but 32 was faster + +#if x86_64_HOST_ARCH +// 32bits are enough for 'entry' as modern amd64 boxes have +// only 48bit sized virtual addres. +typedef StgWord32 MbcCacheLine; +#else +// 32bits is not enough here as some arches (like ia64) use +// upper address bits to distinct memory areas. +typedef StgWord64 MbcCacheLine; +#endif + typedef StgWord8 MBlockMapLine; #define MBLOCK_MAP_LINE(p) (((StgWord)p & 0xffffffff) >> (MBLOCK_SHIFT + MBC_LINE_BITS)) |