On 17 October 2015 at 21:55, Stefan Fuchs <[email protected]> wrote: > > > I really prefer this the other way around. Get everyone involved. Then if > someone has a specific follow up question, send them the file. > But for verification, for you Subsurface now crashes when you just try to > open that file? > Because that's a pretty standard mild trimix dive. Not long, not deep, no > unusual gases - this is something that we test all the time > > Any ideas? Anything else you need to know from my side? Thanks! > > > Not right now, let's see what Lubomir and Robert think >
so, Rick sent me his MSVCRT.dll and the XML dive log. i can't reproduce the issue on Windows 7 with or without the German translation. the faulting offset 0x0007b090 is oddly inside the vswprintf() branch of the DLL! 1017b08d: eb 07 jmp 0x1017b096 1017b08f: 48 dec %eax 1017b090: 80 39 00 cmpb $0x0,(%ecx) <--------- 1017b093: 74 05 je 0x1017b09a 1017b095: 41 inc %ecx 1017b096: 85 c0 test %eax,%eax 1017b098: 75 f5 jne 0x1017b08f 1017b09a: 2b ce sub %esi,%ecx to me, that closely resembles a NULL pointer check. the question is where is vswprintf() used... i don't find any usage of this function in the Subsurface source tree (or any wide char functions to begin with), except in windows.c so it has to come from somewhere else... the only library which calls it directly is libzip, but i don't find that to be planner related (?). objdump -D libzip.dll | grep vswprintf 61693f1a <_vswprintf>: 61693f6a: e8 ab ff ff ff call 61693f1a <_vswprintf> anyhow, i would ask Rick and/or Stefan to run subsurface.exe under GDB so that we obtain some sort of meaningful backtrace. of course, only if we they agree to download a toolchain and follow some instructions. lubomir -- _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
