REMINDER TO ALL TESTERS:
It's far easier for us to fix problems if you send message logs with the appropriate flags set. The main flags are:

<cpu_sched_debug>: problems involving the choice of applications to run.
<work_fetch_debug>: problems involving work fetch (which projects are asked for work, and how much).
<rr_simulation>: problems involving jobs being run in high-priority mode.

Use these flags from the cc_config.xml file.

Report any problems you get with it to the Alpha email list. This list needs registration.


6.12.27 change log

- SCR: Fix Mac crash bug when user clicks SS Test button in system preferences.

- client: Detect processor counts when the number of processors exceed 64 on Windows.

- client: change the handling of account manager replies:
Old: If the AM sends us a project we're already attached to, and the authenticator is different, print an error message and don't change anything.
Problem: If the AM is using weak authenticators, and the user has changed their password, the weak authenticator changes. In this case the AM will send the new weak auth, the client will ignore it, and all subsequent scheduler RPCs will fail until the user removes/adds the project.
Solution: If the AM sends us a new auth for a project, use it. Note: From the time the password is changed on the project to the next AM RPC, the client will have a bad weak auth and scheduler RPCs will fail. That's OK.

- client: update to previous commit: only change the authenticator if both old and new authenticators are weak (strong authenticators don't change).

- client: add <http_transfer_timeout_bps> config option. Defines the transfer rate below which the connection is considered idle, and timeout starts

- client: implement "report immediately" at the level of individual jobs rather than globally. To use this, projects must add <report_immediately/> to the <result> elements in job templates

- client: don't check memory usage immediately after hibernation

- client: show HTTP errors in text form as well as number

- client: fix problem with recursion in dir_size(), this time for real.

- client/manager: don't show resource usage for non-CPU-intensive jobs

- client: XML-escape the contents of stderr files; otherwise non-ASCII characters in client_state.xml make it invalid XML

- client: fix (I think) to scheduling logic. a job is preemptable if it's finished its time slice and
Old: has checkpointed in last 10 sec
New: has checkpointed since the end of the time slice

- client: Account for new registry location that the new VirtualBox installer stashes the version number. Check the new location first, if not found go back to the original location.

- client: add log messages showing steps in exiting all tasks, enabled by <task_debug/>

- client: remove redundant task-start messages

- client: on hibernate, don't wait for apps to exit (NCI apps never will)

- client: if project is set to "don't request more work", report completed tasks immediately

Attention please. Hold your upgrades and wait for 6.12.28 or for server side fixes.

- client: XML-escape the contents of stderr files; otherwise non-ASCII characters in client_state.xml make it invalid XML

breaks stderr output - contains now illegible html codes

Requires a serverside fix. Please wait with upgrading until we are reasonably sure that has been done and is live.

---

Carola
-------
I'm multilingual - I can misunderstand people in several languages!

Then maybe 6.12.27 have to be removed from this page:
http://boinc.berkeley.edu/download_all.php

(Who is "hardcore" tester still can get it from:
http://boinc.berkeley.edu/dl/?C=M;O=A
)

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 

Then maybe 6.12.27 have to be removed from this page:
http://boinc.berkeley.edu/download_all.php

Why? It has a disclaimer that it might be unstable.

Then maybe 6.12.27 have to be removed from this page:
http://boinc.berkeley.edu/download_all.php

Why? It has a disclaimer that it might be unstable.

1) I said "maybe"
2) In this case it's not just "it might be unstable" - it looks like "it is unstable" (= known big bug)!
(so "hide" this version in less known place http://boinc.berkeley.edu/dl/?C=M;O=A)

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 

Then maybe 6.12.27 have to be removed from this page:
http://boinc.berkeley.edu/download_all.php

(Who is "hardcore" tester still can get it from:
http://boinc.berkeley.edu/dl/?C=M;O=A
)

Good idea - I've passed on the message.

David Anderson has just posted

Don't change server code.
We'll fix the problem in the client.
-- David

so v6.12.27 is definitely withdrawn.

@ Ozz - I did a lot of testing with v6.12.27 yesterday, and it was fully 'stable': but I was looking for other things (CUDA stability under Windows fast user switching) - I didn't notice I was polluting all my attached project databases with garbage overnight. We know that disclaimer is put on all development versions automatically - some of us haven't run a 'recommended' version for 9 months or more. I think this bug warrants a recall.

so v6.12.27 is definitely withdrawn.

And already replaced by 6.12.28 (I was just thinking of an immediate downgrade :)

Peter

so v6.12.27 is definitely withdrawn.

And already replaced by 6.12.28 (I was just thinking of an immediate downgrade :)

Peter

I'll upgrade one host.

And check it more carefully this time :)

And first result reported: task ID 1922789669. Stderr output looks legible again.

I'm running BOINC x86 6.12.26 on my LT (T2400;2GiG DDR2;WIN XP x86), no
problems with this version?
Works OK, SETI and CPDN.

My 3 QUADs and i7-2600, all have BOINC 6.10.60, 2 64BIT and 3 32BIT. (Laptop)
(One WIN XP64; 2 WIN XP x86; 1 VISTA x86 and WIN7 64BIT.)

---

I had an interesting problem with 6.12.26. I installed it on my main machine and it was running fine. About a day later, I wanted to test a GPO that only allows me to log into my computer and denies access to any other account on my domain, so I asked Michele to try to log into my computer. I logged off my account and let her try, and she was rightly denied access. So I logged back in as myself and found that BOINC suddenly lost all configuration data. Uninstalling 6.12.26 and reverting back to 6.10.58 seems to find all my projects and configuration data again (which was always there to begin with).

