Actually, the error message is on line 232 of the current file. Are we using an outdated version of seti_header.cpp?

Apart from Jason's provision for Android in 2014 (r2181), most of the file size growth was Eric's r3113 and r3212 for GBT - and the file does "Write a SETI work unit header to a file".

Could the written file be missing some information, if we use an old version?

Actually, the error message is on line 232 of the current file. Are we using an outdated version of seti_header.cpp?

Apart from Jason's provision for Android in 2014 (r2181), most of the file size growth was Eric's r3113 and r3212 for GBT - and the file does "Write a SETI work unit header to a file".

Not sure what missing a parameter addition would do. Is that a possibility for this build?

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

If that is Raistmer's file he'll have build from https://setisvn.ssl.berkeley.edu/trac/browser/branches/sah_v7_opt/AKv8/client/seti_header.cpp

at revision 3377 changes from Urs. you'd have to diff that against vanilla seti and Jason's.

edit i.e. https://setisvn.ssl.berkeley.edu/trac/browser/branches/sah_v7_opt/Xbranch/client/seti_header.cpp

and https://setisvn.ssl.berkeley.edu/trac/browser/seti_boinc/client/seti_header.cpp

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

Searching this board for previous occurences of "Bad workunit header" - which date back to 2005 - reminds me that the -6 error code was triggered by Raistmer's old "VLAR Kill" workround in 2009.

Now, that has no relationship to the current occurrence, except to suggest that interrupting any SETI app at that point in startup has the capability to trigger that exit route. We shouldn't be too literal minded and start peering at the workunit itself.

I think I wrote that better last time round, in message 1711911:

SETI@home error -6 Bad workunit header
!swi.data_type || !found || !swi.nsamples
File: ..\seti_header.cpp

We see this occasionally, but only from the CUDA applications running on NVidia cards (as this task was - that host has both types of card).

"SETI@home error -nn" comes from some very old SETI code, probably dating back to Classic days: my personal suspicion is that the modern applications sometimes wander down this error-handling path for reasons quite different from the ostensible fault reported - but they happen so rarely that the true cause is very hard to track down. There's a SETI@home error -1 "can't create file --disk full?" which similarly crops up sometimes in contexts which imply something completely different to do with autocorrelations.

I think the best thing to do is to ignore the specific error message, but take it as a general indication that the machine is feeling poorly.

It looks like we have a <no_opencl/> "KILL" in the latest client via a cc_config.xml flag. That ought to make a lot of people happy. Looks like a LOT of changes since the last stable release.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

well that was a dead end. Raistmer's last changes (before the extra lines for linux) exactly match Eric's and I've not had enough coffee to certify that Jason's internal switching matches that [@Jason rev. 3315 line 125 I assume you moved that into the temp variable at lines 227 ff. ?]

So, unless it's reproducible - see Richard's comments on odd errors [or is that edd errors? ]

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

It looks like we have a <no_opencl/> "KILL" in the latest client via a cc_config.xml flag. That ought to make a lot of people happy. Looks like a LOT of changes since the last stable release.

ROFL - I'd forgotten that. That was Jacob Klein's request for a way of preventing OpenCL applications from running, during a temporary period when an NVidia driver bug caused errors at PrimeGrid and POEM (only, so far as we know, and the bug is fixed at source now). I did suggest it was overkill, or ought to be matched with a <no_cuda/> tag as well - but since it exists now, there's nothing to stop people testing it.

Just got two bad work units with missing header information it looks like.
4294967290 (0xfffffffa) Unknown exit code

These work units:
Task 4975612198
Task 4975612087

Worth to run scandisk on affected partition.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Just got two bad work units with missing header information it looks like.
4294967290 (0xfffffffa) Unknown exit code

These work units:
Task 4975612198
Task 4975612087

Worth to run scandisk on affected partition.

Well I assumed that anybody who runs into an error that may be due to file damage does first check the integrity of the hard disc before taking it any further.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

Just got two bad work units with missing header information it looks like.
4294967290 (0xfffffffa) Unknown exit code

These work units:
Task 4975612198
Task 4975612087

Worth to run scandisk on affected partition.

Well I assumed that anybody who runs into an error that may be due to file damage does first check the integrity of the hard disc before taking it any further.

Especially after a BSOD.

Correct assumption. I had run a full AV scan earlier in the day since I had moved to different software recently and needed to find out how it handled it. Also, had run integrity checks on the partition and done a /scannow. Nothing showed up. I just think I caught the manager and client in a bad spot at just the right time during program exit. I haven't had a BSOD on either of my crunchers in over a year if I remember correctly. Very solid machines. Or just crack the BSOD up to a case of cosmic ray impacts as Joe or Jason would suggest.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

What exactly makes a SOG a SOG?

Or what is the difference between:

MB8_win_x86_SSE3_OpenCL_NV_r3430.exe

and

MB8_win_x86_SSE3_OpenCL_NV_r3430_SoG.exe?

What exactly makes a SOG a SOG?

Or what is the difference between:

MB8_win_x86_SSE3_OpenCL_NV_r3430.exe

and

MB8_win_x86_SSE3_OpenCL_NV_r3430_SoG.exe?

That's exactly what I would like to know. Both operate within the <plan_class>opencl_nvidia_SoG</plan_class>. That is the only plan_class listed in their respective aistub files in their application 7z files.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

What exactly makes a SOG a SOG?

Or what is the difference between:

MB8_win_x86_SSE3_OpenCL_NV_r3430.exe

and

MB8_win_x86_SSE3_OpenCL_NV_r3430_SoG.exe?

That's exactly what I would like to know. Both operate within the <plan_class>opencl_nvidia_SoG</plan_class>. That is the only plan_class listed in their respective aistub files in their application 7z files.

From Raistmer:
SoG build is more unique case cause it's first time implemented real parallel execution of different searches completely on GPU device.
Progress marks embedded in CPU code and with high AR that CPU code does only non-blocking kernel enqueuing. This done very fast and then GPU process data w/o interaction with CPU code. So no more marks of progress going to BOINC - highly non-linear behavior on VHARs.

non_SoG does process some signals on CPU instead of GPU.

---

With each crime and every kindness we birth our future.

Thanks, Mike.

If they are so different, they probably should have given them different revision numbers.

By not doing so indicates a strong similarity, as indicated by Keith Myers:

Both operate within the <plan_class>opencl_nvidia_SoG</plan_class>

Thanks, Mike.

If they are so different, they probably should have given them different revision numbers.

By not doing so indicates a strong similarity, as indicated by Keith Myers:

Both operate within the <plan_class>opencl_nvidia_SoG</plan_class>

The revision number just makes sure all app versions have same bug fixes and improved switches included.

---

With each crime and every kindness we birth our future.

To be sure what flavor used one can look into result's stderr. It has lot of interesting info, including this line:

Build features: SETI8	Non-graphics	OpenCL	USE_OPENCL_NV	OCL_ZERO_COPY	SIGNALS_ON_GPU	OCL_CHIRP3	FFTW	USE_SSE3	x86	

SIGNALS_ON_GPU in this line means app build with SoG path enabled. So, it's SoG.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

OK, still really confused. I've gone through and looked at my completed tasks with both of the apps I've listed in this thread. Both of them have SIGNALS_ON_GPU listed in their respective stderr.txt files. So how is it you're still saying that MB8_win_x86_SSE3_OpenCL_NV_r3430.exe is not performing analysis with signals on GPU??

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Just wondering if any of the SoG stuff has hit a Lunatics build yet? Assuming no ...

---