valgrind leaks #4794

Closed
tbonfort opened this Issue Oct 15, 2013 · 3 comments

Comments

Projects
None yet
3 participants
@tbonfort
Member

tbonfort commented Oct 15, 2013

some leaks detected by valgrind in the autotests

  • [ ]
==11763== 54 bytes in 3 blocks are definitely lost in loss record 131 of 251
==11763==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11763==    by 0x4ED68B2: msSetOutputFormatOption (mapoutput.c:747)
==11763==    by 0x4ED542A: msCreateDefaultOutputFormat (mapoutput.c:192)
==11763==    by 0x4ED5281: msCreateDefaultOutputFormat (mapoutput.c:164)
==11763==    by 0x4FD8FD3: loadOutputFormat (mapfile.c:4947)
==11763==    by 0x4FDDF3D: loadMapInternal (mapfile.c:6269)
==11763==    by 0x4FDEA7C: msLoadMap (mapfile.c:6522)
==11763==    by 0x401677: main (shp2img.c:126)
==11763==
==11763== 60 bytes in 3 blocks are definitely lost in loss record 133 of 251
==11763==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11763==    by 0x4ED68B2: msSetOutputFormatOption (mapoutput.c:747)
==11763==    by 0x4ED5444: msCreateDefaultOutputFormat (mapoutput.c:193)
==11763==    by 0x4ED5281: msCreateDefaultOutputFormat (mapoutput.c:164)
==11763==    by 0x4FD8FD3: loadOutputFormat (mapfile.c:4947)
==11763==    by 0x4FDDF3D: loadMapInternal (mapfile.c:6269)
==11763==    by 0x4FDEA7C: msLoadMap (mapfile.c:6522)
==11763==    by 0x401677: main (shp2img.c:126)
==11763==
  • [ ]
==10997== 24 bytes in 1 blocks are still reachable in loss record 97 of 251
==10997==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10997==    by 0x60AE89A: ??? (in /usr/lib/libfribidi.so.0.3.1)
==10997==    by 0x60AEBBA: ??? (in /usr/lib/libfribidi.so.0.3.1)
==10997==    by 0x60AEE08: ??? (in /usr/lib/libfribidi.so.0.3.1)
==10997==    by 0x60AEE72: ??? (in /usr/lib/libfribidi.so.0.3.1)
==10997==    by 0x60AD12B: fribidi_get_par_embedding_levels (in /usr/lib/libfribidi.so.0.3.1)
==10997==    by 0x504A4F7: msLayoutTextSymbol (textlayout.c:609)
==10997==    by 0x4F3F2E0: msComputeTextPath (maplabel.c:174)
==10997==    by 0x4F8E59F: msDrawLabelCache (mapdraw.c:2803)
==10997==    by 0x4F834E4: msDrawMap (mapdraw.c:402)
==10997==    by 0x40217B: main (shp2img.c:293)
==10997==
==10997== 4,080 bytes in 1 blocks are possibly lost in loss record 248 of 251
==10997==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10997==    by 0x60AE802: ??? (in /usr/lib/libfribidi.so.0.3.1)
==10997==    by 0x60AEBD2: ??? (in /usr/lib/libfribidi.so.0.3.1)
==10997==    by 0x60AEE08: ??? (in /usr/lib/libfribidi.so.0.3.1)
==10997==    by 0x60AEE72: ??? (in /usr/lib/libfribidi.so.0.3.1)
==10997==    by 0x60AD12B: fribidi_get_par_embedding_levels (in /usr/lib/libfribidi.so.0.3.1)
==10997==    by 0x504A4F7: msLayoutTextSymbol (textlayout.c:609)
==10997==    by 0x4F3F2E0: msComputeTextPath (maplabel.c:174)
==10997==    by 0x4F8E59F: msDrawLabelCache (mapdraw.c:2803)
==10997==    by 0x4F834E4: msDrawMap (mapdraw.c:402)
==10997==    by 0x40217B: main (shp2img.c:293)
==10997==
  • [ ]
==11964== 4 bytes in 1 blocks are definitely lost in loss record 2 of 250
==11964==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11964==    by 0x540FD81: strdup (strdup.c:43)
==11964==    by 0x4F02F76: msStrdup (mapstring.c:2060)
==11964==    by 0x4ED6212: msSelectOutputFormat (mapoutput.c:576)
==11964==    by 0x4ED519D: msPostMapParseOutputFormatSetup (mapoutput.c:137)
==11964==    by 0x4FDDB52: loadMapInternal (mapfile.c:6203)
==11964==    by 0x4FDEA7C: msLoadMap (mapfile.c:6522)
==11964==    by 0x4EE678F: msCGILoadMap (mapservutil.c:220)
==11964==    by 0x401002: main (mapserv.c:238)
==11964==
  • [ ]
