Hi Michal, Yes I found exactly the same bug yesterday evening when I was rewriting the sanity checker (it now scans the heap linearly). The problem is simple, cinfo_alloc contained: if (obj){ zcon = (Node*)heap_alloc(wordsof(Node)); MAKE_NODE(zcon, cinfo, N_NORMAL); obj->node = zcon; obj->info = (Info*)cinfo; } which allocates a zero arity constructor node for the constructor (I just copy pased the code from finfo_alloc to allocate a CAF node). However, I forgot that not all constructors are zero arity and so not all need a zero arity node. So the code should read: if (obj){ if (cinfo->size == 0){ zcon = (Node*)heap_alloc(wordsof(Node)); MAKE_NODE(zcon, cinfo, N_NORMAL); obj->node = zcon; } obj->info = (Info*)cinfo; } I'll submit a patch shortly :-) Thanks very much for your efforts, it really has made my life easier :-) Tom Michał Pałka wrote:
Clarification
On Sat, 2006-03-11 at 22:58 +0100, Michał Pałka wrote:
Hackers,
I've managed to find more details concerning GC failure on AMD64. The heap node that causes GC to crash is allocated on modules loading: #0 cinfo_alloc (size=2, name=0x58a3e0 ":", number=1, flags=0, obj=0x58a360) at info.c:24 #1 0x0000000000403b0f in mod_loadCon (mod=0x52ccf0, name=0x58a3e0 ":", obj=0x58a360) at module.c:463 #2 0x0000000000403ccd in mod_loadObject (mod=0x52ccf0, offs=36277, obj=0x58a360) at module.c:516 #3 0x0000000000402a13 in mod_resolve (module=0x58a380 "Prelude", item=0x58a3a0 ":") at module.c:209 #4 0x0000000000402f0d in mod_loadConstTable (mod=0x588ea0, finfo=0x58a218) at module.c:322 #5 0x0000000000403a4b in mod_loadFun (mod=0x588ea0, name=0x58a1e0 "valid", obj=0x58a160) at module.c:439 #6 0x0000000000403cb4 in mod_loadObject (mod=0x588ea0, offs=1475, obj=0x58a160) at module.c:514 #7 0x0000000000402a13 in mod_resolve (module=0x58a180 "Main", item=0x58a1a0 "valid") at module.c:209 #8 0x0000000000402f0d in mod_loadConstTable (mod=0x588ea0, finfo=0x58a0f0) at module.c:322 #9 0x0000000000403a4b in mod_loadFun (mod=0x588ea0, name=0x58a0c0 "queens", obj=0x58a040) at module.c:439 #10 0x0000000000403cb4 in mod_loadObject (mod=0x588ea0, offs=1580, obj=0x58a040) at module.c:514 #11 0x0000000000402a13 in mod_resolve (module=0x58a060 "Main", item=0x58a080 "queens") at module.c:209 #12 0x0000000000402f0d in mod_loadConstTable (mod=0x588ea0, finfo=0x589fa8) at module.c:322 #13 0x0000000000403a4b in mod_loadFun (mod=0x588ea0, name=0x589f80 "main", obj=0x589f40) at module.c:439 #14 0x0000000000403cb4 in mod_loadObject (mod=0x588ea0, offs=1606, obj=0x589f40) at module.c:514 #15 0x0000000000402a13 in mod_resolve (module=0x7fffffea0b88 "Main", item=0x41f3f1 "main") at module.c:209 #16 0x00000000004046ee in initGlobals (mainMod=0x7fffffea0b88 "Main", mainFunc=0x7fffffea0248, _toplevel=0x7fffffea0250, _driver=0x7fffffea0240) at main.c:120 #17 0x0000000000404880 in init (mainMod=0x7fffffea0b88 "Main", mainFunc=0x7fffffea0248, _toplevel=0x7fffffea0250, _driver=0x7fffffea0240) at main.c:145 #18 0x00000000004048de in main (argc=4, argv=0x7fffffea0348) at main.c:171
The node represents the (:) constructor which takes 2 arguments (size = 2), but the space allocated is only 1 word (no args[]). Why? Next node which occupies the next word is treated as pointer to args by the GC which leads to crash.
Of course it's not treated as pointer to args, but rather as the first argument, which is also wrong.
Thanks, Michal
--------------------------------------------------------------------- Toshiba i FIFA World Cup Wygraj bilety i notebooki z Intel Centrino Duo Mobile Technology http://link.interia.pl/f1912
_______________________________________________ Yhc mailing list Yhc@haskell.org http://haskell.org/mailman/listinfo/yhc
--------------------------------------------------------------------- Toshiba i FIFA World Cup Wygraj bilety i notebooki z Intel Centrino Duo Mobile Technology http://link.interia.pl/f1912