Task 4113884 completed in 140687s (~39hrs) claimed 1869.04. That is about 5000s (3.5%) slower than units completed with 4.33.

This Result was returned with what seems a bit large runtime.

4089386

The reason time is out of whack compared to the other I have returned is at 45 hours had a crash. One WU restarted fine this one started from zero.

____________
Thanks to Paul and Friends
Please consider a Donation to the Seti Project

Found a second linux host, which has at least 50% longer runtimes with APv4.34 compared to APv4.33. Check the tasklist of hostid 23827. I think that verifies my earlier statements: APv4.34 on linux has a problem.

This Result was returned with what seems a bit large runtime.

4089386

The reason time is out of whack compared to the other I have returned is at 45 hours had a crash. One WU restarted fine this one started from zero.

Josh

This occurred during testing of BOINC 6.2.12 and a machine lockup. After banging on the keyboard for about 5 minutes and no response it was the Power Off Button.

A near as I can figure the statefile was probably open for "file write" when the power went away. When Astropulse restarted it could "not open" an "already open" statefile.

To test for it I suppose that you could set a semiphore when the file is open, and check for the semiphore when AP can not open/write to the statefile. Then Issue a Statefile::close command.

This Result was returned with what seems a bit large runtime.

4089386

The reason time is out of whack compared to the other I have returned is at 45 hours had a crash. One WU restarted fine this one started from zero.

The lines in stderr that say:

In ap_fileio.cpp, Statefile::write, statefile is 0'd, trying again: iteration 100
Statefile::Read: 2 iterations with 0'd statefile.

mean that this WU encountered the "0'd statefile" problem, which is unrecoverable since the statefile is corrupt. So the application has to start over. Evidently the application is capable of finishing successfully in spite of this problem, which I wasn't sure about. I still don't know why the statefile gets corrupted.

Sigh! I have yet to successfully complete one of the these AP tasks. Here is my latest failure.

At ap_graphics_init
boinc_graphics_make_shmem failed: 0

Jim

Just completed two more AP4.34 wu’s Pending.

(4146632)42:44:16 claimed 1869.04

(4148192)42:32:10 claimed 1869.04

I just reproduced the problem on my own machine. The problem appears to be that 4.33 was compiled with optimization (-O2) and 4.34 was not. The public version will be compiled with optimization. Thanks for pointing this out.

....In the process, it creates a file called zeroed_statefile_log.txt. The number in the file represents the number of times it has tried so far. (Don't change the number.)

Let me know if this happens to you ...