[M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse?

[Tony Hosking]

On 22 Sep 2009, at 23:48, Jay K wrote:

> I'm "certain" these are ok but I can try without them.
> One just changes the command line parameters to rc to a form that  
> works with more toolsets. Rc probably isn't even used with Juno at  
> all. Just put error() in the file to test it.
>
>
> The other passes a struct by pointer instead of by value, through a  
> C translation layer, because if you use the gcc backend, which  
> nobody does, it names the functions wrong for the struct by value  
> case. (gcc gets it right when compiling C).
>
>
> You still aren't understanding me.
>
> We have a consistent failure before Feb 20, but it is deemed maybe ok.
>   It was maybe always that way. It is maybe unfinished code. Not  
> heap corruption.
>   Though we don't know 100% and it does merit some investigation.
>
> After Feb 20 without @M3nogc we have a "more severe" and actually  
> fairly consistent but not completely consistent failure -- heap  
> corruption.

OK, now I think I begin to understand.  What happens with  
@M3paranoidgc on the post-2009-02 code is what you sent earlier,  
right?  Sounds like something is being collected when it should not,  
resulting in a dangling reference to memory that gets reused for  
something else.  I don't think I changed anything that would affect  
that.  I'll take another look.  The M3paranoidgc flag should catch any  
dangling reference.  Can you try with @M3noincremental and/or  
@M3nogenerational?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090923/30afa698/attachment-0002.html>