This happened when I opened BOINC Manager to Run benchmarks using BOINC Manager 5.4.11. I have 550 MB free RAM of 1 GB installed, AMD Barton core at 2113 MHz and stable for a long time without any errors. Running Windows Vista Beta 2 build 5384.

8/20/2006 10:50:22 AM|rosetta@home|Resuming task 1wit__BOINC_BACKBONE_O_PENALTY_ABRELAX_SAVE_ALL_OUT__1176_756_0 using rosetta version 525
8/20/2006 2:52:41 PM|rosetta@home|Unrecoverable error for result 1wit__BOINC_BACKBONE_O_PENALTY_ABRELAX_SAVE_ALL_OUT__1176_756_0 ( - exit code -1073741819 (0xc0000005))

Here is the result: https://boinc.bakerlab.org/rosetta/result.php?resultid=33562744. My display didn't blink and I'd have missed the event if not looking for my unoptimized benchmarks. Edit for clarification: This is a new installation that has never been optimized.

Just noticed this one. Happened about 24 hours ago:

https://boinc.bakerlab.org/rosetta/result.php?resultid=33412986

Charlie

---

-Charlie

Hi,

Across the machines I have running Rosetta, I've seen a handful of failures recently. Majority have reported an incorrect funtion in dock_structure.cc, with at least one in pack.cc.

Seems to be very similar to what others have reported recently. A bit surprising since I don't remember 5.25 throwing any errors during CASP.

Is it valuable to document the WUs here? My first thought is that the project team must have tools to filter error results from all the returned results for investigation, and documentation here wouldn't be necessary. If that is incorrect and it would help, I'll hang another reply onto the thread.

Cheers,
Alan

---

Is it valuable to document the WUs here?

Yes! See this thread https://boinc.bakerlab.org/forum_thread.php?id=2144. Rhiju is the scientist who submitted the WU.

---

And another. Same error, similar WU (I think) as I and others have reported. Could there be a bad batch of WUs?

https://boinc.bakerlab.org/rosetta/result.php?resultid=33514109

Charlie

---

-Charlie

Per Ethan's reply:

• 33559891 error in dock_structure.cc
  
• 33584990 error in dock_structure.cc
  
• 33513409 error in dock_structure.cc
  
• 32315514 error in dock_structure.cc
  

I'm sure I've seen pack.cc errors as well, but these seem to have fallen off the back end of the results list.

Cheers,
Alan

---

1opd__BOINC_BACKBONE_HN_PENALTY_ABRELAX_SAVE_ALL_OUT__1175_174_0
<core_client_version>5.4.9</core_client_version>
<message>
Incorrect function. (0x1) - exit code 1 (0x1)
</message>
<stderr_txt>
# random seed: 1669857
# cpu_run_time_pref: 86400
ERROR:: Exit at: .dock_structure.cc line:401

