Forum > Windows
New apps based on code revision 2.2 'Noo? No, Ni!' have been released!
BenHer:
Don't worry Joe, Urs is probably super over clocking his Pentium III. ::)
(just kidding for those whose sarcasm sensors don't function)
Urs Echternacht:
--- Quote from: Josef W. Segur on 22 Feb 2007, 11:33:44 am ---
That's a puzzle. For these 3, the callstack indicates it's happening while the app is putting its identifying information in stderr.txt, specifically the line in red:
fprintf( stderr, "Optimized SETI@Home Enhanced application\n\n" );
fprintf( stderr, "%9s: Ben Herndon, Josef Segur, Alex Kan, Simon Zadra\n", "Optimizers" );
fprintf( stderr, "%9s: %s %s %s-bit based on seti V%d.%2d 'Ni!'\n", "Version"
,_OS_, _fft_simd_, _bits_
, gmajor_version, gminor_version );
fprintf( stderr, "%9s: (R-%s|%s)\n", "Rev", _release_, _compOps_ );
How it got to trying to execute non-existent code at 0x0055B8E3 I don't know.
The other one you posted is even more a puzzle, the callstack indicated it was executing a tail section which should only be used if the WU has a num_samples not evenly divisible by the fft length.
Joe
--- End quote ---
Hi Joe,
great you were able to spot the related source-places.
Maybe the fprintf C-function is not safe (stack buffer overrun is possible?). That is one of the other things i did change in my private build at seti beta using instead streaming to stderr, e.g.:
--- Code: ---std::cerr<<"Some text"<<std::endl;
--- End code ---
--- Quote ---Don't worry Joe, Urs is probably super over clocking his Pentium III.
(just kidding for those whose sarcasm sensors don't function)
--- End quote ---
Hi Ben,
sarcasm noted. That machine has NO overclocking possibilities! (-> Gigabyte 6BXDU)
P.S. Attached another one.
[attachment deleted by admin]
Josef W. Segur:
--- Quote from: Urs Echternacht on 22 Feb 2007, 01:20:17 am ---...
Here are some more error reports attached occurring to my dual P3 yesterday. (0xc0000005) Hopefully that flaw can be found someday.
--- End quote ---
For my previous reply I was looking at a disassembly of a test version rather than the fresh disassembly I did of SSE 2.2. Just clumsy, I guess.
With the right file, all but the first error are in the setup for testing pulse folding, this code:
--- Code: --- // At some angle ranges the total number of test folds may be too few to get good
// timing measurements. Scale up so there are at least 8K test folds.
while (NumPlans < 8192) {
for (iL = 0; iL < 32; iL++) {
FFTtbl[iL][1] *= 2;
FFTtbl[iL][2] *= 2;
FFTtbl[iL][3] *= 2;
}
NumPlans *= 2;
}
--- End code ---
The Intel compiler unrolls the for loop completely, the FFTtbl[32][5] array is integers and on the stack, so the generated code loads a value from the stack into esi, adds esi to itself, and stores it back on the stack. The specific one at 0x0055B8E3 is "mov [ebp-44h], esi". But the dump info says "write attempt to address 0x0013D20B" and "ebp=0012e6f8". I have no theories on what's really happening, nor why it's only affecting your dual PIII system. But it should only happen at high angle ranges where that scaling is needed (the two which remained in your results list an hour ago had ar=1.948616 and ar=7.924980 from other host reports).
For the first "Access Violation (0xc0000005) at address 0x0056A89F write attempt to address 0x02239040" you posted, the instruction is "movntps [esi],xmm3". That's the first store for a 4x4 transpose function which writes to the transposed PowerSpectrum array. Transposing is used heavily, so it seems like a one-time glitch unless the system has been choosing one of the other transpose routines since then.
If you would put a copy of the app and a WU renamed work_unit.sah in a temporary directory and execute the app with a -bench command line parameter, it would produce a stderr.txt showing the testing of routines and which ones are chosen. It then exits without actually crunching the WU, so should take less than a minute. I'll attach a README.txt which has all the command line options.
Joe
[attachment deleted by admin]
Urs Echternacht:
--- Quote from: Josef W. Segur on 23 Feb 2007, 03:13:10 pm ---If you would put a copy of the app and a WU renamed work_unit.sah in a temporary directory and execute the app with a -bench command line parameter, it would produce a stderr.txt showing the testing of routines and which ones are chosen...
Joe
--- End quote ---
Hi Joe,
here you are. Took just a few seconds. Hope it helps somehow.
[attachment deleted by admin]
Simon:
Hi folks,
I'm currently compiling Rev-2.2B apps with Joe's fix. In the meantime, I've uploaded a current source archive (including this fix).
Regards,
Simon.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version