@all who experience Android app crashes
I would recommend to install NativeBOINC instead of Berkeley's one and activate BugCatcher mode there.
Here is article about this feature:
http://nativeboinc.org/site/for_users/bugcatch

A Bug report contains:

a Android version
a kernel version
a smaprthone model info
a NativeBOINC version
a catch time
program command line
signal informations (signal number, signal code, exit code)
additional signal info (system time and user time for process)
process state (registers, memory mappings list)
a process stack

Just what Eric needs.

@Eric
Look prev messages from Mateusz. He provided some logs from crashing app. Maybe needed info can be extracted from there?
No crashes on my phone (I'm running under NativeBOINC so "bug-catcher" should be available).

Previous messages where?

Hm... Can't find them. I thought I saw them in very this thread...

Mateusz did post in this thread, under the user name 'matszpk' - message 46628.

He didn't post any logs here, but he invited us to read

http://files.nativeboinc.org/bugcatcher/setibeta/

Just FYI, my two host ARMv6 64495 and 64415 are running fine new app 7.09

---

Descarga gratuitamente y comparte mi primer eBook: Amaneceres

More bad news about 7.08 app.
Both tasks were frozen on one of my tablets. After BOINC restart both returned to last checkpoint time ~17 hours instead of already done 90h. So, more than 70h lost for nothing. Test continues after restart...

BTW, anyone has fully completed 7.08 result already?

EDIT: more info about hung tasks: both are VLARs.
Also, in stderr of 7.08 app identifies itself as 7.07, one more cosmetic bug.

BTW, anyone has fully completed 7.08 result already?

On my ODROID-U2 (Exynos4412) all WU finish (7.07,7.08,7.09) without problem.
Runtime/credit with 7.08, 7.09 is very bad.
http://setiweb.ssl.berkeley.edu/beta/show_host_detail.php?hostid=64579

cu JagDoc

Yeah... the same as on Eric's own device (it has completed 7.08 too aready):

opt NEON folding 0.013907 0.00000

But on my device it's: opt VPF folding

That is, another code path used. And folding per se is VERY important for VLAR tasks (most load on folding there).

So, I reformulate my inquiry:
Has anyone completed 7.08 tasks with opt VPF folding used ?

EDIT: Well, things are even more complicated. opt VPF was on some of previously completed tasks (7.07 app).
Currently Samsung mini uses: swifold (default) and G-tab uses vpfFoldMain (CPU Caps)

But both are not NEON still so ..

There's little difference in speed on most devices for the VFP vs NEON folding paths, and I guess we'll see if continues to think VFP folding is faster on your device. VFP is faster for finding power spectra on most decives.

Right now there have been too few results on most devices to decide which versions are faster. It's so heavily dependent on the angle range of the workunits.

On the Samsung mini and G-tab, it has decided there isn't enough memory to bechmark the routines. That's why you see (default) or (CPU Caps) rather than an benchmark timing. It's deciding based upon what it sees in /proc/cpuinfo. It turns out that some manufacturers' android kernels don't populate /proc/cpuinfo properly.

---

Right now there have been too few results on most devices to decide which versions are faster.

FYI, here are the current number of non-outlier validated results for each app version.

armv7a 7.07: 104 results
armv6 7.07: 25 results
armv6 7.08: 14 results
armv6 7.09: 3 results

There are quite a few of each waiting for validation. We consider 100 results for an app_version to be the minimum before we can think about relative efficiency of different app versions.

---

It's deciding based upon what it sees in /proc/cpuinfo. It turns out that some manufacturers' android kernels don't populate /proc/cpuinfo properly.

My G-tabs have custom kernel, not manufacturers one. It's Cyanogen mod.

We consider 100 results for an app_version to be the minimum before we can think about relative efficiency of different app versions.

I'm afraid if apps will continue to work SO slow on my device I will never see completed results.

EDIT: my point not that VPF per se so slow, the point is that something wrong with 7.08. I have few completed 7.06 andd 7.07 already. Not so bad times and they used VPF too...

BTW, what difference between 7.08 and 7.09 ?
I see 7.08 deprecated already. Maybe worth to abort and download 7.09 ? Or ?

And yes, no memory size in /proc/cpuinfo. Memory not even mentioned at all (cause device rooted I can look the file easely)

And yes, no memory size in /proc/cpuinfo. Memory not even mentioned at all (cause device rooted I can look the file easely)

I haven't looked where BOINC gets memory size. Probably /proc/meminfo. The dividing lines on android are currently...

#define MIN_TRANSPOSE_MEMORY static_cast(512*MEGABYTE)
#define MIN_TRIGARRAY_MEMORY static_cast(384*MEGABYTE)

MIN_TRANSPOSE_MEMORY is the minimum system memory required before S@H will transpose the POT vs frequency array. MIN_TRIGARRAY_MEMORY is the minimum memory for caching sin and cos values for chirping (a lot of the SIMD routines don't do that anyway).

We also use MIN_TRANSPOSE_MEMORY to decide whether to benchmark routines or just choose based on the CPU capabilities. Running the benchmarks can boost memory usage to over 50MB from the typical 32MB. That often enough to get S@H killed on a 256MB android, in which case it ends up restarting and getting killed over and over.

For normal unix systems that have swapping, we use
analyzeFuncs.h:#define MIN_TRANSPOSE_MEMORY static_cast(96*MEGABYTE)
analyzeFuncs.h:#define MIN_TRIGARRAY_MEMORY static_cast(64*MEGABYTE)
but since android typically doesn't, it kills processes without warning to free up memory. I've considered doing memory allocations on android through memory mapped files, but I'm concerned what it would do to the lifetime of a phone's internal flash memory.

---

BTW, what difference between 7.08 and 7.09 ?
I see 7.08 deprecated already. Maybe worth to abort and download 7.09 ? Or ?

The major difference is additional prefetched transpose routines. They don't seem to make much difference, so carry on with 7.08.

---

but since android typically doesn't, it kills processes without warning to free up memory.

Does it do that for all processes? Or services are safe? I saw game killed on my phone when I switched off and started some other stuff, but never saw NativeBOINC killed. Not single time. Maybe some flags exist to restrict Android runtime from memory gathering that way?...

EDIT:
NativeBOINC is considered as 1 process and 2 services. Maybe service immune to memory cannibalizing ?

I haven't looked where BOINC gets memory size. Probably /proc/meminfo.

Ok, G-tab has it.

MemTotal: 446760 kB
MemFree: 25352 kB
Buffers: 50080 kB
Cached: 108652 kB
.....

VmallocTotal: 548864 kB
VmallocUsed: 38528 kB

It seems 512 MB is too big safe margin for app that allocates ~50MB in total, not?
My device has (accordingly to BOINC's web page)436.29 Мб memory. Much more than 256... but still doesn't enough :/

EDIT: and accordingly Android's info dialog my device currently (2 MB7 + NativeBOINC running) still has 124MB free of 436MB.

The big issue isn't total memory. It's free memory. You've got 25MB free, so when an app needs 50MB, android does a combination of discarding read-only pages (usually code) and killing processes until it can satisfy a request.

On you hosts I don't see indications of a lot of restarts on the results that have come back. Host 64393 might be a little tight on memory though. If you look at in stderr.txt in the slots directory you can see if there have been lots of restarts.

---

The big issue isn't total memory. It's free memory. You've got 25MB free, so when an app needs 50MB, android does a combination of discarding read-only pages (usually code) and killing processes until it can satisfy a request.

On you hosts I don't see indications of a lot of restarts on the results that have come back. Host 64393 might be a little tight on memory though. If you look at in stderr.txt in the slots directory you can see if there have been lots of restarts.

Well, are you sure you saw such behavior "in wild" or it's theoretical considerations?
Cause at least on one host, mentioned 64393, restarts are not because of that.
It's my Samsung mini phone, entry-level Android phone with quite restricted memories (all kinds). But as I said before I never saw NativeBOINC or its science apps were killed on this device. I can carry out special experiments cause this phone has lot of "heavy" stuff loaded (maps, big dictionary, few games and so on). Will do such experiment tomorrow.

And regarding increased number of restarts on that host: Cause it's my primary phone now I use it not only for crunching. Founded myself w/o call link few times because of phone was completely discharged. It's inconvinient so now I configured NativeBOINC to run only when on external power (plugged). And to suspend apps otherwise. Plus I restart phone or NativeBOINC itself time to time. Hence increased number of app restarts.

Well, promised experiment:

On start stderr.txt contains 21.48% on last restart. App running currently.
I'm starting different applications and look for RAM allocation via settings.
Switching between currently active app and settings page via "Home" button long press.

App runing manifestation is quite different between apps.
1) starting game ("usual" app):
after switching to Settings there is no that game signs at all.
Settings "sees" NativeBOINC + few other system processes. After switching back to that game it continues run (not restarted from initial screen).

2) Starting maps (app with some service-like part).
after switching to Settings this app (unlike prev one) is listed and consumes some memory. Listed as "1 process and 1 service" (that "service" looks crucial property that defines app closing behavior!)

3) Starting few another "usual" apps - again, no signs of those apps running after switching to Settings.

