[news.eclipse.modeling.m2m] Re: [ATL] random crashes?

[William Piers <william.piers@xxxxxxx>]

Hello,

answers below (and sorry for the late...) :

Rene Ladan a écrit :
> Rene Ladan wrote:
> > Rene Ladan wrote:
> > > Rene Ladan wrote:
> > > > Hi,
> > > >
> > > > I seem to get random crashes: the transformation is bound to crash, 
> > > > but the exact point differs from invocation to invocation

Do you encounter the same issue running your transformation both 
programmatically and using launch configs ? I mean, do you think the 
error comes from your code or the ATL transformation ?

> > > > I've attached the Java file which invokes the engine and a partial 
> > > > backtrace (where the crash happens at 'copy_activation').
> > > >
> > > > Eclipse 3.4M7 I20080502-0100
> > > > ATL 2.0.0 20080520-0346
> > > > EMF 3.4RC1 20080512-1800
> > >
> > > I've (finally) attached the metamodel and an input model (which is 
> > > composed
> > > from different parts, see the code in invoking.java posted in this 
> > > thread).
> > No-one?
> >
> > Have there been possibly relevant changes since 2008-05-20 (cvsweb 
> > available?),

No, no "relevant" changes on engine

> > i.e. would it be recommended to try the CVS HEAD version?
> >
> > The only bug report for 'crash' and 'M2M' is number 214871.
> >
> > I'm afraid this issue is a work-blocker.
> I've installed the CVS HEAD version (2008-05-30), which also crashes.
> It seems like the ouput model somehow gets corrupted, because it only
> contains empty elements in a flat list.  However, the crash always seems
> to happen in a copy_X rule, which really only copies all elements from X
> to a clone of X.

Is there a way for you to provide a small test case reproducing the bug 
? Elsewhere I would try to experiment some "copy" transformations on 
your model, but it might be longer...

> Maybe the offending part is
>   
> org.eclipse.m2m.atl.engine.vm.ASMOperation.realExec(ASMOperation.java:240)
> which is in the handler of the "call" instruction (so the transformation 
> gets
> compiled and loaded correctly).

So I think the error happens during the execution of the called 
operation (by the "call" instruction).
> What also slightly worries me is that the code compares strings using 
> the ==
> operator (e.g. (mn == "call")) instead of using the equals() method.  
> Using the
> == operator compares the memory addresses of two strings, which might 
> indeed
> work for short strings (because of caching?), but not for longer ones.

That code intents to match core instructions (call, push, pop, etc...) 
which are generated by the compiler, so there is no need to match long 
strings.

> Rene

Best regards,

William