==11824== 56 bytes in 1 blocks are indirectly lost in loss record 137 of 259
==11824==    at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11824==    by 0xA7DC612: geos::geom::GeometryFactory::createLinearRing(geos::geom::CoordinateSequence*) const (in /usr/lib/libgeos-3.3.8.so)
==11824==    by 0x67FEBB7: GEOSGeom_createLinearRing_r (in /usr/lib/libgeos_c.so.1.7.8)
==11824==    by 0x4EB612C: msGEOSShape2Geometry_simplepolygon (mapgeos.c:262)
==11824==    by 0x4EB63CD: msGEOSShape2Geometry_polygon (mapgeos.c:317)
==11824==    by 0x4EB65A9: msGEOSShape2Geometry (mapgeos.c:365)
==11824==    by 0x4EB8046: msGEOSIntersects (mapgeos.c:1211)
==11824==    by 0x4F5C139: msHitTestLayer (hittest.c:214)
==11824==    by 0x4F5C4BC: msHitTestMap (hittest.c:285)
==11824==    by 0x4ECC8D4: msWMSGetContentDependantLegend (mapwms.c:4619)
==11824==    by 0x4ECE0C3: msWMSDispatch (mapwms.c:5027)
==11824==    by 0x4EDFC86: msOWSDispatch (mapows.c:244)
==11824==
==11824== 80 bytes in 1 blocks are indirectly lost in loss record 177 of 259
==11824==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11824==    by 0x4F43D9F: msAddLine (mapprimitive.c:316)
==11824==    by 0x4F44075: msRectToPolygon (mapprimitive.c:382)
==11824==    by 0x4F5BFF3: msHitTestLayer (hittest.c:187)
==11824==    by 0x4F5C4BC: msHitTestMap (hittest.c:285)
==11824==    by 0x4ECC8D4: msWMSGetContentDependantLegend (mapwms.c:4619)
==11824==    by 0x4ECE0C3: msWMSDispatch (mapwms.c:5027)
==11824==    by 0x4EDFC86: msOWSDispatch (mapows.c:244)
==11824==    by 0x4EED6E2: msCGIDispatchRequest (mapservutil.c:1647)
==11824==    by 0x401055: main (mapserv.c:259)
==11824==
==11824== 96 (16 direct, 80 indirect) bytes in 1 blocks are definitely lost in loss record 227 of 259
==11824==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11824==    by 0x4F43E53: msAddLineDirectly (mapprimitive.c:333)
==11824==    by 0x4F43E2D: msAddLine (mapprimitive.c:321)
==11824==    by 0x4F44075: msRectToPolygon (mapprimitive.c:382)
==11824==    by 0x4F5BFF3: msHitTestLayer (hittest.c:187)
==11824==    by 0x4F5C4BC: msHitTestMap (hittest.c:285)
==11824==    by 0x4ECC8D4: msWMSGetContentDependantLegend (mapwms.c:4619)
==11824==    by 0x4ECE0C3: msWMSDispatch (mapwms.c:5027)
==11824==    by 0x4EDFC86: msOWSDispatch (mapows.c:244)
==11824==    by 0x4EED6E2: msCGIDispatchRequest (mapservutil.c:1647)
==11824==    by 0x401055: main (mapserv.c:259)
  • [ ]
