You can download it from Berkeley's website.

What are the changes? I can't find any info about it (?).

You can download it from Berkeley's website.

You can download it from Berkeley's website.

But I advise you not to bother, unless you're a masochist. It's riddled with bugs.

Why it is released, if it's full of bugs?

Thank you for your work, and for this explanation.

Nice to know. Keep us posted.

gdf

I've updated on Win 10 x64 creator's edition, and I have not noticed any bugs.

Thanks for your dedication, Richard!
____________

In particular we would like to know what is the status of virtualization because we are trying to setup in gpugrid a CPU application for which there is only a Linux distribution.


g

Ok, so what are the changes?

In release notes there is no info about this version.

Ok, so what are the changes?

In release notes there is no info about this version.

I asked the release manager and he hopes someone else will do them. So it's anyone's guess.
I have an unofficial change log thread over on the BOINC forums: https://boinc.berkeley.edu/dev/forum_thread.php?id=11539 but we're not sure all those changes between 7.6.33 and 7.7.2 and BOINC 7.8.0 are in there. Only the release manager knows, and he won't tell.

I have (or had) BOINC 7.8.2 installed on three Ubuntu 17.04 machines and one Win7 64-bit machine with no problems. That is, until BOINC crashed (manager could not connect to client) on one of the Ubuntu machines. Even after a reboot it did not work, which I don't recall ever seeing before. So I uninstalled BOINC, and went back to 7.6.33, but it was still borked. The only other thing I can think of is that VirtualBox 5.1.28 was installed, but not attached to any projects, and removing it did not fix anything.

I would not normally mention it here (GPUGrid was not in use on that machine), but it is so unusual that maybe it has something to do with the BOINC 7.8.2 bugs. I have to reinstall the OS, and will stick with 7.6.33.

I don't think that's a known problem with v7.8.2 (most of the bugs are more subtle than a downright crash), but it's hard to be sure from the information given. The most common cause of 'manager couldn't connect to client' is that the client isn't running: I'm not sure exactly what logs you get in Linux when an application tries, but fails, to start - that would have been the place to look, but it's probably water under the bridge now.

In the meantime, Jord has posted the most significant change logs known so far.

OK, I thought it might be a bit much for a mere bug. I have not reinstalled yet, so I will look for any logs, and post as necessary.

Normally, I would expect a severe problem to take out the OS, but it seems that only BOINC was affected. I was running only CPDN and WCG, which should be relatively benign, though CPDN requires installation of the 32-bit libraries. That has worked for month on two machines, but it is possible that a bad work unit might trigger something I suppose.

I experienced the exact same thing yesterday too (as Jim1348)!
Lubuntu 16.04
BOINC 7.6.33
AMD Ryzen 1700x (it is my only Linux box, and you see still the abandoned gpugrid task in the log)
Running climateprediction and gpugrid, maybe a primegrid wu on the cpu as well.
This machine was running rock-solid for several months without restarting or any other intervention from my side. And then suddenly disconnected from BOINC client. I have not been able to reconnect either.
I reinstalled everything and up-graded to Lubuntu 17.04 as I assumed this might have been the problem. The computer is running again.}
Very strange!

And behold, after we'd all written that, we get a report of an apple client crashing at startup.

That user posted:

After some digging, I found that the client is crashing pretty much immediately, with the following stack trace on thread 0:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff90e0fd42 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff90efd457 pthread_kill + 90
2 libsystem_c.dylib 0x00007fff90d754bb __abort + 140
3 libsystem_c.dylib 0x00007fff90d75d7e __stack_chk_fail + 205
4 boinc 0x0000000100053d9d 0x100000000 + 343453
5 boinc 0x00000001000531e4 0x100000000 + 340452
6 boinc 0x00000001000520e6 0x100000000 + 336102
7 boinc 0x0000000100051ce0 0x100000000 + 335072
8 boinc 0x000000010002d80d 0x100000000 + 186381
9 boinc 0x000000010002dad5 0x100000000 + 187093
10 boinc 0x0000000100001034 0x100000000 + 4148

I found and saved my BOINC logs, but don't know which one it is. But I have wiped out the OS, so can't do a "stack trace" now. Does that do you any good?

I found and saved my BOINC logs, but don't know which one it is. But I have wiped out the OS, so can't do a "stack trace" now. Does that do you any good?

In stderrdae.txt, I see "buffer overflow" at the beginning and " [vsyscall] SIGABRT: abort called Stack trace (18 frames):" at the end, with a whole lot in between.

Here is the last part in full, but if you need more, let me know:

I don't know yet whether they'll be any help, but please keep them in a safe place in case we need to call for them. Just to be certain, can you be sure (from file timestamps or however) that this stack trace comes from the time when you were running v7.8.2 under, I think you said, Ubuntu 17.04?

I don't know yet whether they'll be any help, but please keep them in a safe place in case we need to call for them. Just to be certain, can you be sure (from file timestamps or however) that this stack trace comes from the time when you were running v7.8.2 under, I think you said, Ubuntu 17.04?

I have (or had) BOINC 7.8.2 installed on three Ubuntu 17.04 machines and one Win7 64-bit machine with no problems. That is, until BOINC crashed (manager could not connect to client) on one of the Ubuntu machines. Even after a reboot it did not work, which I don't recall ever seeing before. So I uninstalled BOINC, and went back to 7.6.33, but it was still borked. The only other thing I can think of is that VirtualBox 5.1.28 was installed, but not attached to any projects, and removing it did not fix anything.

That is a very nice summary, and I (and a lot of other people) are fortunate that Richard visited this forum at the right time. I would add only that the problem does not appear to affect the Windows version of BOINC on CPDN, though it is not clear why not.

I would add only that the problem does not appear to affect the Windows version of BOINC on CPDN, though it is not clear why not.

All reported cases of "won't connect, won't run, won't even run with old version" have now been traced to a newly released batch (batch 658) of CPDN climate models - sprecifically, WAH2 for the PNW region. These tasks all fail after one simulation month under Linux and OS X (CPDN are trying to track down the reason for that - their problem). When the tasks crash, they leave behind a huge crash dump in stderr_txt, and 51 failed upload messages.

BOINC - all current versions - can't cope with that much error information, and fails with the symptoms described here. There are two known recovery routes:[...]