> On Apr 18, 2016, at 2:16 AM, Rick Walsh <[email protected]> wrote: > > > > On 18 April 2016 at 18:21, Rick Walsh <[email protected] > <mailto:[email protected]>> wrote: > > > On 18 April 2016 at 11:20, Steve <[email protected] > <mailto:[email protected]>> wrote: > > > > Registers: > > rax 0x0 0 > > rbx 0x7ffeef3a09d0 140732911978960 > > rcx 0x7ffeef3a09d0 140732911978960 > > rdx 0x7ffeef3a09d0 140732911978960 > > > > SegvAnalysis: > > Segfault happened at: 0x6a8d58 <dc_device_foreach+8>: mov > > 0x30(%rax),%rax > > Hmm. > > dc_device_foreach is in libdivecomputer, and is a rather simple function. > > I suspect that "device->vtable" is NULL. > > > #0 0x00000000006a8d58 in dc_device_foreach () No symbol table info > > available. > > #1 0x0000000000652b02 in do_libdivecomputer_import () No symbol > > table info available. > > The caller is do_libdivecomputer_import -> do_device_import, but > do_device_import is likely inlined. > > I'm not seeing how device->vtable would be NULL, but it's either a > libdivecomputer bug, or it is, as you say, memory corruption. > > Linus > > > > I can also confirm an issue in windows 10 as well when using the older serial > port method to download from a petrel 2. > I don't remember the exact error message and when I tried again from command > line using -vvv to capture the messages it worked successfully. > > I have the same issue and backtrace using native Bluetooth download (for > Petrel 2) running the current master (just verified 15 min ago with 628f83d > but reported on 9 April) running Fedora 23. > http://lists.subsurface-divelog.org/pipermail/subsurface/2016-April/025260.html > > <http://lists.subsurface-divelog.org/pipermail/subsurface/2016-April/025260.html> > > It also fails for me with the same backtrace using the 4.5.4 Appimage, but > works fine with the 4.5.2 Appimage. However, if I build v4.5.2 myself, it > fails the same way. I dare say the cause is something that changed in > Subsurface-branch of libdivecomputer between 27 October (4.5.2) and 16 March > (4.5.5). > > To confirm my suspicion, I built the current subsurface master (with changes > to include lines to build with native Bluetooth support), and old > libdivecomputer that I think would have been used for v4.5.2 Appimage > (058538e Use hidapi for Suunto EON Steel on Mac). I successfully downloaded > my dives from yesterday off my Petrel 2. > > I would try to bisect through the hundred-odd changes in the > Subsurface-branch of libdivecomputer, but I need to get dinner ready.
My guess is that when merging the latest master of libdivecomputer into our branch I managed to break the Shearwater support. It's annoying that our branch has diverged so far from libdivecomputer, but a recent discussion with Jef has shown that our goals for libdivecomputer have diverged about as much as our code bases, so this is a situation that is likely to get worse, not better. Because of the way I handle bringing the changes from master into our branch, I think you'd be much better off not to bisect but to do a direct diff of just the shearwater source files between a working version and the current version. Hopefully that will make it obvious what I messed up /D
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