==10763== Invalid read of size 1
==10763==    at 0x4C2DCAB: bcmp (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10763==    by 0x4EB1006: msGetFontFace (fontcache.c:204)
==10763==    by 0x50492EF: check_single_font (textlayout.c:227)
==10763==    by 0x50495B4: get_face_for_run (textlayout.c:294)
==10763==    by 0x504AB60: msLayoutTextSymbol (textlayout.c:681)
==10763==    by 0x4F3F2E0: msComputeTextPath (maplabel.c:174)
==10763==    by 0x4F4B52A: msLineLabelPath (mapprimitive.c:1828)
==10763==    by 0x4F4B3D9: msPolylineLabelPath (mapprimitive.c:1775)
==10763==    by 0x4F884AD: lineLayerDrawShape (mapdraw.c:1616)
==10763==    by 0x4F89DC5: msDrawShape (mapdraw.c:1961)
==10763==    by 0x4F85573: msDrawVectorLayer (mapdraw.c:993)
==10763==    by 0x4F84662: msDrawLayer (mapdraw.c:728)
==10763==  Address 0x16571080 is 0 bytes inside a block of size 8 free'd
==10763==    at 0x4C2A82E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10763==    by 0x4FCC742: freeLabel (mapfile.c:1779)
==10763==    by 0x4F3F526: freeTextSymbol (maplabel.c:209)
==10763==    by 0x4F88914: lineLayerDrawShape (mapdraw.c:1692)
==10763==    by 0x4F89DC5: msDrawShape (mapdraw.c:1961)
==10763==    by 0x4F85573: msDrawVectorLayer (mapdraw.c:993)
==10763==    by 0x4F84662: msDrawLayer (mapdraw.c:728)
==10763==    by 0x4F8326A: msDrawMap (mapdraw.c:351)
==10763==    by 0x40217B: main (shp2img.c:293)
==10763==
==10763== Invalid read of size 1
==10763==    at 0x4C2DCC0: bcmp (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10763==    by 0x4EB1006: msGetFontFace (fontcache.c:204)
==10763==    by 0x50492EF: check_single_font (textlayout.c:227)
==10763==    by 0x50495B4: get_face_for_run (textlayout.c:294)
==10763==    by 0x504AB60: msLayoutTextSymbol (textlayout.c:681)
==10763==    by 0x4F3F2E0: msComputeTextPath (maplabel.c:174)
==10763==    by 0x4F4B52A: msLineLabelPath (mapprimitive.c:1828)
==10763==    by 0x4F4B3D9: msPolylineLabelPath (mapprimitive.c:1775)
==10763==    by 0x4F884AD: lineLayerDrawShape (mapdraw.c:1616)
==10763==    by 0x4F89DC5: msDrawShape (mapdraw.c:1961)
==10763==    by 0x4F85573: msDrawVectorLayer (mapdraw.c:993)
==10763==    by 0x4F84662: msDrawLayer (mapdraw.c:728)
==10763==  Address 0x16571081 is 1 bytes inside a block of size 8 free'd
==10763==    at 0x4C2A82E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10763==    by 0x4FCC742: freeLabel (mapfile.c:1779)
==10763==    by 0x4F3F526: freeTextSymbol (maplabel.c:209)
==10763==    by 0x4F88914: lineLayerDrawShape (mapdraw.c:1692)
==10763==    by 0x4F89DC5: msDrawShape (mapdraw.c:1961)
==10763==    by 0x4F85573: msDrawVectorLayer (mapdraw.c:993)
==10763==    by 0x4F84662: msDrawLayer (mapdraw.c:728)
==10763==    by 0x4F8326A: msDrawMap (mapdraw.c:351)
==10763==    by 0x40217B: main (shp2img.c:293)
@dmorissette

This comment has been minimized.

Show comment
Hide comment
@dmorissette

dmorissette May 12, 2015

Contributor

@tbonfort, we came across one of the errors above (not a leak but an actual error). Did you look into it, or need a testcase to look into it?

==10763== Invalid read of size 1
==10763==    at 0x4C2DCAB: bcmp (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10763==    by 0x4EB1006: msGetFontFace (fontcache.c:204)
==10763==    by 0x50492EF: check_single_font (textlayout.c:227)
...
Contributor

dmorissette commented May 12, 2015

@tbonfort, we came across one of the errors above (not a leak but an actual error). Did you look into it, or need a testcase to look into it?

==10763== Invalid read of size 1
==10763==    at 0x4C2DCAB: bcmp (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10763==    by 0x4EB1006: msGetFontFace (fontcache.c:204)
==10763==    by 0x50492EF: check_single_font (textlayout.c:227)
...
@tbonfort

This comment has been minimized.

Show comment
Hide comment
@tbonfort

tbonfort Jun 16, 2015

Member

@dmorissette 6b982bb should have taken care of it, can you confirm?

Member

tbonfort commented Jun 16, 2015

@dmorissette 6b982bb should have taken care of it, can you confirm?

@jratike80

This comment has been minimized.

Show comment
Hide comment
@jratike80

jratike80 Nov 9, 2015

So, it this OK now?

So, it this OK now?

@tbonfort tbonfort closed this Nov 10, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment