> On Jan 9, 2015, at 2:10 AM, Miika Turkia <[email protected]> wrote: > > Crash when trying to import. Vyper was slow on getting to transfer mode. > Unfortunately no debugger attached. Console gave the following: > ---8<--- > [3.807747] ERROR: Failed to receive the answer. [in suunto_vyper2.c:207 > (suunto_vyper2_device_packet)] > [4.478353] ERROR: Unexpected answer header. [in suunto_vyper2.c:213 > (suunto_vyper2_device_packet)] > [5.149138] ERROR: Unexpected answer header. [in suunto_vyper2.c:213 > (suunto_vyper2_device_packet)] > [5.149215] ERROR: Failed to read the version info. [in suunto_vyper2.c:144 > (suunto_vyper2_device_open)] > terminate called after throwing an instance of 'std::bad_alloc' > what(): std::bad_alloc > Aborted > ---8<—
Oops. > 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. I fixed quite a few array access errors in the code, most likely I missed one or two. > 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? > I am not able to select dives to be downloaded using the checkbox, only > clicking elsewhere ticks/unticks the selection. That’s funny. Tomaz’ code allowed you only to click the tiny checkboxes. I found that way too hard so I added the code to allow you clicking anywhere on the row. And apparently that broke being able to click the checkbox. Oops again. /D _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
