Bug and patch

[Vijay Vaidy]

Hi, 

I had reported the THREADSWITCH problem to Tim, but
wasnt as brave as you, cos I couldnt figure out wha
it was doing. I'll look at it and put it back into
the gcc version and retry. Since I dont know enough
about the threads impl. yet could someone else confirm
these changes???

On the other problem, however, I think you may be
looking at a false alarm. Here is my analysis.

in ...
> walkObject(gcInfo* base)

You said ...

>                 obj = MEM2GC(mem[i]);			<---- PROBLEM HERE

What your memory tool is probably catching is an UMR
(or equiv) Uninit Mem Read ... or something that says you
are reading from where you should not, because you did not write
to it to begin with.

Thats fine ... that is how the GC alg works, its scanning for
anything in there that *may* point to an object. Many of the
things it points to are not objects (since they are often not
even pointers) ... so you'd get garbage (probably triggering
a memory access tool in the process) but then you'd
catch it in the next line in the source ...

>                 /* Check we've got a valid object */
>                 if (((void*)obj < minMem || (void*)obj > maxMem) ||
>                     (((uintp)obj % sizeof(void*)) != 0) ||
>                     (!VALIDREF(obj->ref)) ||	       <------PROBLEM HERE
>                     (GETREF(obj->ref) != (uintp)obj)) { <-----PROBLEM HERE
>                         continue;

So, it is not that you are assuming that it *is* a gcInfo, you
are checking to see whether is is a gcInfo there. Thats fine,
and the places you have PROBLEM HERE are what should in
fact trigger the continue.

If anyone feels my analysis is incorrect, please let me know.

- Vijay
-------

> Maybe i am wrong. But when checking this code, debugger say there is problem.
> 
> 
> Any body suggest a patch for this?
> 
> Thank's
> 
> Gilles
> 
>