Reported: Computation error (5,)
14 Sep 2011 14:12:55 UTC
Topic 195968
(moderation:
I recently built and brought up a brand new quad-core i7 system that has Server 2008 R2 running on it with 16GB of RAM, and 1.5 TByte of disk space. It's only job is to crunch einstein@home and seti@home data. Unfortunately it is having way too many computation errors. There are multiples of Einstein@Home 0.23 Gamma-ray pulsar search #1...Reported: Computation error (5,) WIN-11ERLSVJEOE
seti@home has the same error with their astropulse software.
A look at the logs attached to the reports reveals that the E@home and S@home software is attempting to write to memory that is write-protected. Probably an errant pointer or memory that was freed prematurely.
I have another i7 quad-core system with 8 GB RAM and 3 Tbyte of disk space running Windows 7 Pro that has been crunching E@home and S@home for several months now and is suffering none of the computational errors of the other system.
Reported: Computation error (5,)
)
Ok, but if both SETI@Home and E@H fail on that particular PC (those apps are written by different teams and I would be surprised if they share bugs), and no such problem exists on another host of yours, doesn't that indicate there is probably something wrong with that PC, and not with the software?
I would suggest to run some memory checking diagnostic software on the PC that shows frequent computation errors.
H B
The first thing that I did
)
The first thing that I did was run memory diagnostics.
The only E@home app that fails is Einstein@Home 0.23 Gamma-ray pulsar search #1 and once only so far SETI@home 6.03 SETI@home Enhanced(possibly a red herring to this problem). All other apps run just fine.
The most prominent failure point is at/near line 1086 in the file exchndl.c.
If the source is available I will dig in and see what is to be learned.
Okay, Took the time this
)
Okay,
Took the time this evening to look closer at the error dumps. It's a classic stack problem. The return instruction pointer on the stack is bogus. My guess is that the stack isn't allocated large enough and it is intruding into data space or the stack is allocated properly and data is intruding into stack space.
Either way it will fail at weird times and situations.