I had an interesting problem with 6.12.26. I installed it on my main machine and it was running fine. About a day later, I wanted to test a GPO that only allows me to log into my computer and denies access to any other account on my domain, so I asked Michele to try to log into my computer. I logged off my account and let her try, and she was rightly denied access. So I logged back in as myself and found that BOINC suddenly lost all configuration data. Uninstalling 6.12.26 and reverting back to 6.10.58 seems to find all my projects and configuration data again (which was always there to begin with).

Depends how that GPO works. "Lost all configuration data" could describe a situation I encountered during testing: BOINC - specifically the BOINC installer - had set the permissions on the BOINC data directory in such a way that only members of certain user groups could access them. I, as a member of local group boinc_admins, could read and write the data directory without problems: my test account, not a member of that group, was denied access, with error messages like

24-May-2011 12:33:53 [---] Can't open client_state_next.xml: fopen() failed
24-May-2011 12:33:53 [---] Couldn't write state file; check directory permissions
24-May-2011 12:33:53 [---] Can't create HTTP response output file all_projects_list_temp.xml
24-May-2011 12:33:53 [---] This computer is not attached to any projects
24-May-2011 12:34:44 [---] Can't write state file, exiting in 10 seconds
24-May-2011 12:34:54 [---] Can't write state file, exiting now
24-May-2011 12:34:54 [---] Time to exit
24-May-2011 12:34:54 [---] Can't open client_state_next.xml: fopen() failed

It would have been interesting to know whether a 'repair' installation of v6.12.26, which checks/regenerates user groups and directory permissions, would have had the same effect as uninstalling and re-installing an older version.

Depends how that GPO works.

In the GPO I simply used the policy "Allow log on locally" and set it to my user account.

All this does is prevent people from logging on to my local machine, and it did so in that Michele was not able to log on.

"Lost all configuration data" could describe a situation I encountered during testing: BOINC - specifically the BOINC installer - had set the permissions on the BOINC data directory in such a way that only members of certain user groups could access them. I, as a member of local group boinc_admins, could read and write the data directory without problems: my test account, not a member of that group, was denied access, with error messages like

<snip>

It would have been interesting to know whether a 'repair' installation of v6.12.26, which checks/regenerates user groups and directory permissions, would have had the same effect as uninstalling and re-installing an older version.

I think the permissions and GPO are red herrings. In short, all that happened was a legal user logged off, an illegal user attempted to log on and failed, and the legal user was able to log back in, which is my personal account which should have already had the appropriate permissions on the BOINC data directory, and is a member of the BOINC_Admins group as well.

[Edit] Interesting. I tried to re-create the exact situation by upgrading to 6.12.26 again with the same options I used before (don't install as a service, don't use the screen saver, and do not allow other users to control BOINC), and waited for the benchmarks to finish.

I then logged off my account and tried logging in with my test account, and was rightly denied access. I logged back in as myself and BOINC was still working.

I can't seem to re-create the same scenario. Too bad as I would like to know what caused it to behave as it did, and now all we'll have are guesses.

I think the permissions and GPO are red herrings. In short, all that happened was a legal user logged off, an illegal user attempted to log on and failed, and the legal user was able to log back in, which is my personal account which should have already had the appropriate permissions on the BOINC data directory, and is a member of the BOINC_Admins group as well.

So, if you are calling 'bug' on v6.12.26 - on the grounds that it lost all configuration data - and you don't think it's a permissions issue (although the data was present all along for v6.10.58 to find), do you have any idea of a failure mode which could explain the lost configuration data? Is there any evidence logged in stdoutdae.txt?

If we could work out what the problem was, or find evidence to point the finger, then we have a chance of getting it fixed. Without fixing things, we're stuck with the lousy GPU support of v6.10.xx (well, ATI users, in particular, are stuck with lousy GPU support).

[Edit - cross-post while you were editing. But stdoutdae.txt should have survived all the changes - if there's any evidence to be found, that's where it'll be]

I'm not seeing anything relevant in stdoutdae.txt between the times I installed BOINC 6.12.26 the first time and then reverted back to 6.10.58.

Guys! Where I can find change log for new 6.12.28 version? Thank you in advance

I'm not seeing anything relevant in stdoutdae.txt between the times I installed BOINC 6.12.26 the first time and then reverted back to 6.10.58.

If we agree that "Suddenly lost all configuration data" sounds like the client (and/or Manager) lost access to BOINC data dir, then there is nothing written to be expected :-(

Peter

Guys! Where I can find change log to new 6.12.28 version. Thank you

You can find a moderated log here.

Peter

I'm not seeing anything relevant in stdoutdae.txt between the times I installed BOINC 6.12.26 the first time and then reverted back to 6.10.58.

If we agree that "Suddenly lost all configuration data" sounds like the client (and/or Manager) lost access to BOINC data dir, then there is nothing written to be expected :-(

Peter

I found the log entries I quoted in message 1109772 in stdoutdae.txt: even though the record states that BOINC was unable to access files in the data directory, it was able to append that data to the existing log file. It was worth a look.

After the 6.12.27 issue we resume our normal programming...

6.12.28 change log

- MGR: Fix shutting down of Client on Linux

- client: escape only non-ASCII chars in stderr out, not control chars