does your preference setting of "Leave applications in memory while preempted?" make any difference to that strange behavior? Please try changing it (don't forget to update the project) and report.
At some point, when the BOINC manager is not correctly reporting the cpu time and/or progress, could you please look into the client_state.xml file and see if the cpu time and/or progress are correct there or are incorrect?
If client_state.xml is correct and the BOINC manager display is incorrect, then the problem is in BOINC manager. If client_state.xml is incorrect, then the problem is in the boinc core client.
You can find this client_state.xml in /Library/Application\ Data/BOINC/
this is caused by the SETI App which still has the bug we fixed in our 0.08.
In the SETI App suspending depends on which thread happens to catch a signal, so suspending might work some times, but not always. They need to rebuild their App, too.
It might be worth to piont out that this problem only applies to Apps which have a separate thread for the graphics. LHC, Predictor and CPDN I think thus shouldn't be affetected.
Seems that the 008 runs into a problem, probably in the FreeBSD layer. Will take some time to get this fixed. I can confirm that it _might_ hang, and if the screensaver is active, it's hard to get access to it without reboot. Sorry for that, this is Beta test. I suggest for now you turn off the screensaver function if you want to use the 008.
Hm. What is your "Switch between applications every" preference set to?
I'll take a look at that Workunit. Hm, hard to find the Result you were talking about - You mentioned a hostid 365364, I assume you mean 356364 (the latter one belongs to your account). This machine got sent a Result named "w1_0979.5__0979.6_0.1_T02_S4hA_3", which I suspect is what you mean.
Can you please take a look into your slots directories ("/Library/Application Support/BOINC Data/slots/*")? There should be two Files "Fstat.Ha" and "Fstat.Hb". How large are they? Is your diskspace getting tight?
If you want, you can abort the Result, I'll keep an eye on this Workunit. Maybe there's something wrong with the data. We had some WUs in S3 which caused that files to get very large, leading to long processing times at the end.
OK, I think David Anderson has figured out what's going on. The signal handler used by the BOINC application library to manage timers and suspend/resume operation is calling functions that are not async interrupt safe. This explains the random nature of these failures.
It may take a little while to figure out how to fix this.
David Anderson has "fixed" the BOINC API library bug that was causing unpredictable hangs in test app version 0.08. Bernd has just finished building and testing a new version 0.11 of the einstein application. Please download it from the app test page. Please continue to report success or problems with the Mac OS X test app to this discussion group thread.
One thing I have noticed is that BOINC may not be doing the best housecleaning on the slot directories....
It does. After the result file has been uploaded to the upload server, the slot directory in which it stays there until the result (and the upload) has been reported to the scheduler, e.g to keep the stderr output which goes into the database. Between these two actions the result is shown in the Manager as "uploaded", it vanishes from the work list along with the slots directory when it has been reported.
Alan, does your preference
)
Alan,
does your preference setting of "Leave applications in memory while preempted?" make any difference to that strange behavior? Please try changing it (don't forget to update the project) and report.
BM
BM
Alan, C, At some point, when
)
Alan, C,
At some point, when the BOINC manager is not correctly reporting the cpu time and/or progress, could you please look into the client_state.xml file and see if the cpu time and/or progress are correct there or are incorrect?
If client_state.xml is correct and the BOINC manager display is incorrect, then the problem is in BOINC manager. If client_state.xml is incorrect, then the problem is in the boinc core client.
You can find this client_state.xml in /Library/Application\ Data/BOINC/
RE: Under einstein 0.08, I
)
Robert,
can you name the Workunit or Result in question? This might be rather related to the data than to the App.
BM
BM
Shaktai, this is caused by
)
Shaktai,
this is caused by the SETI App which still has the bug we fixed in our 0.08.
In the SETI App suspending depends on which thread happens to catch a signal, so suspending might work some times, but not always. They need to rebuild their App, too.
BM
BM
It might be worth to piont
)
It might be worth to piont out that this problem only applies to Apps which have a separate thread for the graphics. LHC, Predictor and CPDN I think thus shouldn't be affetected.
BM
BM
Seems that the 008 runs into
)
Seems that the 008 runs into a problem, probably in the FreeBSD layer. Will take some time to get this fixed. I can confirm that it _might_ hang, and if the screensaver is active, it's hard to get access to it without reboot. Sorry for that, this is Beta test. I suggest for now you turn off the screensaver function if you want to use the 008.
BM
BM
Hm. What is your "Switch
)
Hm. What is your "Switch between applications every" preference set to?
I'll take a look at that Workunit. Hm, hard to find the Result you were talking about - You mentioned a hostid 365364, I assume you mean 356364 (the latter one belongs to your account). This machine got sent a Result named "w1_0979.5__0979.6_0.1_T02_S4hA_3", which I suspect is what you mean.
Can you please take a look into your slots directories ("/Library/Application Support/BOINC Data/slots/*")? There should be two Files "Fstat.Ha" and "Fstat.Hb". How large are they? Is your diskspace getting tight?
If you want, you can abort the Result, I'll keep an eye on this Workunit. Maybe there's something wrong with the data. We had some WUs in S3 which caused that files to get very large, leading to long processing times at the end.
BM
BM
OK, I think David Anderson
)
OK, I think David Anderson has figured out what's going on. The signal handler used by the BOINC application library to manage timers and suspend/resume operation is calling functions that are not async interrupt safe. This explains the random nature of these failures.
It may take a little while to figure out how to fix this.
Bruce
David Anderson has "fixed"
)
David Anderson has "fixed" the BOINC API library bug that was causing unpredictable hangs in test app version 0.08. Bernd has just finished building and testing a new version 0.11 of the einstein application. Please download it from the app test page. Please continue to report success or problems with the Mac OS X test app to this discussion group thread.
RE: One thing I have
)
It does. After the result file has been uploaded to the upload server, the slot directory in which it stays there until the result (and the upload) has been reported to the scheduler, e.g to keep the stderr output which goes into the database. Between these two actions the result is shown in the Manager as "uploaded", it vanishes from the work list along with the slots directory when it has been reported.
BM
BM