On Fri, Jan 9, 2015 at 5:52 PM, Dirk Hohndel <[email protected]> wrote:
> > > On Jan 9, 2015, at 2:10 AM, Miika Turkia <[email protected]> wrote: > > > > But my trusty Stinger gave a new crash, so here is some more details: > > ---8<--- > > [1.899591] ERROR: Failed to receive the answer. [in suunto_vyper.c:231 > (suunto_vyper_transfer)] > > [Thread 0x7fff65f59700 (LWP 31974) exited] > > terminate called after throwing an instance of 'std::bad_alloc' > > what(): std::bad_alloc > > > > Program received signal SIGABRT, Aborted. > > 0x00007ffff43cfbb9 in __GI_raise (sig=sig@entry=6) > > at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 > > 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. > > (gdb) bt > > #0 0x00007ffff43cfbb9 in __GI_raise (sig=sig@entry=6) > > at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 > > #1 0x00007ffff43d2fc8 in __GI_abort () at abort.c:89 > > #2 0x00007ffff4ac56b5 in __gnu_cxx::__verbose_terminate_handler() () > > from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 > > #3 0x00007ffff4ac3836 in ?? () from > /usr/lib/x86_64-linux-gnu/libstdc++.so.6 > > #4 0x00007ffff4ac3863 in std::terminate() () > > from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 > > #5 0x00007ffff4ac3aa2 in __cxa_throw () > > from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 > > #6 0x00007ffff4ac3f8d in operator new(unsigned long) () > > from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 > > #7 0x00007ffff4ac4029 in operator new[](unsigned long) () > > from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 > > new throws the crash, so that makes me think that there are more out of > bounds errors here > I’d suggest running this under Valgrind. > Good idea, but I probably won't have any time to do any hacking while here. You know the drill. dive, eat, sleep, repeat > I fixed quite a few array access errors in the code, most likely I missed > one or two. > I'll give it a try after I get 4 more dives on the DC. > > I have an empty line on the divelog list, but one dive is missing. Thus > I am able to download only 2 of todays 3 dives. > > I saw that as well - my guess is we terminate the loop too early. Also > easy to look into. > > > It would be great if canceling download would allow me to select dives > from the ones that were already loaded. (As I have to force load of all > dives to get all 3 dives out of my Vyper, I naturally tried to speed things > up and canceled the load prematurely.) > > On my todo list. > > This code needs a lot more testing. But the best way to get it tested is > to put it in master. > Especially a week before Linus and I go diving again and while you are > diving. :-) > > Are you able to build Subsurface while you are traveling? > Building myself is the only way to get new stuff under testing. Apt is not working from here and I am too lazy to download the daily deb manually. miika
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
