On 29 January 2016 at 19:26, Dirk Hohndel <d...@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 <jlmul...@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 -- _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface