Many thanks for this Even.
I've built and been testing the branch with the `tostring` exe. The good (?)
news is that the issue occurs with this also - so at lease that rules out
Python and SWIG.
In MSVC the default optimization for release is /02. If this is changed to /O1
it works.
It also appears you can create PDB debug files for release versions. These
don't allow me to step through in a debugger, but it did provide a stack trace.
Exception thrown at 0x00007FFB306F6CF1 (ucrtbase.dll) in tostring.exe:
0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.
ucrtbase.dll!strnlen() Unknown
ucrtbase.dll!__crt_stdio_output::output_processor<char,__crt_stdio_output::string_output_adapter<char>,__crt_stdio_output::standard_base<char,__crt_stdio_output::string_output_adapter<char>>>::type_case_s()
Unknown
ucrtbase.dll!__crt_stdio_output::output_processor<char,__crt_stdio_output::string_output_adapter<char>,__crt_stdio_output::standard_base<char,__crt_stdio_output::string_output_adapter<char>>>::state_case_type()
Unknown
ucrtbase.dll!__crt_stdio_output::output_processor<char,__crt_stdio_output::string_output_adapter<char>,__crt_stdio_output::standard_base<char,__crt_stdio_output::string_output_adapter<char>>>::process()
Unknown
ucrtbase.dll!common_vsprintf<__crt_stdio_output::standard_base,char>() Unknown
mapserver.dll!msIO_vfprintf() C
mapserver.dll!msIO_fprintf() C
mapserver.dll!resetClassStyle() C
mapserver.dll!resetClassStyle() C
mapserver.dll!resetClassStyle() C
mapserver.dll!msWriteMapToString() C
tostring.exe!main() C
[Inline Frame] tostring.exe!invoke_main() Line 78 C++
tostring.exe!__scrt_common_main_seh() Line 288 C++
kernel32.dll!BaseThreadInitThunk() Unknown
ntdll.dll!RtlUserThreadStart() Unknown
Interestingly, if I go back to a debug build and step through with a debugger
`resetClassStyle` is never called..
It looks like it is trying to print out a NULL string, but how this is created
I've not been able to find.
Seth
--
web:https://geographika.net
twitter: @geographika
On Sun, Oct 16, 2022, at 1:49 PM, Even Rouault wrote:
> Seth,
>
> Several things:
>
> - there used to be a time where you couldn't safely mix code built with
> different versions of Visual Studio, but this was relaxed since VS 2015
> (https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-170),
>
> and anyway apparently this isn't the case here, given release-190-x64
> is
> built with VS2022. The only thing however is that your Python binary is
> likely not built with VS2022. But thinking of GDAL, we have the same
> situation and a Windows CI setup with VS2022, and things work well.
>
> - you could potentially try https://github.com/dynamorio/drmemory which
> is an equivalent of Valgrind, that runs on Windows.
>
> - It is strange that you get different behaviour with Release vs
> RelWithDebInfo. Perhaps RelWithDebInfo generates a binary with slightly
> lower optimization level. This is the case with gcc where RelWithDebInfo
> is -O2 whereas Release is -O3. I couldn't quickly find info on that for
> MSVC, but might be something to investigate
>
> - all the fuzzing fixes are about error code paths, not regular code
> triggered by a nominal sane mapfile.
>
> - we can never exclude compiler bugs, and that's quite a headache to
> spot them and reduce to a simpler reproducer. But it could also be that
> VS2022 optimizes something more greedily on a part of the code that may
> rely on some undefined behavior. C/C++ has many undefined behaviours,
> and compilers may decide to do different things, and sometimes crazy
> things, on code with such undefined behaviour. it could also be a memory
> corruption whose effects manifest themselves later in weird ways.
>
> - it could indeed be interesting to check if you can reproduce the
> issue
> outside of a python context, for example with
> https://github.com/rouault/mapserver/commit/9d64dc65461c4df30da0f9170de4300331a6d173
>
> ("tostring" branch of https://github.com/rouault/mapserver/)
>
> Even
>
> Le 16/10/2022 à 11:07, Seth G a écrit :
>> Hi all,
>>
>> I've been trying to get MapScript for Python working for MapServer 8.0 using
>> Visual Studio 2022 and the release-1930-x64 SDK from GISInternals- see issue
>> https://github.com/MapServer/MapServer/issues/6628
>>
>> In summary, whenever you try and save a Mapfile to a file in Python (all
>> versions from 2.7 to 3.10 are affected) there is a "Windows fatal exception:
>> access violation".
>>
>> Note, everything builds fine when using Visual Studio 2019 (and the
>> release-1928-x64 SDK) with the same MapServer code.
>>
>> The worst thing is that when running a DEBUG version of the code -
>> everything works fine. The exception only works in RELEASE version, which
>> means my "debugging" involves modifying code, recompiling and rerunning.
>>
>> The fact it doesn't work in RELEASE version strongly implies that VS2022 is
>> doing some optimization which causes the issue. I'm not sure how best to
>> progress this, and hoping someone on the list may have some ideas.
>>
>> - With each of the fuzzing fixes, I've been hoping the issue will be
>> resolved. Could it be the case that memory is getting corrupted and causing
>> the issue?
>> - Is it likely the cause is a bug in the MapServer code which causes
>> something to be optimized away that shouldn't be?
>> - Is there any chance there is a bug in VS2022 itself rather than anything
>> in MapServer?
>> - Commenting out various parts of `writeWeb, and `writeFeature` get things
>> working again, but there seems to be no logic to this - e.g. commenting out
>> half of the `writeLayer` means it works again (with no changes to
>> `writeWeb`), but commenting out a single line in `writeWeb` also gets it
>> working, removing parts of `writeFeature` also works, a Mapfile with one
>> LAYER works one with 2 LAYERS doesn't..
>> - the `writeMapToString` [1] is only called using MapScript. Would it be
>> worth adding an option to map2img to dump out an input Mapfile to test this
>> without any MapScript?
>>
>> Thanks for any input!
>>
>> Seth
>>
>>
>> [1]
>> https://github.com/MapServer/MapServer/blob/e5a53178b056f0da83ec8e5a2e0412a50d0ca3a6/mapfile.c#L5904
>>
>> --
>> web:https://geographika.net
>> twitter: @geographika
>> _______________________________________________
>> MapServer-dev mailing list
>> [email protected]
>> https://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
_______________________________________________
MapServer-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/mapserver-dev
