memory leaks in openlayers template page

[tbonfort]

the openlayers template page probably needs some reworking:

• why is a msDrawMap() called when we only need to generate some html ?

• there's an important memory leak (seems like the imageObj created by msDrawMap() is never freed)

attached is a valgrind run:

valgrind --leak-check=full ~/local/bin/mapserv QUERY_STRING='map=/gro1/mapserver-utils/osm-google.map&LAYERS=default&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&FORMAT=application/openlayers&SRS=EPSG%3A3857&BBOX=-20000000,-20000000,20000000,20000000&WIDTH=1024&HEIGHT=512'

(...)

==755== HEAP SUMMARY:
==755==     in use at exit: 2,691,765 bytes in 2,765 blocks
==755==   total heap usage: 99,001 allocs, 96,236 frees, 73,968,350 bytes allocated
==755== 
==755== 300 (60 direct, 240 indirect) bytes in 1 blocks are definitely lost in loss record 262 of 363
==755==    at 0x4C2779D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==755==    by 0x9A2953C: nss_parse_service_list (nsswitch.c:626)
==755==    by 0x9A29D11: __nss_database_lookup (nsswitch.c:167)
==755==    by 0xF9981EF: ???
==755==    by 0xF998D94: ???
==755==    by 0x99E967C: getpwuid_r@@GLIBC_2.2.5 (getXXbyYY_r.c:256)
==755==    by 0x81B1355: ??? (in /usr/lib/libpq.so.5.4)
==755==    by 0x819D30D: ??? (in /usr/lib/libpq.so.5.4)
==755==    by 0x81AEC1B: ??? (in /usr/lib/libpq.so.5.4)
==755==    by 0x81ADA79: ??? (in /usr/lib/libpq.so.5.4)
==755==    by 0x8197B83: PQconnectPoll (in /usr/lib/libpq.so.5.4)
==755==    by 0x8196C86: ??? (in /usr/lib/libpq.so.5.4)
==755== 
==755== 2,559,565 (96 direct, 2,559,469 indirect) bytes in 1 blocks are definitely lost in loss record 363 of 363
==755==    at 0x4C25E84: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==755==    by 0x4F145F8: agg2CreateImage(int, int, outputFormatObj*, colorObj*) (in /home/tbonfort/local/lib/libmapserver-6.1-dev.so)
==755==    by 0x4F08298: msPrepareImage (in /home/tbonfort/local/lib/libmapserver-6.1-dev.so)
==755==    by 0x4F10B1C: msDrawMap (in /home/tbonfort/local/lib/libmapserver-6.1-dev.so)
==755==    by 0x4F016E1: msWMSGetMap (in /home/tbonfort/local/lib/libmapserver-6.1-dev.so)
==755==    by 0x4F0493E: msWMSDispatch (in /home/tbonfort/local/lib/libmapserver-6.1-dev.so)
==755==    by 0x4F2E427: msOWSDispatch (in /home/tbonfort/local/lib/libmapserver-6.1-dev.so)
==755==    by 0x4F661BC: msCGIDispatchRequest (in /home/tbonfort/local/lib/libmapserver-6.1-dev.so)
==755==    by 0x401147: main (in /home/tbonfort/local/bin/mapserv)
==755== 
==755== LEAK SUMMARY:
==755==    definitely lost: 156 bytes in 2 blocks
==755==    indirectly lost: 2,559,709 bytes in 123 blocks
==755==      possibly lost: 0 bytes in 0 blocks
==755==    still reachable: 131,900 bytes in 2,640 blocks
==755==         suppressed: 0 bytes in 0 blocks
==755== Reachable blocks (those to which a pointer was found) are not shown.

[aboudreault]

yeah.... well... the templating system IS supposed to call msDrawMap since it's supposed to plug the image/features in the html. This might need some optimization.. but initially we just used the current templating system. Will try to take a look soon....

[tbonfort]

I can live with the overhead of a call to msDrawMap, but the memory leak on the created imageObj should be fixed as the amount is non-trivial.