@Carl Love Yes I confirm that Preben's eval trick doesn't work for me, that add, sum, mul and indeed no function at all -- as Carl observed -- reliably cause kernel death.  We really need a Maplesoft programmer to comment.

BTW this code is distilled from a much more involved context, and I have tried numerous variations:

• Proc BlahMethod can be static or not, kernel still dies.
• Giving the object a ModuleCopy constructor -- that will be called by Object -- kernel still dies.
• C, d can be assigned or unassigned, Array, Vector or table, kernel still dies.
• Simple +, like C[i] + d[i] ... works fine!
• Simple *, like C[i]*d[i] ... works fine!
• Dropping either or both indices e.g. C[i]*d + C[i] ... works fine!

Looks as though the bug is triggered by a "* and +" expression involving indexed variables.  Which is baffling!

The point is that the offending line is in the proc BlahMethod, yet the failure is not triggered during execution of BlahMethod.  Instead it is triggered during object construction by Object.  So what is wrong with the line?  The line with add is able to execute at command line, so of itself seems ok.  The kernel failure appears to be a bad interaction between add and objects.

Thanks for the pointers.  I hadn't spotted that caveat in the Profiling help page, as the exception was being raised in other places like CodeTools:-Profiling:-Coverage:-Print,  CodeTools:-DecodeName and the like.  I've tried the named module suggestion, and it looks like it's going to work, without the nuisance of putting the module into a repository.

It could be that the two workarounds you suggested are related. The help page for module,named says: "Every module that is saved to a repository is given a name (that under which it was saved) for use by the persistent store."  So perhaps the reason why packages in the repository work is that they are named?

In fact we had a third workaround, along the following lines...

m := module() option package; export f; f := proc() end proc; end module;
fcopy := op(m:-f);
[now work with fcopy for profiling purposes]

But named module is cleaner.  Thanks again for your help, we now have something we can work with.

Ian.

Thanks for the pointers.  I hadn't spotted that caveat in the Profiling help page, as the exception was being raised in other places like CodeTools:-Profiling:-Coverage:-Print,  CodeTools:-DecodeName and the like.  I've tried the named module suggestion, and it looks like it's going to work, without the nuisance of putting the module into a repository.

It could be that the two workarounds you suggested are related. The help page for module,named says: "Every module that is saved to a repository is given a name (that under which it was saved) for use by the persistent store."  So perhaps the reason why packages in the repository work is that they are named?

In fact we had a third workaround, along the following lines...

m := module() option package; export f; f := proc() end proc; end module;
fcopy := op(m:-f);
[now work with fcopy for profiling purposes]

But named module is cleaner.  Thanks again for your help, we now have something we can work with.

Ian.