• How do you think about to achieve any further insights for the program “/var/lib/boinc/projects/boinc.bakerlab.org_rosetta/vboxwrapper_26198_x86_64-pc-linux-gnu”?
  
• How should the software components evolve according to information like the following?
  

/var/lib/boinc/slots/0/stderr.txt:
“…

2021-12-27 13:33:32 (3837): Detected: VirtualBox VboxManage Interface (Version: 6.1.30)
2021-12-27 13:33:38 (3837): Error in host info for VM: -1041038848
Command:
VBoxManage -q list hostinfo 
Output:
VBoxManage: error: Failed to create the VirtualBox object!
VBoxManage: error: Code NS_ERROR_SOCKET_FAIL (0xC1F30200) - IPC daemon socket error (extended info not available)
VBoxManage: error: Most likely, the VirtualBox COM server is not running or failed to start.

2021-12-27 13:33:38 (3837): WARNING: Communication with VM Hypervisor failed.

• aaai-SAR_pp-mNMABU-AGLY-ACBEN2_pp_8_2756113_1
  
• aaqb-SAR-mALA-AMACBEN4-mACPenC12C_pp_5_2805265_1
  
• boinc_cages_IL_2728657_84362
  
• boinc_cages_IL_2728657_84423
  

How can remaining open issues be resolved here?

I saw few situations when R@H cause errors on other application.

[...], and without exception, every unit results in "client error."

... - have you thought of external "consulting" from the volunteering programmers from the BOINC or Free/Libre/Open Source Software community?

I do realize there can be many secrets and fears of being copied involved

- but additional IT resources could be very potent: both in generating new and higher quality, reviewed code as well as higher reliability and recognition within our communities.

These are understandable concerns which we have sometimes a hard time to answer.

I remember seeing on this forum a very brief remark of a volunteer who saw some actual code and I thought it was a positive experience for both sides.

I've read elsewhere that they charge for a commercial version of the source code.

That appears likely to provide a major part of their income, so do you expect them to make it free?

You could, in principle, get a copy of the base code through the UW - as you know.

If you're serious and committed about volunteering to do testing/debugging of the Rosetta@home code, it might be worth emailing David Baker to volunteer in such a capacity, but I can't make any guarantees that anything will come of it.

Markus, it sounds like you a mixing the ideas of the project team (which needs to gather information across the whole of the project) with a individual user (which needs information about their own machines and potential problems they may be having).

Each BOINC project also tends to have a variety of types of work, each of which might warrant it's own bucket of statistics.

On the other hand, some symptoms and messages and outcomes are common to general causes, such as memory exceptions, or common to specific Operating Systems.

If some logic to analyze the output in general terms were incorporated into BOINC, all of the projects could benefit from such a thing.

The code that's being run on Rosetta@home corresponds to a fairly recent snapshot of the main Rosetta development branch.

The code that's being run on Rosetta@home corresponds to a fairly recent snapshot of the main Rosetta development branch.

I believe that there's provisions for interested third parties to get access to the development source code as something like a "consultant" (...).

Probably an easier course of action is to post whatever information about the crash you have here to the forums.

Hopefully one of the other posters will recognize it as an existing issue and offer you a workaround, or perhaps one of the developers will be able to diagnose and fix it.

That might not help you exactly, as the version which is on Rosetta@home isn't the same as the released version.