</stderr_txt>
33445584
Seems to be a few of them popping up.. (that's 3 of the 10 WUs that have run on this machine this last week.)

---

I got one too:

https://boinc.bakerlab.org/rosetta/workunit.php?wuid=29059205

Result: https://boinc.bakerlab.org/rosetta/result.php?resultid=33499101

stderr out

<core_client_version>5.5.13</core_client_version>
<![CDATA[
<message>
Forkert funktion. (0x1) - exit code 1 (0x1)
</message>
<stderr_txt>
# random seed: 1690643
# cpu_run_time_pref: 10800
ERROR:: Exit at: .dock_structure.cc line:401

</stderr_txt>
]]>

---

[b]"I'm trying to maintain a shred of dignity in this world." - Me[/b]

Incorrect function. (0x1) - exit code 1 (0x1)

Seems to be a few of them popping up.. (that's 3 of the 10 WUs that have run on this machine this last week.)

Me too.

https://boinc.bakerlab.org/rosetta/results.php?hostid=288399

Got 5 of them on this host this morning. The new credit system gives me zero credit for them too. They all seem to have been resubmitted to other hosts. I am running 5.4.11 on this machine.

Edit to say that I have another machine with identical hardware running 5.4.11 and it has zero failed WU's. Maybe a config problem? I dunno..

---

Team Starfire World BOINC

The new credit system gives me zero credit for them too.

You seem to be getting credit for them. The script only runs once a day, though, so you haven't gotten credit for the ones returned today yet. Also, the credit doesn't show in the list, but it does show if you look at the result.

Incorrect function. (0x1) - exit code 1 (0x1)

Seems to be a few of them popping up.. (that's 3 of the 10 WUs that have run on this machine this last week.)

Me too.

https://boinc.bakerlab.org/rosetta/results.php?hostid=288399

Got 5 of them on this host this morning. The new credit system gives me zero credit for them too. They all seem to have been resubmitted to other hosts. I am running 5.4.11 on this machine.

Edit to say that I have another machine with identical hardware running 5.4.11 and it has zero failed WU's. Maybe a config problem? I dunno..

Do I understand this right: In the old system you even got credit for invalid results? Why should this be?

Do I understand this right: In the old system you even got credit for invalid results? Why should this be?

Because here at Rosetta@home the software is tested. Part of the data, sent to you with a new WU, is code to test. So bugs in the software should not effect credit.

Norbert

PS: It's not new. IIRC Seti does this for years, when aborted WUs get credit. At Seti it's corrupt data (or useless data), that causes the aborts (Error 9??).

---

Do I understand this right: In the old system you even got credit for invalid results? Why should this be?

Saenger, just before Ralph started (and probably the reason for ralph existence) is that they were have many wus fail most the way through or get stuck at 1% for days. People were screaming about tying up there puters for that period and not getting some form of reward. They started handing out credit as claimed for the run time up to a certain limit (can't remember the limit, 300 I think). Now that ralph is here, the incidents of failed wus is very low, and I hope they stop that practice.

tony

Do I understand this right: In the old system you even got credit for invalid results? Why should this be?

Because here at Rosetta@home the software is tested. Part of the data, sent to you with a new WU, is code to test. So bugs in the software should not effect credit.

Norbert

PS: It's not new. IIRC Seti does this for years, when aborted WUs get credit. At Seti its corrupt data (or useless data), that causes the aborts (Error 9??).

OK, I understand.
But those results are not marked "invalid", that's the difference.
The only other project I know that grants anything for "invalid" is LHC. There you get half of the credits granted as those with valid results.

So I think the labelling should be changed, as it's also possible that a result is really invalid, for example when the hardware is faulty and delivers no useful results.

Now that ralph is here, the incidents of failed wus is very low, and I hope they stop that practice.

No. (see my answer to Saenger for my argument).

Norbert

---

I hope the practice continues, if the WU is what is wrong nothing to do with your system and you have spent say 23 hours of a 24 hour unit working why should you not get credits ?

---

Not all Czech`s bounce but I`d like to try with Barbar ;-)

Make no mistake This IS the TEDDIES TEAM.

Do I understand this right: In the old system you even got credit for invalid results? Why should this be?

Because here at Rosetta@home the software is tested. Part of the data, sent to you with a new WU, is code to test. So bugs in the software should not effect credit.

Norbert

PS: It's not new. IIRC Seti does this for years, when aborted WUs get credit. At Seti it's corrupt data (or useless data), that causes the aborts (Error 9??).

Norbert, Yes, -9 "result overflow" is the ONLY error that will get credit at seti. It just means there was too much RFI in the signal. There's a limit and when reached it aborts the wu and you get proportional credit for it. It's usually on a matter of a minute or two runtime before it terminates though.

Here's 3 examples from my file:
361014709 86507692 1 Aug 2006 2:45:43 UTC 2 Aug 2006 19:13:29 UTC Over Success Done 138.39 0.11 0.11 2.8615 2.8615
361337990 86585100 1 Aug 2006 21:05:59 UTC 2 Aug 2006 19:13:29 UTC Over Success Done 139.64 0.12 0.12 3.0937 3.0937
360389054 86356170 30 Jul 2006 11:05:05 UTC 30 Jul 2006 17:05:44 UTC Over Success Done 58.78 0.11 0.11 6.7370 6.7370

as you can see they only ran 138 seconds, 139 seconds, and 58 seconds respectively. Now there are a few that run into hours before failing.

I hope the practice continues, if the WU is what is wrong nothing to do with your system and you have spent say 23 hours of a 24 hour unit working why should you not get credits ?

That's right, and that's why they grant something over @LHC.
But how is it determined that it was the software, and not the hardware?

I hope the practice continues, if the WU is what is wrong nothing to do with your system and you have spent say 23 hours of a 24 hour unit working why should you not get credits ?

My opinion is that if the "decoys" is ok you should get credit for them.

Anders n

[edit] I assume that if the computer has done 5 decoys and fails on no 6

it reports the 5 that was ok ?! [/edit]

---

So I think the labelling should be changed, as it's also possible that a result is really invalid, for example when the hardware is faulty and delivers no useful results.

It would be difficult to decide: Is the result invalid, because the computer failed? Or is the result invalid, because the used "routines / parameter combination" doesn't work? The second is a very useful result for Rosetta.

Norbert

---