Android app -755

[Lubomir I. Ivanov]

On 29 January 2016 at 19:26, Dirk Hohndel <dirk at hohndel.org> wrote:
> On Fri, Jan 29, 2016 at 07:09:03PM +0200, Lubomir I. Ivanov wrote:
>> On 29 January 2016 at 17:23, Jan Mulder <jlmulder at xs4all.nl> wrote:
>> > 3) After 5 minutes of clicking and swiping I ran into a SIGSEGV. One thing,
>>
>> is there some sort of a consistency in the crash location - dive #,
>> sequence of events etc?
>> can this be reproduced on each run?
>>

waiting on Jan to respond so that we can have a better guess.

>> > ABI: 'arm'
>> > pid: 8435, tid: 8449, name: QtThread  >>> org.subsurfacedivelog.mobile <<<
>> > signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xe0502fdc
>> >
>> > [snip]
>> >
>> >  backtrace:
>> >     #00 pc 00017b90  /system/lib/libm.so (pow)
>> >     #01 pc 0281816c  [heap]
>> >
>>
>> a SIGSEGV inside pow() is plain odd.
>>
>> it's implementation dependent, but some of the math.h functions can
>> use a bunch of tricks like logx() lookup tables, taylor series
>> approximations with range reduction, mantissa exponent separation and
>> so on. if the crash is really inside pow() then it must to be fed a
>> very bogus value that bypasses some of the error checks (that i'm sure
>> are present in libm) and accesses a lookup table index out of range.
>> then, that out of range index should be large enough to even throw a
>> SIGSEGV, as it could sometimes just work with adjacent memory and
>> return something like 0.00.
>>
>> now, the backtrace could be just wrong and the actual bogus access
>> could be outside of pow() - i.e. in the function input.
>> grepping for usage of pow() in subsurface i don't see anything that suspicious.
>> deco.c (is buehlmann_N2_t_halflife[ci] safe?), divelist.c, etc.
>>
>> this bug requires some plain stderr/stdout debugging to catch the
>> exact offending stage.
>
> I was also suspecting that it might be something in the deco calculation.
> And given that we don't expose the ability to display the calculated
> ceiling or the TTS or anything else... I would really like to see a patch
> that just compiles out all that code when building Subsurface-mobile.

it can also be one of the calls from divelist.c breaking on a certain
weird ARM pow() implementation.

the main problem with the mobile version crash reports ATM seems to be
not so useful backtraces.
a verbose build of the mobile version that shows a bunch of print() /
console.log() message is going to be very useful.

it would be then much easier to narrow down problematic stages.

lubomir
--