Opened 15 years ago

Last modified 14 years ago

#2996 closed defect

memory leak in function msOGRFileOpen — at Version 2

Reported by: linuxsch Owned by: dmorissette
Priority: normal Milestone: 6.0 release
Component: OGR Support Version: 5.4
Severity: normal Keywords:
Cc: warmerdam, dmorissette

Description (last modified by dmorissette)

there have memory leak in function msOGRFileOpen.

==4650== 
==4650== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 2)
==4650== malloc/free: in use at exit: 1,089 bytes in 34 blocks.
==4650== malloc/free: 34,791 allocs, 34,757 frees, 173,579,917 bytes allocated.
==4650== For counts of detected errors, rerun with: -v
==4650== searching for pointers to 34 not-freed blocks.
==4650== checked 1,735,624 bytes.
==4650== 
==4650== 32 (16 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 14
==4650==    at 0x4904A06: malloc (vg_replace_malloc.c:149)
==4650==    by 0x4DBA312: CPLPushErrorHandler (in /usr/local/lib/libgdal.so.1.11.4)
==4650==    by 0x42EB3D: msOGRFileOpen(layer_obj*, char const*) (in /home/gsm/program/testmap_5x/src/testmap_5x)
==4650==    by 0x42F1D5: msOGRLayerOpen (in /home/gsm/program/testmap_5x/src/testmap_5x)
==4650==    by 0x40C3C9: myQueryByPoint(map_obj*, std::string, std::string, int, pointObj, double, std::list<MapQueryResult, std::allocator<MapQueryResult> >&) (myMapQuery.cpp:278)
==4650==    by 0x40CF99: QueryInArea(map_obj*, double, double, std::string, std::string, int) (testmap_5x.cpp:19)
==4650==    by 0x40D56A: main (testmap_5x.cpp:109)

Change History (2)

comment:1 by sdlime, 15 years ago

Component: MapServer C LibraryOGR Support
Owner: changed from sdlime to dmorissette

comment:2 by dmorissette, 15 years ago

Cc: warmerdam added
Description: modified (diff)
Milestone: 6.0 release
Status: newassigned

This specific one is a one-time leak of 32 bytes to set a OGR Error handler. I'll check if we could unset this in msCleanup() but I don't think this one is serious and I wouldn't worry about it too much.

However, I see that there were a total of "1,089 bytes in 34 blocks" in use at exit... so what about the other 33 blocks of leaked memory? Were they in the MapServer code or in your own program?

Note: See TracTickets for help on using tickets.