[Yhc] Re: make tests

[Tom Shackell]

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 at 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
>