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.

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

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.

Oh, I've just updated my hosts with this version.
Why it is released, if it's full of bugs?
(that would look nice on the change list: "We've put more bugs in it than we and you combined could imagine")

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

That's a very deep question, and needs some background.

Somewhat more than two years ago, the US Government's NSF decided not to renew a research grant which paid the salaries of the three key workers who managed and maintained the BOINC project. Those workers lost their jobs.

The BOINC project was - nominally - handed over to the community to manage and maintain, but no preparation had been done: the community wasn't ready to receive it. It dropped into their lap, and they did nothing with it.

Two months ago, elements of the community came together in a working group to prepare procedures through which the community could pick up the responsibility which had been thrust upon it. I wrote about it here: I'm still a member of the group, and our work is ongoing.

In the meantime, the NSF has funded a new project which expands and builds upon the original BOINC project (described here). That needs some additional features in BOINC, and development work has started again.

The v7.8 branch/release is really intended as a simple refresh to ensure that there is a stable base for the new NSF work (which won't appear until v7.10), and to apply some needed updates like a new version of VBox compatible with Windows 10. But life is never as simple as that...

In the past, BOINC version releases have gone through a slow and extended process of alpha test releases, debugging, and re-releasing. It's taken months. The working group is moving towards more modern software practices where testing is a continual (and largely automated) process as code is written: that should allow new versions to be deployed practically 'on demand' as circumstances - like Windows and OS X updates - require them.

The v7.8.2 release is the first attempt at combining the old and the new ways of working. It's revealed where the gaps lie, and we're working to fix them: I had my own first bugfix accepted into the master codebase this morning - yay! Only 19 left to go...

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.

At the moment there is no official list of changes.

"Ageless" wrote:

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.

Source: https://boinc.berkeley.edu/dev/forum_thread.php?id=11818

Assuming the above lists, there are no new "features" or serious bugsfixes(for Windows/Linux).

Surprisingly, even have not been updated to the openssl library, stuck on version 1.02 g(release 1 Mar 2016] and bundle of root certificates(ca-bundle.crt) (30 April 2015).
Had to once again to do it manually : /

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

If anyone can get a similar report out of your Linux crashes (Linux and OS X are pretty similar behind the fancy graphics, apparently), could you post it here, please?

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?

Logs on their own probably won't help, although stderrdae.txt and stdoutdae.txt might have something. Could you look at the end of those files, please, and see if there's any mention of a failure around the time your problems started?

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:

[vsyscall]
SIGABRT: abort called
Stack trace (18 frames):
/usr/lib/x86_64-linux-gnu/libboinc.so.7(boinc_catch_signal+0x1d8)[0x7fd5504932ac]
/lib/x86_64-linux-gnu/libc.so.6(+0x357f0)[0x7fd5507287f0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x9f)[0x7fd55072877f]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fd55072a37a]
/lib/x86_64-linux-gnu/libc.so.6(+0x79090)[0x7fd55076c090]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x54)[0x7fd55080df84]
/lib/x86_64-linux-gnu/libc.so.6(+0x118f00)[0x7fd55080bf00]
/lib/x86_64-linux-gnu/libc.so.6(+0x1184b9)[0x7fd55080b4b9]
/lib/x86_64-linux-gnu/libc.so.6(_IO_default_xsputn+0xa9)[0x7fd5507709a9]
/lib/x86_64-linux-gnu/libc.so.6(_IO_vfprintf+0x1ccc)[0x7fd55074255c]
/lib/x86_64-linux-gnu/libc.so.6(__vsprintf_chk+0x84)[0x7fd55080b544]
/lib/x86_64-linux-gnu/libc.so.6(__sprintf_chk+0x7d)[0x7fd55080b49d]
/usr/bin/boinc(+0x9ddec)[0x560aa99fcdec]
/usr/bin/boinc(+0x7f9a9)[0x560aa99de9a9]
/usr/bin/boinc(+0x39e70)[0x560aa9998e70]
/usr/bin/boinc(+0xc4a9)[0x560aa996b4a9]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fd5507133f1]
/usr/bin/boinc(+0xec9a)[0x560aa996dc9a]

Exiting...

As for stdoutdae.txt, I just see the usual parameters such as upload and download rate, with no obvious problems. I will be happy to zip and send you both of them, if there is a way.

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?