[MapServer-dev] Schrödinger's bug

[Seth G]

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
>> MapServer-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
> -- 
> http://www.spatialys.com
> My software is free, but my time generally not.