RE: 2.4 Official Release - machine level exception
Robert Craig wrote:
>
>
> Pete Lomax wrote:
> > I get a machine-level exception during the statement
> > pos[P_yto]-=rely
> > where
> > pos = {24646,7901,32476,9990}
> > rely = -3543
> > and P_yto is the constant 4
> >
> > If I just insert eg 'if integer(rely) then end if' before that
> > statement it works fine.
> >
> > Worrying.
> >
> > If making such a tiny alteration makes the problem go away, it will
> > probably work fine on most other machines (or any with a slightly
> > different kernel32.dll etc)...
> >
> > Any ideas?
>
> Your little code fragment above works fine for me.
> I assume it's part of a much bigger program that
> has pokes, calls to C routines etc.
> Chances are, you have gone out of bounds with a poke,
> passed a bad value to a C routine, etc. The program
> could work fine on one run, but fail mysteriously
> on another, after any kind of trivial and
> seemingly irrelevant change. In this particular case
> you may be clobbering a Euphoria variable, stored
> in memory near one of your allocated blocks. Perhaps this
> is showing up now with 2.4, since the memory is organized
> differently. When using Win32Lib, I think you are now
> more likely to trash a Euphoria variable when you
> go out of bounds, rather than trashing another
> memory block that you allocated.
>
> I would at least try safe.e (see instructions at top of safe.e).
> Since Win32Lib has gone back to using Euphoria's allocate(),
> safe.e is now more effective. By default, in 2.4 Official,
> safe.e will only check the edges of blocks allocated
> by allocate(), so you shouldn't get any false alarms,
> but a lot of memory accesses will not be checked.
>
>
I still the get a mystery crash once in a while. I can never isolate or
duplicate it precisely (usually random numbers are involved and I can
never find a seed that reproduces the problem), but it seems to happen
in programs that sum up a large number of floating point values, often
incredibly small values, and then do something like invert it. Can you
think of a reason adding up a bunch of floats (there are probably
precision issues here) would ever cause a problem? Sometimes a number
that isn't quite zero is taken to be zero in some operations but not
others (precision again, I assume). What happens if I do
1/not_quite_zero ?
|
Not Categorized, Please Help
|
|
