<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Rainer,<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 13, 2022, at 01:57, Rainer Mohr <<a href="mailto:mail@divelogs.de" class="">mail@divelogs.de</a>> wrote:</div><div class=""><div class=""><br class="">
Realized, that there are a few dives missing, so I get them from
<a href="http://divelogs.de" class="">divelogs.de</a>. Download works fine, but after clicking "apply" it
tries to merge an then crashes. Can reproduce any time. Report
attached<br class="">
<br class="">
This "apply" and merge <b class="">does</b> work on a local logbook. <br class=""></div></div></blockquote><div><br class=""></div>So this means that it's some odd random memory corruption that happens in one scenario, not in another, because otherwise it should crash in both scenarios.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">
Also works on my Version 5.0.5 I still had installed on this Mac
with both local and cloud logbook<br class="">
<br class="">
@Dirk, you have explicit permission to access my cloud dives if that
helps in any way<br class=""></div></div></blockquote></div><br class=""><div class="">That's likely not enough - I'd need to be able to download your dive data from dive <a href="http://logs.de" class="">logs.de</a> as well in order to recreate that merge scenario that causes the crash.</div><div class=""><br class=""></div><div class="">I had hoped that the offsets in the stack trace would be pointing me at a specific line in the code, but at least the crash one is clearly bogus.</div><div class=""><br class=""></div><div class=""><div class="">READ of size 4 at 0x000166f1de10 thread T0</div><div class="">#0 0x102c08efc in copy_dc_renumber+0x7a8 (Subsurface:arm64+0x100708efc)</div><div class="">#1 0x102c0404c in join_dive_computers+0xc8 (Subsurface:arm64+0x10070404c)</div></div><div class=""><br class=""></div><div class="">the copy_dc_renumber function isn't 0x7a8 or 1960 bytes long...</div><div class="">At first I thought maybe the compiler had inlined something there, but actually that's way past the end of that object file...</div><div class=""><br class=""></div><div class="">I might be able to get something useful with a backtrace from a life app if I can reproduce this locally.</div><div class="">And of course I should be able to instrument the build a bit more - which always risks to hide the problem for things like this one...</div><div class=""><br class=""></div><div class="">The other thing that's (as always) annoying is that I tell the tooling not to strip the binary, but somehow, somewhere, it gets stripped...</div><div class=""><br class=""></div><div class="">Dang.</div><div class=""><br class=""></div><div class="">I spent the last three hours on this flight trying to figure out how to get a DMG that contains the debug symbols for the app - no such luck.</div><div class="">And while I figured out how to get at least a little bit of log info for apps that crash when double clicked, using macOS' log app, I still can'f figure out WH|Y it silently crashes when I double click, but doesn't crash when started from the command line...</div><div class=""><br class=""></div><div class="">/D</div></body></html>