Re: NULL pointer or objptr should not pass the validity check.

You are right, Matthew. the NULL point should not have been in the heap.

I noticed after my temporary fix, the executable at last raise a exception
says not enough memory to create a heap. Therefore I then made the runtime
print each GC_mmapAnon and GC_release. The requested heap size goes from
18M to 500M at last. Note that I implement GC_mmapAnon() with malloc(). I
realized that it is a special feature of my currently using platform. The
freed piece of memory are directly put back to the system nor they can be
used to satisfied by next request. The C runtime keep all those pieces of
heaps and finally run out of memory.

After I telling the C runtime to always to put back those freed storage,
the running out of memory error goes aways. And removing my temporary fix,
the executable can still successfully run, showing that the NULL point does
not exist on the heap when there are sufficient memory.

Thank you very much,

Jason


2013/5/11 Matthew Fluet <[email protected]>

> On Thu, May 9, 2013 at 5:27 AM, 吴佳森 <[email protected]> wrote:
> > When I was porting the MLton, I met two segment faults. And after careful
> > inspection on the trace, I made following changes to runtime/gc/objptr.c
> and
> > runtime/gc/pointer.c.
> >
> > The changes are about deciding whether the given pointer or objptr is
> valid.
> > The original code only check the last few bits must be zero, and hence
> NULL
> > pointer is also considered valid. I don't think NULL pointer should pass
> the
> > check hence made the changes.
> >
> > I am not sure if I'm correct on the judgement because I guess if may
> also be
> > some problem elsewhere that introduce the NULL pointer to GC.
> >
> > Could someone please have a check on it? I would appreciate any feed back
> > for it. Thank you very much.
>
> The isObjptr and isPointer functions are used by the garbage collector
> to distinguish true pointers to ML objects from other data that is
> packed into a pointer-sized field (and that could, sometimes, be a
> true pointer).  The canonical example is a type like:
>
>   (int * int) option
>
> The SOME variant must be represented as a pointer to the (int * int)
> tuple, but the NONE variant can be represented by a pointer-sized word
> with non-zero low bits.
>
> This should always be the case --- either the word being inspected by
> isObjptr/isPointer is a true pointer or it has non-zero low bits.  I
> don't believe that it these functions should ever be called on NULL.
>
> I think the better choice would be to add:
>   assert (0 != p)
>
> If these functions are being called on NULL, then the heap has been
> corrupted at some earlier point.  Returning 'false' and treating the
> NULL as a non-pointer will simply mask the corruption for a little
> longer.
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. This 200-page book is written by three acclaimed
> leaders in the field. The early access version is available now.
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> _______________________________________________
> MLton-devel mailing list
> [email protected]; [email protected]
> https://lists.sourceforge.net/lists/listinfo/mlton-devel
>

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

_______________________________________________
MLton-devel mailing list
[email protected]; [email protected]
https://lists.sourceforge.net/lists/listinfo/mlton-devel