Re: EU 3.0.1 -- there's probably a bug in there somewhere
Robert Craig wrote:
>
> Andy Serpa wrote:
> > I've been running 3.0.1 for a just a couple weeks -- had no problems with
> > anything
> > but these most complex programs using lots of memory. (Had a similar crash
> > on something else a couple days ago, but didn't bother to track it down.)
> > So
> > a "simple example" may be an impossibility. If I change the order of
> > statements
> > in the crashing function or just add do-nothing statements (but so that the
> > logic remains the same), it will still crash, but maybe on a different call
> > to the function at a different time.
> >
> > Also, it may be helpful to know that in the ex.err file it produces, all of
> > the
> > variable values for the function in question are listed as <no value>,
> > so apparently it is happening as or just after it has dereferenced those. I
> > assume something is not getting cleaned up properly. Have you changed
> > anything
> > along these lines from v2.5 to 3.0?
>
> Yes, there were changes in subroutine call/return to support multitasking.
> These changes can affect programs even if they don't use multitasking.
> If you are doing recursion, that might be of particular interest in
> solving this.
>
I'm slowly narrowing in on this. There is no way I will be able to do anything
with the source code to help here -- it is simply over my head. I've found two
instances of this now that I can reliably repeat. This is code I've been using
for years. Both crashes occur when exiting functions that are being called as
methods in Mike Nelson's Diamond. Which means they are being called via
routine-id. If I call them directly (which does involve changing a few things
because certain Diamond calls won't work that way) I can't get them to crash. So
does calling a function via call_func/routine-id affect things, or maybe that is
just a coincidence? Or maybe it because of recursion -- Diamond has its own call
stack, so calling anything at all in Diamond might involve some recursion.
One of the functions is actually only two lines long:
function save_forest
put_obj(get_property(this(),"savepath")&"for_"&get_property(this(),"name")&".ent",save_entity(this()))
return NIL
end function
What this does is save the Diamond entity to the hard drive. The call
"save_entity(this())" converts the current entity into a byte sequence -- that's
a recursive function very similar to the one in EDS that converts Eu objects into
byte sequences for storage. The other parts grab filepaths and filenames, the
procedure "put_obj" simply opens up the filename for binary writing, and puts()
the second argument to disk.
The other function that crashes is much more complex, but it does call some
other functions which are also recursive.
Another thing I've verified is that the return value itself seems unimportant;
it crashes with anything, even just an integer 0.
It is important to note that everything in the function gets done, and done
correctly -- it just crashes on exit. (For instance, in the first example, the
entity is successfully saved to disk before the crash.)
Also, they don't crash every time the function is called -- conditions have to
right. I don't know what the right conditions are, but in my case they involve
doing a bunch of complicated sequence building, and if the initial conditions are
the same, it will crash reliably at the same point. But as usual with these
things, just changing a line here or there or adding a reference will cause it to
no longer crash, or to crash at a different point, even if the logic of the
program is the same.
For instance, if I change the above the function to :
function save_forest
sequence e
e = save_entity(this())
put_obj(get_property(this(),"savepath")&"for_"&get_property(this(),"name")&".ent",e)
return NIL
end function
then it no longer crashes. It is because the bug no longer occurs when written
like that, or it is just because I've changed the conditions and it would still
crash in other conditions? Can't tell.
|
Not Categorized, Please Help
|
|
