[UPDATE 31 Jul. 2020]
After several release candidates, I just released the stable release of MapWinGIS v5.2, with internal version number 5.2.4
I also published the stable release of MapWindow5 v5.6, with internal version number 5.6.3
Please download them, try them and let us know on this forum if you run into trouble.
Most work has been done by @Mathijs.Dumon and @jerryfaust
hello, something causing app crash and is probably related to TilesThreadPoolSize property value and when tile provider is openstreetmap and/or when the user switches between providers and the map has not finished loading all tiles.
when TilesThreadPoolSize =30 crashes are more often compare to value of 5.
here is the settings I use:
var gc = new GlobalSettings()
{
BingApiKey = bingKey,
AllowProjectionMismatch = true,
ReprojectLayersOnAdding = true,
ApplicationCallback = new Callback(),
LabelsCollisionMode = tkCollisionMode.LocalList,
TilesThreadPoolSize = 30,
};
gc.HotTrackingMaxShapeCount = 1;
axMap1.Tiles.set_MaxCacheSize(tkCacheType.Disk, 500);
axMap1.Tiles.set_UseCache(tkCacheType.Disk, true); // is on by default
axMap1.Tiles.set_UseCache(tkCacheType.RAM, true); // is on by default
axMap1.Tiles.set_DoCaching(tkCacheType.RAM, true); // is on by default
axMap1.Tiles.set_DoCaching(tkCacheType.Disk, true); // is off by default
Thread size plays a role I think.
–
making more testing about this issue I can say that prior to app crash there is a noticeable delay in tile loading, especially for openstreetmap. So maybe there are some sort of rejected requests from the tile server not properly handled in mapwingis, although not sure if that is the case.
Hello @nnikos123, @pmeems
I was able to crash the app once using the settings above. I’d like to repeat it but it’s late and I’ll try again tomorrow. The crash, interestingly, was in libeay32.dll, which has come up before in a different ticket.
I’m running a 32-bit app using the latest OCX code, linked against GDAL 2.4.0.
Addendum:
Ok, so I stayed up a little longer, and I was able to crash it again, in libeay32.dll called from the cURL library.
Any suggestions? Should I move to GDAL 2.4.2, which was stable for @nnikos123?
Hi Jerry , your latest gdal version according to your doc on github is 2.4.4 . I suggest to start from this one and then downgrade.
The interesting thing is that arcgis of bing providers does not give crash incidents such as openstreetview.
Hi Jerry
Did you find any solution on this matter? I am still receiving crashes even using the latest RC 5.2.2.
Hello @nnikos123
Sorry for not getting back to this earlier.
I am not able to make it crash right now. I’ve tried quite a number of times. I have linked in GDAL 2.4.4. Interestingly, GDAL no longer uses libeay32.dll, so that’s no longer in the mix.
One question; I notice in your code that you’re providing a Bing key. Are you using Bing as opposed to OpenStreetMaps? Or did you say that it is crashing also for OpenStreetMaps?
I am not absolutely sure about Bing but definitely I have crashes using openStreetMaps.
For now I use Bing and ArcGis (World Topo and Imagery) without issues so far.
It seems very unlikely to have bug in other parts of my code since the only change is the map provider and it happens almost instantly when I switch from Bing to OSM
Here is the trace on the Windows event Log
Hi Jerry,
Something has changed in openssl that uses libeay32.dll and ssleay32.dll . Recent versions do not have libeay32 , see link below
as a workaround I have downloaded a more recent version of libeay32 (v1.0.2.20 ) from
Thanks for the update.
I don’t believe that libeay32.dll should even be distributed with MapWinGIS (with GDAL 2.4.4). I do not install MapWinGIS on my build machine, and when I cleaned out the build and installed GDAL 2.4.4, it no longer included libeay32. Instead it included libssl-1_1 and libcrypto-1_1 dlls. I was able to build and run the OCX against this installation of GDAL, and this is what I tested, and I did not get any errors.
However, I went to a clean machine and installed the latest MapWinGIS, and it still includes libeay32.dll (and does not include the libssl or libcrypto dlls). Something seems wrong, and I’m not convinced that the release of MapWinGIS actually includes the latest 2.4.4 version of GDAL. I’m confused by this at the moment, and it will take a little more research. (@pmeems, am I missing something here?)
Hopefully we’ll get this figured out.
Thanks again for your input.
Regards,
Jerry.
well, cure on this matter has not been found yet. I even tried libeay32 & ssleay32 v1.0.2.21 and crashes still happening.
It is almost reproducible if the user tries to zoom very fast while tiles are still loading. hope that helps you more.
It appears, if I’m not mistaken, that the dependent DLLs for GDAL have changed with v2.4.4. However, the build process uses CopyTamasFiles.bat to copy very specific DLLs from the GDAL directory to the MapWinGIS bin directory. I believe that this bat file needs to change for the latest MapWinGIS build.
I wonder, additionally, why it doesn’t just copy all DLLs from the GDAL directory, rather than specifying a specific set of DLLs.
Thank you,
Jerry.
Addendum:
After cleaning out the bin\win32 directory and rebuilding MapWinGIS, the build failed to register the OCX until I modified CopyTamasFiles.bat as follows:
REM Copy needed Tamas binaries:
REM FOR %%G IN (cfitsio.dll geos.dll geos_c.dll hdf5.dll hdf5_hl.dll hdf5_cpp.dll hdf5_hl_cpp.dll libcurl.dll
REM iconv.dll libeay32.dll libmysql.dll libpq.dll libxml2.dll lti_lidar_dsdk_1.1.dll netcdf.dll
REM openjp2.dll proj.dll spatialite.dll sqlite3.dll freexl.dll
REM ssleay32.dll szip.dll tbb.dll xdrdll.dll zlib1.dll libtiff.dll expat.dll NCSEcw.dll) DO (
REM IF EXIST %_from_dir%\%%G (
REM xcopy /v /c /r /y %_from_dir%\%%G %_to_dir%
REM )
REM )
xcopy /v /c /r /y %_from_dir%\*.dll %_to_dir%After an off-list conversation with @jerryfaust it seems GisInternals has updated his binaries and now includes the libssl-1_1 and libcrypto-1_1 dlls.
I updated our build process and created new installers. For now only available at my Google Drive:
https://drive.google.com/drive/folders/0B8UeIGgvyx2VQXRDVndvTUVlUFE?usp=sharing
Since I can’t reproduce the mentioned error, can you (@nnikos123) test this version and let us know?
Gentlemen I think we nailed it!
I made some first checks and works. I had crashes almost every time I changed my provider to OSM.
I will make more tests during the weekend and I will report you back
Thank you again for your efford on this
Hello,
I confirm that no more crashes happened after the last modification and exclusion on old libs
thank you very much for your help.
Nikos
Hello @pmeems, @jerryfaust
which VC redist version must be installed to the target machine for this fix version?
I am using the ISOLATED flag and custom installer without ocx reg.
Hello Nikos.
I believe Paul uses VS2017 for the builds. It looks like you can get the latest redist here, and it will work for 2015, 17, and 19.
Regards,
Jerry.
Yes, I use VS2017 for the build.
I just published a new release candidate: https://github.com/MapWindow/MapWinGIS/releases/tag/v5.2.3 with the fix for the LIBEAY32 problem.
Hello I tried building MW5 v5.6.3 using VS2017 and I ran into these errors. How do I fix these errors? I registered the win32 MapWinGIS.ocx and installed syncfusion winform.
Hi @birkal, sorry for the late reply.
Can you build only the Shared project and then the API project?
If so can you try to build the other projects one by one?
