Subsurface 4.5 (Win10) crash after adding dive with planner

[Lubomir I. Ivanov]

On 17 October 2015 at 21:55, Stefan Fuchs <sfuchs at gmx.de> 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
--