Ticket #2729 (closed defect: fixed)
msLoadExpressionString() cause memory leaks
| Reported by: | aboudreault | Owned by: | sdlime |
|---|---|---|---|
| Priority: | normal | Milestone: | 5.4 release |
| Component: | MapServer C Library | Version: | svn-trunk (development) |
| Severity: | normal | Keywords: | |
| Cc: | dmorissette |
Description
Every call of msLoadExpressionString() function cause a memory leak. This function is used is few parts in MapServer. I noticed this bug during a test i made. The map that i used for my test had only one layer of type annotation, connectiontype ogr (mapinfo) and styleitem auto. This layer contains around 40 labels. In the function msOGRLayerGetAutoStyle() in mapogr.cpp, the call of the msLoadExpressionString() is made for each label. This cause a lot a memory leaks. msLoadExpressionString() is also called in php/mapscript, in the function classObj->setText(). So, you can easily reproduce the bug with a simple layer, that is a label and try to change the text.
Example:
<?php dl("php_mapscript.so"); $oMap = ms_newMapObj("/opt/fgs/www/test/myMap.map"); echo $oMap->numlayers; $oLayer = $oMap->GetLayer(0); $oClass = $oLayer->getClass(0); $oClass->setText("TEXT HASASASASA"); $oClass->setText("TEXT HASASASASA"); $oClass->setText("TEXT HASASASASA"); $oClass->setText("TEXT HASASASASA"); $oClass->setText("TEXT HASASASASA"); $oClass->setText("TEXT HASASASASA"); $oClass->setText("TEXT HASASASASA"); $oClass->setText("TEXT HASASASASA"); $oClass->setText("TEXT HASASASASA"); $oClass->setText("TEXT HASASASASA"); $oClass->setText("TEXT HASASASASA"); echo "done"; ?>
You'll see memory leaks with php-cli and valgrind. Here is my valgrind's output:
==9956== ERROR SUMMARY: 27 errors from 7 contexts (suppressed: 131 from 1) ==9956== malloc/free: in use at exit: 17,348 bytes in 24 blocks. ==9956== malloc/free: 15,288 allocs, 15,264 frees, 1,866,624 bytes allocated. ==9956== For counts of detected errors, rerun with: -v ==9956== searching for pointers to 24 not-freed blocks. ==9956== checked 748,792 bytes. ==9956== ==9956== ==9956== 17,084 (528 direct, 16,556 indirect) bytes in 11 blocks are definitely lost in loss record 3 of 4 ==9956== at 0x4022AB8: malloc (vg_replace_malloc.c:207) ==9956== by 0x4B7BFEC: ??? ==9956== by 0x4B7C478: ??? ==9956== by 0x4B7C54B: ??? ==9956== by 0x4B9344E: ??? ==9956== by 0x4B46BEE: ??? ==9956== by 0x4B4075D: ??? ==9956== by 0x82C211B: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==9956== by 0x82B4888: execute (zend_vm_execute.h:92) ==9956== by 0x82977E9: zend_execute_scripts (zend.c:1134) ==9956== by 0x825720C: php_execute_script (main.c:2004) ==9956== by 0x831020D: main (php_cli.c:1140) ==9956== ==9956== LEAK SUMMARY: ==9956== definitely lost: 528 bytes in 11 blocks. ==9956== indirectly lost: 16,556 bytes in 11 blocks. ==9956== possibly lost: 0 bytes in 0 blocks. ==9956== still reachable: 264 bytes in 2 blocks. ==9956== suppressed: 0 bytes in 0 blocks.
