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? > > > 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. I realize that there are some tech divers who disagree with this and who instead want the ability to show ceilings - maybe we'll do a Subsurface-mobile (tech edition) for those and tell them "hey, it may crash and it WILL be slow". /D _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
