Seeing as 7.0.25 became a release version its time for a new thread.

REMINDER TO ALL TESTERS
It's far easier 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.


If you are posting to this message thread please don't add signatures.


7.0.26 change log

- client simulator: compile fixes

- client: change some unsigned int to size_t in our versions of NVIDIA APIs. This apparently caused crashes (in app, not client, which I don't understand) for Einstein@Home. From Steffen Moller.

- client: don't write deviceHandle to NVIDIA XML description. Um, pointers don't have any meaning outside the process

- client: if we fetch a master file and it contains no scheduler URLs, show a message of class INTERNAL_ERROR

- client/scheduler: make CUDA_DEVICE_PROP.totalGlobalMem a double, and remove dtotalGlobalMem. Although NVIDIA reports RAM size as a size_t, there's no reason to store it as an integer after that.

- client: add PID to random stuff used to make host CPID, in case running multiple clients on same host

How is the beta test going on 7.0.26? I'm running down my cache before switching from 6.12.4x. I have 2 large WU almost done at 150 hours each done and don't want to risk a bobble on switch over on them. Looks like I'm going to be 5-6 days out before the switch could be done. So feedback and posts on how testing is going would be appreciated.

---

I tried Boinc 7.0.26 and had driver failure after driver failure

I lost all of my WU but got them back after putting 7.0.25 back in

It happened while I was running NV gpu astropulse and multibeam 610 fermi at the same time.
25 handles it fine.


Michael Miles

Ok looks like I's roughly 36-48 hours from clearing my big WUs. Ok what is the testing status for 7.0.26? any problems being reported? My system is a Mac running OS X 10.6.8. So any Mac specific bugs?
Thanks for any feedback you can give.


Edit I'm looking to get ready for Open CL apps that are coming so I need to do the switch from Bonc 6.x .x to Boinc 7.0.x for Open CL app support. I crunch other projects and one is hoping to start beta testing an Open CL science app in the next month. Need to run it for a bit so that the work fetch instabilities are worked out before I start doing the new beta work.

---

I'm running 7.0.26 on my Ubuntu server. (this is due to Ubuntu/Debian repository versions having a bug preventing many ubuntu/s@h users from crunching with CPUs) My system is Cpu only. I run s@h only.

I haven't had a problem noticed yet with the upstream 7.0.26

-Dave

Ok looks like I's roughly 36-48 hours from clearing my big WUs. Ok what is the testing status for 7.0.26? any problems being reported? My system is a Mac running OS X 10.6.8. So any Mac specific bugs?
Thanks for any feedback you can give.


Edit I'm looking to get ready for Open CL apps that are coming so I need to do the switch from Bonc 6.x .x to Boinc 7.0.x for Open CL app support. I crunch other projects and one is hoping to start beta testing an Open CL science app in the next month. Need to run it for a bit so that the work fetch instabilities are worked out before I start doing the new beta work starts.

There are some more bug fixes that will be included in 7.0.27, when they get it released is another story.

---

There are some more bug fixes that will be included in 7.0.27, when they get it released is another story.

Round-about-now. ;-)

---

There are some more bug fixes that will be included in 7.0.27, when they get it released is another story.

Round-about-now. ;-)

Already downloaded and installed.

---

There are some more bug fixes that will be included in 7.0.27, when they get it released is another story.

Round-about-now. ;-)

Already downloaded and installed.

And seems to work OK.

The extra logging for one of my bugs revealed *when* BOINC switched of its own accord into an undocumented mode, but not alas *why*.

7.0.27 change log

- client: only send active tasks in get_simple_gui_info GUI RPC.

- client: remove <std_debug> log flag.

- client: remove <zero_debts> config option.

- components under Windows, Update copyrights.

- client: add <suspend_debug> log flag.

- client/server: remove assert()s from message log code.

- MGR: Show() does not restore the window state from a minimized state. Use maximize(false) to handle that situation.

- client: fix bug that could erroneously cause a GPU to be "blocked by config file".

- client: fix function prototypes for CUDA detection.

- Added NVIDIA GPU platform detection to boinc_get_opencl_ids_aux()

- client: fix bug that caused a project's jobs to all be run EDF if the project has the <dont_use_dcf> flag set.

- WINSETUP: Fix long standing installer bug where we were attempting to add the boinc_master account to the boinc_admins group when installing in the non-service install mode. boinc_master is only created during service installs. This was causing a setup failure on Windows 8. As far as I can tell it should have also been failing on Win7 and Win Vista.

- update_versions: eliminate PHP warnings when no version.xml file.

- client: when showing how much work a scheduler request returned, scale by availability (as is done to show the amount of the request).

- client in account manager request, <not_started_dur> and <in_progress_dur> are in wall time, not run time (i.e. scale them by availability) Note: there's some confusion in the code between runtime and wall time, where in general wall time = runtime / availability. New convention: let's use "runtime" for the former, and "duration" for the latter.

- client: fix crashing bug that happened when a scheduler reply had a parse error, and it included project files. While parsing the scheduler reply we'd add FILE_REFs to PROJECT::project_files, but wouldn't link them to FILE_INFOs since this is done only if the reply parses correctly. The next garbage_collect() would dereference these NULL pointers. Solution: parse the FILE_REFS into SCHEDULER_REPLY::project_files. Copy this to PROJECT::project_files only if the reply parses.

- Bad logic in Win code: if you have *pbuf = HeapAlloc?(...)then you need if (*pbuf == NULL) not if (pbuf == NULL)

- various code cleanups from Steffen Moeller.

- client: enforce <no_gpus> in config file not just at startup, but also when config file is re-read. A first attempt to fix the bug where apps die with exit(1) (whereas they didn't do this w/ older clients). On Windows, the client uses TerminateProcess?(h, 1) to kill processes; the 1 is the exit code the process will appear to have. So instead, add a "will_restart" bool arg to the various kill functions, and if set use 0 (= STATUS_SUCCESS), otherwise use EXIT_ABORTED_BY_CLIENT. Note: in principle this shouldn't make any difference for quitting tasks, since handle_exited_app() checks for task state QUIT_PENDING and ignores the exit code in that case. The only place I can see where it would make any difference is when we kill a process because it hasn't been handling queued shared-memory messages for 180 seconds.

- client: add more info to the message about an exited app.

- client: function return values (ERR_*) are different from process exit codes (EXIT_*). But in many places we were using return values as exit codes. Fix these. Also, break out the different types of limits a job can exceed (time, disk, memory) into difference exit codes.

- compile fix.

- WINSCR: Use the DefProcHandler? function when processing WM_CLOSE/WM_DESTROY window messages. In effect, let Windows do the default thing. This removes the hacks which kept the screensaver running with old versions of Microsoft's keyboard/mouse driver software installed.

- client: if acct mgr sends us an account with no authenticator, show an error message instead of trying to attach.

- client: code cleanup. Move RESULT and PROJECT to separate files.

- client: minor code shuffle.

- client: if an app version needs OpenCL/CUDA/CAL, make sure that the GPU supports it (fix bug where sometimes, e.g. CUDA detection fails but OpenCL succeeds, and we have a CUDA app).

- Mac: Update XCode project with new source files.

- Manager: message tweak.

- Add new files to Win project.

- Mac installer: changes for OS 10.8 compatibility.

Does anyone know if the "code cleanups from Steffen Moller" and the "compile fix" will fix their (Debian package maintainers) issue with compiling Boinc?

Lol, this question is half rhetorical. I don't even know if Steffen himself knows that answer yet.

---

#resist

Any Problems found with 7.0.27 on OSX? I am now almost done with the WU clearing. I am down to one GPU task and am looking to update in about 2 hours.

---

Why the HECK is the BOINC 7.0.27 asking for a full computer restart to install(OSX 10.6.8 Mac Mini 2010 edition 8GB Ram GPU is a Nvidia 320M)?!?! That is not very friendly. No application that is not system software should require a full restart of the system. What are you wedging in on the instal that requires a full restart?

---

Why the HECK is the BOINC 7.0.27 asking for a full computer restart to install(OSX 10.6.8 Mac Mini 2010 edition 8GB Ram GPU is a Nvidia 320M)?!?! That is not very friendly. No application that is not system software should require a full restart of the system. What are you wedging in on the instal that requires a full restart?

I don't know the exact answer for the Mac OSX case, but in general the answer is "BOINC creates its own limited rights user accounts to run project applications."

It's known as sandboxing: BOINC will be downloading and executing programs from whichever project URLs you choose to paste into the 'add project' dialog. University based projects like SETI should only supply reputable, tested, safe applications - but you can never be certain.

If the applications are only allowed to run under a user account with restricted access to one specific data folder tree, there is less danger that a rogue application could damage the data on some other part of your hard disk.

My guess is that the restart is required by the operating system (once only - it won't be needed on future BOINC upgrades) to finalise the creation on the new accounts, and activate them.

For details, see http://boinc.berkeley.edu/sandbox.php

Answer from the developer:

Because the installer is removing the old boinc_master and boinc_project users and groups and creating new ones with different IDs, to solve some issues. The reboot is needed to guarantee that the OS recognizes the new values. This is a one-time thing; the installer won't require a reboot for further upgrades or reinstalls.

This change was recommended by Apple:

- Mac installer: follow recommendations of Apple Developer Technical Support: create users and groups boinc_master and boinc_project at first available UserIDs and GroupIDs starting at 501 instead of 25 to avoid conflicts with UserIDs and groupIDs which may be added in the future; use Directory Services to find the user names of all human users instead of stepping through the entries in the /Users directory.

---

Thanks for the quick replies. I will be installing now.

---

Thanks for the quick replies. I will be installing now.

Oh, ye fearless soul.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Thanks for the quick replies. I will be installing now.

Oh, ye fearless soul.

I need to not really want to. One of the projects I crunch is making a GPU science application. The project does not allow anonymous science apps and will only make an Open CL GPU app. Boinc 7.0.x is needed to support stock Open CL science applications on the project. I'm told you need at least 1 week before 7.0.x work fetch settles out to normal so If I want to have my instillation stable before the testing of the new App starts I need to start running it now a month ahead of when the testing is supposed to start.

---

Do you know already that the meaning of the work buffer settings has changed?

---

Christoph

Do you know already that the meaning of the work buffer settings has changed?

Yeah it has switched to a high tide low tide system. It will fetch work until it has at least the max number of seconds of work on board and not fetch again until it drops below the low tide mark. I need to watch this to see how it works on my machine. I don't plan to react to ups and downs until I see it at work in real life unless I see a huge work over fetch. Just let BOINc work it out for a bit and then see how it looks.

---