Android app -755
Lubomir I. Ivanov
neolit123 at gmail.com
Fri Jan 29 09:09:03 PST 2016
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?
> ABI: 'arm'
> pid: 8435, tid: 8449, name: QtThread >>> org.subsurfacedivelog.mobile <<<
> signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xe0502fdc
> #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.
More information about the subsurface