This will likely run slower that earlier versions due to addition debugging code (that would be removed in an eventual release). Please continue to run it even though it is slow.

---

This will likely run slower that earlier versions due to addition debugging code (that would be removed in an eventual release). Please continue to run it even though it is slow.

I hope it is not all that much slower than 7.24, which was considerably slower than 7.23.

I'm hoping that we're getting toward the point where I can strip out the debugging code.

---

Don't know what you changed since worked offline version but this 7.25 fails again, at least online.

http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=16005360

<core_client_version>7.0.36</core_client_version>
<![CDATA[
<message>
process exited with code 193 (0xc1, -63)
</message>
<stderr_txt>
Unable to resolve function unwind_backtrace_signal_arch
Unable to resolve function acquire_my_map_info_list
Unable to resolve function release_my_map_info_list
Unable to resolve function get_backtrace_symbols
Unable to resolve function free_backtrace_symbols
Unable to resolve function format_backtrace_line
Unable to resolve function load_symbol_table
Unable to resolve function free_symbol_table
Unable to resolve function find_symbol
one or more symbols not found. stackdumps unavailable
setiathome_v7 7.24 Revision: 2072 arm-linux-androideabi-g++ (GCC) 4.6 20120106 (prerelease)
libboinc: BOINC 7.3.0

Work Unit Info:
...............
WU true angle range is : 0.014765
Optimal function choices:
--------------------------------------------------------
name timing error
--------------------------------------------------------
v_BaseLineSmooth (no other)
vfp_GetPowerSpectrum (CPU Caps)
neon_ChirpData (CPU Caps)
v_Transpose4 (default)
neonFoldMain (CPU Caps)
SIGILL: illegal instruction
Manual call stack printout
6 find_pulse()
5 analyze_pot()
4 InitTrigArray()
3 seti_analyze()
2 seti_do_work()
1 worker()

Exiting...

</stderr_txt>
]]>

This will likely run slower that earlier versions due to addition debugging code (that would be removed in an eventual release). Please continue to run it even though it is slow.

Even slower than 7.24? I'll prepare to finish next task then, just before mid summer :-)

---

WARNING!! "THIS IS A SIGNATURE", of the "IT MAY CHANGE AT ANY MOMENT" type. It may, or may not be considered insulting, all depending upon HOW SENSITIVE THE VIEWER IS, to certain inputs to/from the nervous system.

I had 27 consecutive errors with this version and now my phone isn't getting new work.

The errors are not all the same, either. Some are similar to the one Raistmer posted, while others say "got signal 11" and then at the bottom there's a SIGSEGV. None of them ran longer than 2 minutes.

On the ones where another Android also worked on in, they all got the identical error, whichever error it was. I noticed one WU where another phone got it as a v24, but it hasn't come back yet.

---

David
signature sent back to alpha testing

This will likely run slower that earlier versions due to addition debugging code (that would be removed in an eventual release). Please continue to run it even though it is slow.

Even slower than 7.24? I'll prepare to finish next task then, just before mid summer :-)

Trust me, Sten. If you get a v25, it won't run very long at all.

---

David
signature sent back to alpha testing

This will likely run slower that earlier versions due to addition debugging code (that would be removed in an eventual release). Please continue to run it even though it is slow.

Even slower than 7.24? I'll prepare to finish next task then, just before mid summer :-)

Trust me, Sten. If you get a v25, it won't run very long at all.

Hehe, well I'll run down my quota to zero then :-)

Thanks for the heads up.

---

WARNING!! "THIS IS A SIGNATURE", of the "IT MAY CHANGE AT ANY MOMENT" type. It may, or may not be considered insulting, all depending upon HOW SENSITIVE THE VIEWER IS, to certain inputs to/from the nervous system.

bur interestingly my 2013 Nexus 7, that never worked with .24, appears to be happily munching away with .25 (so far, touch wood).

bur interestingly my 2013 Nexus 7, that never worked with .24, appears to be happily munching away with .25 (so far, touch wood).

Yup, 7.25 seems to work so far (touch wood), on my Catphone too.

---

WARNING!! "THIS IS A SIGNATURE", of the "IT MAY CHANGE AT ANY MOMENT" type. It may, or may not be considered insulting, all depending upon HOW SENSITIVE THE VIEWER IS, to certain inputs to/from the nervous system.

I will start my first 7.25 in a couple of hours, it has an estimate of 80 hours.

I just checked my event log. The reason I'm not getting any more work is that I've reached a daily quota of 6. However, the server must have just imposed that limit; all 27 of the errored tasks were sent today (UTC) (25 of them today my time, CST).

---

David
signature sent back to alpha testing

Don't know what you changed since worked offline version but this 7.25 fails again, at least online.

It's identical down to the MD5 to the last megadebug version. :(

---

Well eventually my first 7.25 cacked out about 50% through:

http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=16006221
Google Nexus 7, 2013 Model

That's a new error number to me, though a similar spontaneous exit as I saw eventually with megadebug under standalone.

I see restarts for no apparent reason. Are we sure the Boinc client is taking appropriate wakelocks (JNI), and that these transfer through effectively to the child processes ? The device was on, locked awake (via debugging options), and not in use...

That was allowing 1 core. I'll run a few more through with 2 cores allowed to see if anything more useful comes out.

[Edit:] Ah, just now in developer options I see and option to switch to the new ART runtime (from the default dalvik). I will twiddle that & see what happens (if anything)

