On the server status page I spotted the availability of the new gravitational wave tuning run, and promptly increased the requested queue size of my hosts in hopes of getting this new type of work.
Three of my four machines promptly received work, and as the deadline was short, they promptly started the new tasks as otherwise in deadline trouble (so-called high priority).
All four tasks of this type which my machines have started on three different hosts have gone to computation error immediately. They are listed with status "Error While Computing" on the web page task list, show status in the history page of BOINCTasks as "Reported: Computation error (309,)", and have the same stderr appearance.
All show the exit status as -1073741515 (0xffffffffc0000135) Unknown error number
error task 1 on Stoll6
error task 2 on Stoll6
error task on Stoll7
error task on Stoll8
Copyright © 2024 Einstein@Home. All rights reserved.
Immediate Computation error with Gravitational Wave search O1 al
)
Promoted the one WU I got to run immediately and got the same error as you.
RE: All show the exit
)
May I remind you of the exchange we had about six months ago? Message 141791
"Error code 0xc0000135 (as it's usually written) means "The application failed to initialize properly", and that's usually because of a missing DLL."
Dependency Walker is an excellent tool for finding out what the application expects to have available, so that you can compare that with what the project have supplied.
I've pretty much completely
)
I've pretty much completely forgotten that exchange, sadly.
Is that one where we eventually decided that Kaspersky was silently blocking something?
On the small chance that the app_version portion of client_state.xml is of interest this time, here it is from Stoll6:
I downloaded dependency walker, and pointed at the indicated executable.
The file not found complaint list seems to be this:
The most likely thing that
)
The most likely thing that happened is that the developer forgot to include the LIBSTDC++-6.DLL in the package. Or that the executable should have been linked statically instead of dynamically.
The server status indicates
)
The server status indicates that of 207 tasks distributed up to 11 Feb 2016, 15:55:01 UTC, already 41 have reported back failed.
I doubt so very many of are running Kaspersky--but of course there may be other problems mixed in with the one I and Logforme are reporting here.
We are aware of the problem
)
We are aware of the problem and will deploy a new application soonish. I halted the distribution of work for now. There are some other problems that surfaced and need taking care of but nothing critical so far. Remember that this is still a Beta test.
Wonderful, Christian. I
)
Wonderful, Christian.
I was only trying to be helpful, and will be quiet now.
Got two tasks on this host
)
Got two tasks on this host that both failed with error message: 114 (0x72) Unknown error number. stderr output here.
Update: * We released a new
)
Update:
* The error code 114 is because the work generator didn't include enough data files. I fixed that calculation but can't change the already created tasks. It also does not affect all tasks so I cancel them as they come in. The next batch of tasks will not have this problem.
* The problem with missing result files was also addressed and should not happen for tasks that are send out today.
On seeing the good news that
)
On seeing the good news that some fixes were in and some work available, I fished for and got new "tuning" work for three of my four hosts.
On two of them the new work so far is running at the 25 to 30 minute point without obvious complaint.
However the third host Stoll8 has so far downloaded three of the units, started each immedidately (short deadline plus appreciable work queue), and failed after about 4 elapsed seconds with a new (to me) error syndrome.
Here are the links which can show the task stderr files:
Stoll8 error task 1
Stoll8 error task 2
Stoll8 error task 3
For all three:
1. The exit status on the task page shows as
114 (0x72) Unknown error number
2. a message at the beginning of stderr asserts
3. a notation interior to the stderr says something like
with some more lines after that.
I've disabled new CPU work request on Stoll8, as it might repeat that syndrome, which seems unhelpful, and of course allowed the other two to continue.