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
[email protected]
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
_______________________________________________
Yhc mailing list
[email protected]
http://haskell.org/mailman/listinfo/yhc