FWIW, my phone wasn't doing anything out of the ordinary. It was plugged in for the night, sitting where it sits every night, connected to my home wifi. It finished one task unusually quickly, but it shows as a success. Then it ran through 27 v25s in about 2.5 hours.

---

David
signature sent back to alpha testing

FWIW, my phone wasn't doing anything out of the ordinary. It was plugged in for the night, sitting where it sits every night, connected to my home wifi. It finished one task unusually quickly, but it shows as a success. Then it ran through 27 v25s in about 2.5 hours.

And both our devices (with similarish looking stderrs) have 4 processors .... maybe a look at someone's that is working with it...

[Edit:] Hmmm, Arkayn's Uniprocessor model, unlike our quaddies, seems to be printing complete stackdumps after exceptions like the SIGSEGV on exit, though validating with 7.24 and 1 7.25 so far...

Just another possibility to throw in the ring, if it looks like uniprocessor ARM devices sortof work with the builds.

Could be the threads / ARM SMP model, which makes no ordering guarantees, unlike the x86 model. I'd have to look where the checkpoints are triggered, but if not in the worker thread then lack of synchronisation there might explain malfunction on SMP ARM, while working on x86 (and uniprocessor ARM. not sure about dual-core).

There are like 28 errors with v25 today with my RK3188 TV stick. I has been running fine for the last month and half. This is the error message I got from it.

<core_client_version>7.3.0</core_client_version>
<![CDATA[
<message>
process got signal 11
</message>
<stderr_txt>
setiathome_v7 7.24 Revision: 2072 arm-linux-androideabi-g++ (GCC) 4.6 20120106 (prerelease)
libboinc: BOINC 7.3.0

Work Unit Info:
...............
WU true angle range is :  0.853231
Optimal function choices:
--------------------------------------------------------
                            name   timing   error
--------------------------------------------------------
                v_BaseLineSmooth (no other)
            vfp_GetPowerSpectrum 0.000942 0.00000 
                  neon_ChirpData 0.032671 0.00000 
                  v_pfTranspose4 0.033446 0.00000 
                opt NEON folding 0.003813 0.00000 
SIGSEGV: segmentation violation
Manual call stack printout

</stderr_txt>
]]>

20% done. Slowest android app this far.Still running though. Hope to finish this wu before summer comes to Sweden.

Edit: Since I don't crunch while on battery, and I use that phone every day, it will take forever to finish wu's with this kind of slow app. Watching grass grow is lightingly fast compared to this.

---

WARNING!! "THIS IS A SIGNATURE", of the "IT MAY CHANGE AT ANY MOMENT" type. It may, or may not be considered insulting, all depending upon HOW SENSITIVE THE VIEWER IS, to certain inputs to/from the nervous system.

bur interestingly my 2013 Nexus 7, that never worked with .24, appears to be happily munching away with .25 (so far, touch wood).

My 2012 Nexus 7, that works fine with .24, errors at about 300 secs on .25 with process got signal 11:

SIGSEGV: segmentation violation
Manual call stack printout

The 2012 HTC One S (which hasn't worked properly with any app) meanwhile fails at about 60 secs,
with either a process got signal 11 and a SIGSEGV: segmentation violation, or a process exited with code 193 (0xc1, -63),
I've seen the following traces so far:

SIGILL: illegal instruction
Manual call stack printout
#00 pc 00b3ca5b <unknown> (???) [0xb527b73b]
#01 pc 3efd4b6e <unknown> (???) [???]

Or

SIGILL: illegal instruction
Manual call stack printout
SIGSEGV: segmentation violation
Manual call stack printout
#00 pc 00000000 <unknown> (???)

Or

SIGSEGV: segmentation violation
Manual call stack printout
#00 pc 00b55636 <unknown> (???) [0xd9603bb4]
#01 pc 003c5390 <unknown> (???) [0xbbb5854c]

Or

SIGSEGV: segmentation violation
Manual call stack printout
#00 pc 00b2c5e7 <unknown> (???) [0xb3e05e3b]
#01 pc 000f4ab7 <unknown> (???) [0x]

Or

SIGSEGV: segmentation violation
Manual call stack printout
#00 pc 0001b043 <unknown> (???) [0xa72f743f]
#01 pc 00033cf4 <unknown> (???) [0x3f7ef37e]

Claggy

bur interestingly my 2013 Nexus 7, that never worked with .24, appears to be happily munching away with .25 (so far, touch wood).

My 2012 Nexus 7, that works fine with .24, errors at about 300 secs on .25 with process got signal 11:

SIGSEGV: segmentation violation
Manual call stack printout

Aside from possible program bugs, that's interesting, because it *might* reinforce the SMP model avenue to explore. From direct experience I know that David Anderson has no understanding of the consistent SMP model found on x86 and uniprocessor ARM, let alone the intentionally flexible (inconsistent) & lightweight ARM definition for SMP multiprocessors. So in a lot of failure modes, probably just dealing with similar lack of synchronisation issues, to the old Cuda sticky downclocks and driver crashes.

Long story short, Attempting to read, write to, or otherwise manipulate memory areas freed in another thread through undetermined order will generate the segmentation violations (unsure of the sigills, but possiblly a side effect too). For android probably he needs to use pthreads mutexes in similar fashion to my Windows Cuda patch, but how much of the current problems here that encompasses is anyone's guess. (maybe none, maybe most of them)