Re: Weird irreproducible error

[Steve Heller <steve@...>]

On Mon, 08 Oct 2007 23:52:13 +0100, David Given <dg@cowlark.com>
wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Steve Heller wrote:
>[...]
>> I'm doing that right now as a result of an earlier suggestion. I'm
>> also going to put my code on another computer and see if I can
>> replicate the problems there.
>
>TBH I'd be highly surprised if that were the problem. Memory faults on modern
>computers usually result in crashes due to corrupted pointers, rather than
>actual bogus data. (One of the older memory tests was to continuously rebuild
>the Linux kernel for 12 hours. That's a *lot* of pointers. If it got through
>that, provided you managed to make it use all the memory, you were probably
>fine.) Still, it's best to be sure.

So far, no errors in the memtest86 run. I'm up to test #8. I'll
probably let it run overnight tonight to try to eliminate the
possibility of bad memory. 

>> No, there is no DirectX code, or any C code at all for that matter.
>> There is nothing but I/O (disk and a little standard I/O to the
>> screen) and numeric/string calculations, all done in pure Lua.
>
>Can you give an example of one of the things that went wrong? For example,
>line of code, before-and-after values for the variables?

The problem is that the "things that go wrong" are random and don't
make any sense. The code is doing nothing unusual, e.g.,

"if x[i] > y[j] then z = w end"

Most of the problems are nil values that shouldn't be nil. For
example, an index may have a nil value, even though it should not. The
next time I run the program, a different index will have a nil value.
However, if I have this problem when running under ldb, when I look at
the variable that is reported as being nil, its value is what it
should be rather than nil.

Other times, the problem doesn't show up immediately, but only after
the value of a variable is incorrect, which leads to bad calculations
later in the program.

Steve