4) Starting Skype (app designed, just as BOINC and maps, to run into background hence containing "service" part).
And again, after switching to Settings Skype listed as 1 process and 1 service, whole 25MB of RAM consumed.

5) running few more "usual" apps.
6) trying to switch back to initial "game app": it was restarted from very beginning, with initial screen. That is, Android cannibalized whole process here.
7) switching to Skype and maps showed that they was not killed.

8) running another browser and calculator, switching to initial game app - again, it was killed completely. That is, phone now running in low memory state and Android runtime actively frees memory by killing whole processes.

9) launching Android maps (ont more app with service part, designed to run into background). Again, now it listed with other services in Settings "running apps" page.

10) launching Dictophone and Jasmine IM (ICQ) - both apps have service part.
11) launching videoregistrator (again, "service" app)
Currently 140MB busy/57MB free.
12) launching few more apps... and looks like all available on phone apps with service part are running already. Busy 156MB/ free 47MB.

Finally, switching back to NativeBOINC:
MBv7 running. Checking stderr.txt - same % of last restart (21.48&) while current % is 24.157.

Hence, all my attempts to summon NativeBOINC or its apps cannibalizing are failed. Nevertheless Android runtime was in "cannibalizing" mode, it was shown with other apps.

Summary: it's impossible (at least VERY hard) to induce SETI app killing by Android runtime if app was launched via NativeBOINC.

Maybe someone who uses stock BOINC on Android could repeat such test on own device?

For now I would recommend to lower memory boundaries for more advanced code paths using inside SETI app.

Well, are you sure you saw such behavior "in wild" or it's theoretical considerations?

I was seeing it on my 256MB DROID with cyanogen all the time. Endless restarts with the same percentage done on the armv7 app (which doesn't bypass the benchmarks. (I've occasionally been running "uniq" on stderr.txt to avoid getting the file getting too large and aborting the result).

But you're right, maybe we could relax the requirements to 256MB and 350MB respectively without problems.

---