It looks like some bad workunits were distributed on April 14:

https://rake.boincfast.ru/rakesearch/workunit.php?wuid=19424958
https://rake.boincfast.ru/rakesearch/workunit.php?wuid=19424055
https://rake.boincfast.ru/rakesearch/workunit.php?wuid=19424378
https://rake.boincfast.ru/rakesearch/workunit.php?wuid=19424051

Based on the fact that all hosts seem to have problems with these units I assume the problem is server-side.

Any clues as to what happened here ?

Tom

Hello Tom!

... It looks like some bad workunits were distributed on April 14 ...

Thank you for information!
Now we collect and analyze results received during sprint and regenerate workunits like this.

There's another bunch of bad workunits being distributed right now, almost all tasks on my computers crash immediately (e.g., https://rake.boincfast.ru/rakesearch/results.php?hostid=5553&offset=0&show_names=0&state=6) and crashed with the same 0x80000003 exception on other computers.

Yea same, just had 26 in a row error out. Similar to the above the error returned was. an Unhandled Exception "-2147483645 (0x80000003)" https://rake.boincfast.ru/rakesearch/results.php?hostid=7574&offset=0&show_names=0&state=6&appid=

EDIT: Just found another dozen that just happened on this PC. https://rake.boincfast.ru/rakesearch/results.php?hostid=2190&offset=0&show_names=0&state=6&appid=

Hello folks!

Thank you for information! During generation of bunch of workunits some of them "crashed". In next few days we plan to regenerate it.
Also we check integrity of bunches of workunits and results during receiving and archivation phase and if we detech missed or crushed workunits - we make a new copy for them.

Thank you!

Hi, bad work units still incereasing , https://rake.boincfast.ru/rakesearch/results.php?userid=67&offset=0&show_names=0&state=6&appid=

750 and 1000 waiting for walidation .. at night fall project to "24 hours refresh" .. and my pc was empty of units,
hope you find where is problem soon..

Unfortunately, some tasks are downloaded empty.
https://thumbsnap.com/LHQvN3JJ

Yeah, had a ton of them again as well. Worst is that computation errors have a negative effect one the BOINC client connection retries (waits longer and longer, really annoying)

Hello folks!

Total number of "crushed workunits" - about 7200. We know, how to extract its list from the database - by workunit attributes.
Today 3812 of "crushed workunits" were archived and regenerated.

It seems that another batch of bad work units are being distributed.

Been receiving LOTS (50)+ BAD TASKS -- MOSTLY IN LAST HOUR
Error tasks for Dr Who Fan

---

Hello RobertN!

Interesting! Post link to one or several tasks tasks, please.

Thank you!

It seems that another batch of bad work units are being distributed.

Hello Dr Who Fan!

Been receiving LOTS (50)+ BAD TASKS

Your hosts hidden, but we can view failed tasks later - in database.

From what I can see there from just two batches.

Tasks that are still being issued that start with either "R9_02026****" or "R9_02025****" all give computation error.

Hello Dr Who Fan!

Been receiving LOTS (50)+ BAD TASKS

Your hosts hidden, but we can view failed tasks later - in database.

My host are NOT hidden.... I have the check box checked/filled for Should RakeSearch show your computers on its web site?

I never had a problem linking to my public viewable task list at other projects in the past.
Could it be there has been some change to the base/default BOINC SERVER CODE removing the ability to view other peoples task list recently?

---

@Dr Who Fan: In your link titled "Error tasks for Dr Who Fan" you tried to link "all" your PC's error tasks. You can only show links to just one PC at a time. It's always been that way.
For some reason only a logged in user has access to all his PC's at once, why? who knows?

Eh, been getting lots of bad WUs myself. Nvm the ratelimit, getting more bad WUs again :P

Thank you for attention, folks! Some "crushed workunits" created (during its generation) normally but the problem arose during generation of tasks. But some workunits, really crushed at the beginning, during generation files for workunits. Both groups were "distributed" over an entire set of failed tasks. The first group already detected and most of workunits within - already processed, but the second group we detected now with your help!

Now we make a new copy of workunits and upon "completion" present "failed workunits", we delete it from database and make a new copy of tasks.

Thank you!

Minor update: now about 5600 workunits based on "broken" files in progress. Most of them already have 6 .. 9 results completed with errors and, I think, in next few days lifecycle of most of them come to and end and we can replace them with new ones. Half an hour ago we replace 1849 workunits.

Still coming through all my work is aborting:

<core_client_version>7.6.33</core_client_version>
<![CDATA[
<message>
process exited with code 193 (0xc1, -63)
</message>
<stderr_txt>
terminate called after throwing an instance of 'char const*'
SIGABRT: abort called
Stack trace (14 frames):
[0x40bf2d]
[0x493e00]
[0x493ccb]
[0x49e095]
[0x47927d]
[0x4772a6]
[0x4772d3]
[0x4773f2]
[0x404846]
[0x404bdb]
[0x400bdc]
[0x4013d6]
[0x49563b]
[0x400449]

Exiting...

</stderr_txt>
]]>

---

Proud Founder of BOINC@AUSTRALIA
Have a look at my WebCam
My best Prime 91655310131072 + 1