Tamas Szekeres
Tamas Szekeres
The stack trace is looking like: ``` mapserver!msMVTWriteTile+0x57027 mapserver!msMVTWriteTile+0x5cfe6 mapserver!msMVTWriteTile+0x56dc4 mapserver!msMVTWriteTile+0x407eb mapserver+0x272f mapserver!msRasterizeArc+0x9bf mapserver!msAddLabelGroup+0x329 mapserver!msValueToRange+0xf64 mapserver!msDrawShape+0x7b5 mapserver!msDrawVectorLayer+0x804 mapserver!msDrawLayer+0x3a3 mapserver!msDrawMap+0x415 mapscript!CSharp_mapObj_draw+0xd ``` and ``` mapserver!msRasterizeArc+0x9ea mapserver!msPolylineLabelPath+0x125 mapserver!msUnionLayerInitializeVirtualTable+0x1646 mapserver!msDrawShape+0x80d mapserver!msDrawVectorLayer+0x804 mapserver!msDrawLayer+0x3a3 mapserver!msDrawMap+0x415...
PATH_INFO on IIS is a bit different than we would expect. It's defined here: http://msdn2.microsoft.com/en-us/library/ms524602.aspx Note that we could set a property (AllowPathInfoForScriptMappings) on the server to make it compatible...
To fix this issue we should replace target_link_libraries(mapcache ${PNG_LIBRARY}) with target_link_libraries(mapcache ${PNG_LIBRARIES})
When configuring mapcache CGI in IIS I'm getting truncated results for the demo requests. Actually the in the CGI response output stream (stdout) every \n is replaced with \r\n so...
if(getenv("HTTPS")) { ... } should be replaced with: char *https = getenv("HTTPS"); if(https && !strcmp(https,"on")) { ... }
When using mapcache in IIS setting IIS environment variables per application is fairly challenging and setting the system wide MAPCACHE_CONFIG_FILE is not always sufficient during deployment. I'd suggest to set...
It looks like msProjFinder is not thread safe, that may cause memory corruptions. The following stack traces have been detected on a server with heavy load pressure: Count: 2 Exception...
As of the cmake build, the WIN32 flag for the SWIG command line hasn't been added, though it was present in the nmake based builds. This results in the GEOS...
The msUpdate...FromString functions may cause memory corruption issues in a multi-threaded environment, where multiple threads call the functions simultaneously. This is because msReleaseLock(TLOCK_PARSER); is called before msyylex_destroy() which releases memory...