<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 18, 2016, at 2:16 AM, Rick Walsh <<a href="mailto:rickmwalsh@gmail.com" class="">rickmwalsh@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On 18 April 2016 at 18:21, Rick Walsh <span dir="ltr" class=""><<a href="mailto:rickmwalsh@gmail.com" target="_blank" class="">rickmwalsh@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote"><span class="">On 18 April 2016 at 11:20, Steve <span dir="ltr" class=""><<a href="mailto:stevewilliams@internode.on.net" target="_blank" class="">stevewilliams@internode.on.net</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">><br class="">
> Registers:<br class="">
> rax 0x0 0<br class="">
> rbx 0x7ffeef3a09d0 140732911978960<br class="">
> rcx 0x7ffeef3a09d0 140732911978960<br class="">
> rdx 0x7ffeef3a09d0 140732911978960<br class="">
><br class="">
> SegvAnalysis:<br class="">
> Segfault happened at: 0x6a8d58 <dc_device_foreach+8>: mov 0x30(%rax),%rax<br class="">
<br class="">
Hmm.<br class="">
<br class="">
dc_device_foreach is in libdivecomputer, and is a rather simple function.<br class="">
<br class="">
I suspect that "device->vtable" is NULL.<br class="">
<br class="">
> #0 0x00000000006a8d58 in dc_device_foreach () No symbol table info<br class="">
> available.<br class="">
> #1 0x0000000000652b02 in do_libdivecomputer_import () No symbol<br class="">
> table info available.<br class="">
<br class="">
The caller is do_libdivecomputer_import -> do_device_import, but do_device_import is likely inlined.<br class="">
<br class="">
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.<br class="">
<br class="">
Linus<br class="">
<br class="">
<br class="">
<br class="">
</span>I can also confirm an issue in windows 10 as well when using the older serial port method to download from a petrel 2.<br class="">
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.<br class="">
<span class=""><font color="#888888" class=""><br class=""></font></span></blockquote></span>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.<br class=""><a href="http://lists.subsurface-divelog.org/pipermail/subsurface/2016-April/025260.html" target="_blank" class="">http://lists.subsurface-divelog.org/pipermail/subsurface/2016-April/025260.html</a><br class=""><br class=""></div></div></div></blockquote><div class="">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).<br class=""><br class=""></div><div class="">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.<br class=""><br class=""></div><div class="">I would try to bisect through the hundred-odd changes in the Subsurface-branch of libdivecomputer, but I need to get dinner ready.<br class=""></div></div></div></div></div></blockquote><br class=""></div><div>My guess is that when merging the latest master of libdivecomputer into our branch I managed to break the Shearwater support.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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</div><div><br class=""></div><div>/D</div><br class=""></body></html>