Maude-help mailing list

[Steven Eker <eker AT csl.sri.com>]

Hi,

I can't investigate strange behavior without the example that reproduces that 
behavior. I want a single file (that can load other files), say bug.maude 
such that I can type

load bug.maude

into a fresh instance of Maude and see the bad behavior (without having to 
modify or even look at the contents of the file). Unless the bug is semantic 
in nature I debug by looking at Maudes internals while something bad is 
happening rather than trying to understand the 3rd party code that triggered 
the bug.

Thus having an small example that triggers the bug is unimportant. Having an 
example that triggers the bug quickly is preferable since a fully 
instrumented Maude interpreter can run a couple of orders of magniture slower 
than the release version and I may need to trigger the bug multiple times to 
figure out what the problem is.

Also I need to know what platform you are running on since sometimes bugs are 
platform specific.

There is no timeout feature currently. I suppose one could be implemented - 
I've added it to my maudeToDo list - it's item 954.

Steven

On Friday 19 September 2008 08:35, Nishant Sinha wrote:
> Hi,
>  I'm trying to debug a Maude (2.3) run using "set trace on" option.
> Maude prints information about the rules being applied for some time,
> but then it stops printing anything after a point and starts consuming
> memory rapidly so that it crashes with a std::bad_alloc.
>
> I'm quite sure that my rules are terminating - I've seen Maude keep
> printing stuff if the rule set is non-terminating, so I think the
> problem is somewhere else. In some cases, I've managed to avoid the
> above behavior by commenting out some rules, but there is no
> particular set of rules that I can pinpoint for different examples.
>
> Also, is there a way to set a timeout for rewriting in Maude, i.e.,
> Maude should be able to stop the current rewriting and output the
> intermediate result if timeout occurs.
>
> Please advice.
> nishant