Hello fitze,
Here is an earlier signal 9 problem:
https://secure.worldcommunitygrid.org/forums/...ead,36068_offset,0#445709
Maybe using only 1 core will work? If so, increase core count till you run into problems.

Lawrence

Could this be the problem of all the errors?

When Boinc loads it does not look at the available memory it needs to run. (256K Ram
is the minimum). If you have less like I did 202K it still loads and will run a task, not
knowing it needs a minimum of 256K of free space Ram available.

This is a most unlikely problem. The agent is supposed to pause when there's a shortage of ram, however many tasks with 'waiting on memory'. Also, if peak memory use recorded on windows for fahv tasks is 38mb and on linux is 42mb, why would the android version have a balloon requirement? For good order, the 250mb as specified on the system requirement page is a test level at point of work assignment. Why that high? One possible is to be very save even with a quad I'd venture to guess, certainly most projects never ever get close to the specified requirement, and then actually if, they do specify exceeding memory or maximum allowed storage space when going belly up, not a dumb kill.

In development, it seems latest code includes sending back actual usages with the results for server side statistics. Whether wcg code is registering that, don't know. Only wcg technicians would know from zillions of bombed results on '195' why the client decides to sigkill the tasks at such an excessive incidence rate.

For those who want to check, don't know if android agents can be attached to this project, wuprop would be the 'go to' place to verify for yourself what the usage statistics are per platform. It's nci, only using a fraction of cpu time just as quake catcher network which I'm running on the network. Think this one only runs when on charger as it needs to be stable on a desktop to detect tremors and not the dancing in your trouser pocket.

My current phone returns error after error. My old phone works great.

I am sure there are several differences between them but let me know when there is a fix and I'll turn it back on.

Thanks.

There's this question of 'we'll keep you posted' that comes with 65000 greenbacks. Something improved, maybe just utter coincidence, android 4.4.4, only openssl fixes over 4.4.3. The result for the tablet, still listed with a generic 'android', opposed to the proper identifier as shown on the result status pages, 8 results validated in 24 hours, a record

07/21/2014 		0:002:20:00:16 		1,981 		8
07/20/2014 		0:000:19:53:47 		487 		2
07/18/2014 		0:002:12:41:44 		1,941 		5
07/17/2014 		0:001:17:51:49 		1,429 		4
07/16/2014 		0:001:01:34:36 		1,208 		2
07/14/2014 		0:000:17:02:14 		637 		1
07/13/2014 		0:000:22:42:03 		879 		2
07/11/2014 		0:000:11:20:14 		462 		1
07/10/2014 		0:001:03:39:44 		940 		3
07/06/2014 		0:001:12:02:41 		1,924 		3
07/05/2014 		0:000:09:04:32 		370 		1
07/04/2014 		0:000:12:24:23 		667 		1
07/03/2014 		0:000:14:08:21 		684 		1
07/01/2014 		0:000:14:25:21 		877 		2

Last error occurred actually on the 18th, 4 days ago. Meanwhile, courtesy of a silent member, the android history shows, ahum, 245k credit, lowest since long, but it could have been a supply chain issue, some members, including myself, reporting lack of vina work. That lapse lasted 18-20 hours. Maybe this sets off another run, the june hike not evident why happening, then tapering off again, discovery made nothing improved, more volunteers lured and ticked off, and ticked off is lost most often forever. Of course at ibm they look at it in business perspective, where 245k credit on 100 million, after to-the-day exactly 1 year in production, is hardly worth the bother. Got better things to do