The same on my hosts, like
Windows here: exit code -1073741819 (0xc0000005), Reason: Access Violation (0xc0000005) at address 0x0066C28D read attempt to address 0x0405FF98 (with full BOINC Windows Runtime Debugger symbolic output),
or Linux here: Maximum disk usage exceeded, segmentation violation, with numeric Stack trace (12 frames).

Peter

Chu,


Could you put that problem summary in the 'technical news' at the Rosetta@home site.

It would give people a definate place of what the problem is, it would also mean forum helpers could post a link to the news when the errors are happening.

I had a WU fail today, this message was in the log:

12/14/2006 9:14:07 PM|ralph@home|Unrecoverable error for result 1ten__BOINC_POSE_ABRELAX_VARY_ALL_BOND_ANGLES_VARY_ALL_BOND_DISTANCES_NEWRELAXFLAGS_frags83__1561_15_0 ( - exit code -1073741819 (0xc0000005))

This result: resultid=362757

I came back to the computer and had a Windows error message on the screen "Please tell Microsoft about this problem..." . I don't know if graphics were involved, since I was out, however I do have graphics enabled on this machine, and it is a multiprocessor machine. hostid=2016

I've got a live one!

I can't do anyting with the graphic, no rotate, zoom etc. therefore no crash, as per all these "beta / test" WU's.
but
when viewing the graphic, very slow to show the image, black screen for a few sec then very slow to update the graphic.

WU at 1% but has taken 50min of cpu.

then go back to boinc when typing this message, and the WU shows 1.5% complete and 4 min of cpu time.

it didn't crash though.

boinc 5.75
rosetta 5.43
ralph rosetta_beta 5.43

We are trying to increase stability in this release... We have turned off mouse rotation and sidechains temporarily. Please let us know if you can force a crash by playing with the "show graphics" option from the boinc manager, or with your screensaver!

If I open the show graphics window then minimize and re-open the window is just black and then crashes

Well, I'm now back to my problem PC, and was about to blow the train whistle --Whoo hooo!-- when I saw my screensaver MOVING, and it was on model 94. But then I noticed it only crunched the first WU for almost exactly 3hrs. Now that I've updated to project it shows watchdog ended it. And I commonly saw that same symptom on Rosetta once I activated the screensaver on the same host.

Because the watchdog ended it, the messages tab just shows that the very long WU name "finished".

The second WU I received is crunching happily now in to it's 10th hour. I could NEVER have lasted that long on v5.41. So, I can definately say "more stable". It is supposed to run for 24hrs, and that means if all goes well it will complete just after I leave for work in the AM.

I should note that my hyperthreaded CPU is set in BOINC to only use 1 at the moment. That measure did not seem to make Rosetta any more stable. Now I should set it back to two, but the only other work I have is for Rosetta :) and if I have both running, I don't know how BOINC chooses the screensaver, but I think I'll botch my test.

The "docking" WUs seemed to be the most graphically intense. Have some of those been queued up for test here?

Old error 161 is still with us

http://ralph.bakerlab.org/result.php?resultid=331711

stderr out

<core_client_version>5.2.14</core_client_version>
<stderr_txt>
Graphics are disabled due to configuration...
# random seed: 2845454
# cpu_run_time_pref: 21600
======================================================
DONE :: 1 starting structures built 126 (nstruct) times
This process generated 126 decoys from 126 attempts
0 starting pdbs were skipped
======================================================


BOINC :: Watchdog shutting down...
BOINC :: BOINC support services shutting down...

</stderr_txt>
<message><file_xfer_error>
<file_name>CAPRI_11_t27j_SMALLPERTURBATION_DOCKING_1520_12_1_0</file_name>
<error_code>-161</error_code>
<error_message></error_message>
</file_xfer_error>

</message>

Validate state Invalid

After about 40 minutes of computing:

2006-12-01 08:07:29|ralph@home|Unrecoverable error for result 1mkyA_ETABLE_TEST_ABRELAX_rhh13sm6atrrep__1519_8_0 (Niepoprawna funkcja. (0x1) - exit code 1 (0x1))

<stderr_txt>
fullatom_setup.cc: CHANGING fa_max_dis to 6!!!!!!!!!!!!!
setting hydrogen_interaction_cutoff to: 6
# random seed: 2845518
# cpu_run_time_pref: 3600
fullatom_setup.cc: CHANGING fa_max_dis to 6!!!!!!!!!!!!!
setting hydrogen_interaction_cutoff to: 6
# cpu_run_time_pref: 3600
sin_cos_range ERROR: -1.#IND000 is outside of [-1,+1] range
sin_cos_range ERROR: -1.#IND000 is outside of [-1,+1] range
ERROR:: Exit at: .fullatom_energy.cc line:2002

Regarding the new feature to run Rosetta from a command file and a more flexible interface for setting up runs on BOINC...

I just wanted to confirm... this will make things more flexible for... the project team, right? Or if users can make use of this in some way, then of course we'll want to know how to utilize it and what it can do. If for the project team, another brief sentence about what this will enable you to do in the future would be nice. It will... ??? allow you to setup the runtime parameters for a set of WUs faster? and in a way that's less prone to error? ...or to produce more WUs on the server with less overhead? Or what?

=============

Also, I wasn't clear on what you fixed in item 3. Was the watchdog not stopping WUs? Or were the completed models not being properly preserved?

One more:

2006-11-23 12:14:34|ralph@home|Unrecoverable error for result CAPRI_11_U1H2_GLOBAL_DOCKING_1510_39_2 (Niepoprawna funkcja. (0x1) - exit code 1 (0x1))

<core_client_version>5.6.5</core_client_version>
<![CDATA[
<message>
Niepoprawna funkcja. (0x1) - exit code 1 (0x1)
</message>
<stderr_txt>
ERROR:: Exit at: .docking.cc line:1825

Even it didn't begin to compute :(

Pepo wrote:

Also the version 5.36 is checkpointing after reaching 100% (instead of reporting the result) and then being preempted by other apps afterwards (possibly for a longer time, because of negative STD).

Also the version 5.40 is checkpointing after reaching 100% (instead of reporting the result) and then being preempted by other apps afterwards (possibly for a longer time, if there is too negative STD).

Actually it happened on Rosetta, not here, but I assume the responsible code is the same.

Peter

FRA_2rio_RIO2_hom002_6_2rio_6_1a06__IGNORE_THE_REST_10_1499_12_0


WARNING! error deleting file .aa2rio.out

May I ask? I hope a good description can be written for when 5.38 comes to Rosetta... WHY is "...outputting structures with non-ideal backbone and sidehchain geometries" an improvement? I know, useful to the science... please explain more, on the surface it sounds to a layperson like a step backwards. Also, what impact will this have on the user experience? Will it mean we'll see larger upload sizes on results?

V5.38 WU 315376 just crashed on my other machine. I just HAPPENED to be enlarging the native structure shown at the time of failure, so that was the first I'd brought up the graphic for this WU, rotated the lowest energy, then enlarged native and then crash and burn.

exit code -1073741819
24hr RT preference.