On 29 January 2016 at 17:23, Jan Mulder <[email protected]> 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 > > [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. lubomir -- _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
