And others (4852300, 4852284, etc) with these errors:

<message>
(unknown error) - exit code -1073741819 (0xc0000005)</message>

- Unhandled Exception Record -
Reason: Access Violation (0xc0000005) at address 0x0045C0E8 write attempt to address 0x306F712C

- Unhandled Exception Record -
Reason: Access Violation (0xc0000005) at address 0x0147C0E8 write attempt to address 0x312C612C

- Unhandled Exception Record -
Reason: Access Violation (0xc0000005) at address 0x00000000

[quote]Looks like whoever wrote the message on 24/4/18 is still waiting for information on which versions of Windows were used for the 32 bit failures. If so, there's no point in complaining about lack of another message or fix until more people supply this information.
[Quote]

G'Day Robert,
I was not complaining, I was bringing back to the forefront of awareness a problem which dates back to at least the beginging of Feburary (2018).
32 Bit Rosetta work units have been failing for many months, but no fix yet.

They fail on both Ralph and Rosetta, as the administrators of the Rosetta project have not used their test project Ralph properly before releasing work on the main project.
The problems are supposed to be fixed here first then released to Rosetta.

Other problems were listed here about Linux work units as well but still they went ahead and released work on Rosetta.

So now they have a lot more people complaing (over at Rosetta) about failing work units (32 bit, 64 bit, Windows and Linux) because they did not seem to take heed of what the test project was telling them.

We try to help these people but if they don't take action on what we report then the results will be poor.

So just trying to help the Project, as I have been doing since the test project was launched.

Have a great day.

Conan

---

We try to help these people but if they don't take action on what we report then the results will be poor.
So just trying to help the Project, as I have been doing since the test project was launched.

I was amazed how few people work on ralph@h/rosetta@h.
Only 3 persons: 2 servers admins and 1 developer/debugger/code maintainer.
To this situation we have to add the heterogeneous code of rosetta.....and the problems start!!

4858014
4857997

std::cerr: Exception was thrown:
File: C:\cygwin\home\boinc\Rosetta\main\source\src\core/pack/dunbrack/SingleResidueDunbrackLibrary.hh:306
chi angle must be between -180 and 180: -nan(ind)[/quote]

Still getting work units that run successfully but give very low credits, just 45 on average, for a 6 Hour work unit.
This is well down on what is normally issued for a work unit (up to 200+)

See WU 4872271
WU 4872276
WU 4872277
wu 4872279

This was on a 64 Bit Linux machine.

Conan

---

We just posted an update to version 4.08 for the Rosetta beta linux 64bit applicaton. This update includes a bug fix suggested by rjs5 which simply includes:

putenv("LC_ALL=C");

in the main function.

This bug affects the latest linux versions that use glibc 2.27+, for example Ubuntu 18.04 and Fedora 28.

Please post here if you are still experiencing the "loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed." bug with this updated linux app version.

4917343

<core_client_version>7.14.1</core_client_version>
<![CDATA[
<message>finish file present too long</message>
<stderr_txt>
command: ../../projects/ralph.bakerlab.org/rosetta_android_beta_4.11_arm-android-linux-gnu @1462.1_1_redo_alternatives_1462.1_1_cis_design_android.flags -nstruct 10000 -cpu_run_time 3600 -watchdog -boinc:max_nstruct 600 -checkpoint_interval 120 -mute all -database minirosetta_database -in::file::zip minirosetta_database.zip -boinc::watchdog -run::rng mt19937 -constant_seed -jran 1821896
======================================================
DONE :: 1 starting structures 5809.75 cpu seconds
This process generated 4 decoys from 4 attempts
======================================================
BOINC :: WS_max 0
called boinc_finish(0)

<![CDATA[
<message>finish file present too long</message>
<stderr_txt>

Uops, seems to be a boinc server's problem, not a ralph's problem
pull request 3300

Uops, seems to be a boinc server's problem, not a ralph's problem
pull request 3300

Boinc Server 1.2 version is released.

<core_client_version>7.14.1</core_client_version>
<![CDATA[
<message>finish file present too long</message>

Again and again
Please, fix it

SAME HERE "finish file present too long" message.
Task 4918499

Also see my topic on the BOINC ,message boards "Suddenly BOINC Android thinks my battery is too low".

This leads me to suspect the latest RALPH program is ignoring the BOINC RAM & storage settings.

I have disabled work request from this project on Android. When or if things are fixed here at RALPH I might consider letting it have access to my Android device. BOINC is supposed to play nice with our device(s) but when it becomes a P.I.T.A. and causes major problems the offending project(s) no longer get my resources.

---