1. 2.4 weirdness -- first report
This may be too vague to be of any help, but I'll try.
I've got a program that does a bunch of that "random math" that
uncovered the arithmetic bug in the translator. I've suspected that
there may be a similar bug in the interpreter as I've occasionally
gotten a machine-level crash with the same programs with the interpreter
(2.3).
Just yesterday this happened to me with the interpreter, but it is very
hard to isolate, and it doesn't happen consistently even when running
the exact same code. So this morning I set up v2.4 and ran the same
program. Sure enough, I got a machine-level crash on the very first
try, but the new interpreter (exw.exe, btw) gave me an error message
this time. The line that caused the exception:
"return NIL"
at the end of a function. (It is a function that acts as a procedure,
but is called as a method with the Diamond library.) So that didn't
help much. And I haven't been able to reproduce the error since.
But there's more. The function in question does a bunch of that random
math (calls other functions that do it), and also stores the results of
the calculations in a massive 2d sequence. Then it takes that sequence
and "rotates" it into another big sequence, but with the "rows &
columns" inverted. As such, the thing takes quite a bit of memory, and
the sequences are local to the routine. Right before the return
statement, it prints out a value, and the line directly after the one
that calls the routine also has a print statement. So when the function
exits I see two lines printed on the screen basically at the same time.
At least, when using the 2.3 interpreter that's what happens (when it
isn't crashing mysteriously). With 2.4, there is a pause of nearly 30
seconds between the two print statements -- in other words it takes
about 30 seconds to execute the line:
"return NIL"
Now then, I have a free RAM indicator on my toolbar, and I can watch the
amount of free memory go down as my programs run. With 2.3, the memory
goes down to a certain level and stays there. With 2.4, during those 30
seconds, the memory creeps back up (about 30 MB). So I assume you've
done something different with the garbage collection, and it is taking
forever to release those temporary sequences for some reason?
So, I'm not sure if I have one or two problems, and I don't know if they
are related. Run-down of the weirdness:
-- I sometimes get a machine-level crash with both 2.3 & 2.4. I'm not
doing any peeking or poking. I cannot reliably reproduce this crash
even though the code is exactly the same and the output of the program
otherwise is exactly the same. My program does use randomness, but I'm
setting the random seed to the same value at the beginning of the
program (almost -- there is some "random randomness" that occurs when
loading in some include files prior to setting the random seed in the
main file, but that should have no effect on anything). With 2.4, the
crash is identified as occuring in the line "return NIL". (No dump in
the ex.err with this btw, just the one line -- that could be useful.)
-- With 2.4, I'm getting a huge pause to return from a routine and a
bunch of memory is freed.
Here endeth the report.
2. Re: 2.4 weirdness -- first report
Andy Serpa writes:
> I sometimes get a machine-level crash with both 2.3 & 2.4. I'm not
> doing any peeking or poking. I cannot reliably reproduce this crash
Please send me the program. I'll try to reproduce it on
one of my machines here.
> Now then, I have a free RAM indicator on my toolbar,
> and I can watch the amount of free memory go down as
> my programs run. With 2.3, the memory
> goes down to a certain level and stays there. With 2.4, during those 30
> seconds, the memory creeps back up (about 30 MB). So I assume you've
> done something different with the garbage collection, and it is taking
> forever to release those temporary sequences for some reason?
Yes, I've changed the storage allocator significantly.
I'm using a WIN32 API routine directly.
It might be giving the memory back to the system in this situation,
rather than holding on to many megabytes of it. That takes more time though.
Perhaps you are now getting some disk paging activity too.
> return NIL
When you execute a "return" statement, it will free up all the
private variables and temps used in the subroutine.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: 2.4 weirdness -- first report
On Sat, 22 Feb 2003 18:55:31 -0500, Robert Craig <rds at RapidEuphoria.com>
wrote:
>
> Andy Serpa writes:
>> I sometimes get a machine-level crash with both 2.3 & 2.4. I'm not
>> doing any peeking or poking. I cannot reliably reproduce this crash
>
> Please send me the program. I'll try to reproduce it on
> one of my machines here.
>
>> Now then, I have a free RAM indicator on my toolbar,
>> and I can watch the amount of free memory go down as
>> my programs run. With 2.3, the memory
>> goes down to a certain level and stays there. With 2.4, during those 30
>> seconds, the memory creeps back up (about 30 MB). So I assume you've
>> done something different with the garbage collection, and it is taking
>> forever to release those temporary sequences for some reason?
>
> Yes, I've changed the storage allocator significantly.
> I'm using a WIN32 API routine directly.
> It might be giving the memory back to the system in this situation,
> rather than holding on to many megabytes of it. That takes more time
> though.
> Perhaps you are now getting some disk paging activity too.
Does this also apply to allocate(). If so, I can reinstall its usage in
win32lib and remove the WIN32 API calls.
--
cheers,
Derek Parnell
4. Re: 2.4 weirdness -- first report
Derek Parnell writes:
> Does this also apply to allocate(). If so, I can reinstall its usage in
> win32lib and remove the WIN32 API calls.
Yes.
For exw.exe, I'm now using HeapAlloc() on the default heap,
for all storage allocation.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
