[Gdal-dev] ogr2ogr on Red Hat Advanced Server 2.1 vs. Red Hat 9

Doug_Newcomb at fws.gov Doug_Newcomb at fws.gov
Fri Sep 5 10:55:37 EDT 2003

Ask and ye shall recieve.  This is the Valgrind output from the RH Advanced
Server 2.1 box with the 9-3-2003 cvs snapshot (when run by itself, it
appeared to function normally) :

[xxxxxx at xxxxx athens]$ valgrind --leak-check=yes ogr2ogr -t_srs "NAD83" -f
"ESRI Shapefile" dd /gis/import/nwi/athens/aonia_p.shp
==22843== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==22843== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
==22843== Using valgrind-1.9.6, a program instrumentation system for
==22843== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==22843== Estimated CPU clock rate is 1507 MHz
==22843== For more details, rerun with: -v
==22843== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 2)
==22843== malloc/free: in use at exit: 5170 bytes in 327 blocks.
==22843== malloc/free: 8815 allocs, 8489 frees, 3646646 bytes allocated.
==22843== For counts of detected errors, rerun with: -v
==22843== searching for pointers to 327 not-freed blocks.
==22843== checked 9708472 bytes.
==22843== 40 bytes in 1 blocks are definitely lost in loss record 18 of 26
==22843==    at 0x40169994: __builtin_new (vg_clientfuncs.c:129)
==22843==    by 0x804A064: main (in /usr/local/bin/ogr2ogr)
==22843==    by 0x4059B686: __libc_start_main
==22843==    by 0x8049100: (within /usr/local/bin/ogr2ogr)
==22843== 64 bytes in 1 blocks are definitely lost in loss record 19 of 26
==22843==    at 0x40169994: __builtin_new (vg_clientfuncs.c:129)
==22843==    by 0x403D4951:
OGRCreateCoordinateTransformation(OGRSpatialReference *,
OGRSpatialReference *) (in /usr/local/lib/libgdal.1.1.so)
==22843==    by 0x804A577: TranslateLayer(OGRDataSource *, OGRLayer *,
OGRDataSource *, char **, char const *, int, OGRSpatialReference *,
OGRSpatialReference *, char **, int, int) (in /usr/local/bin/ogr2ogr)
==22843==    by 0x804A28E: main (in /usr/local/bin/ogr2ogr)
==22843== LEAK SUMMARY:
==22843==    definitely lost: 104 bytes in 2 blocks.
==22843==    possibly lost:   0 bytes in 0 blocks.
==22843==    still reachable: 5066 bytes in 325 blocks.
==22843==         suppressed: 0 bytes in 0 blocks.
==22843== Reachable blocks (those to which a pointer was found) are not
==22843== To see them, rerun with: --show-reachable=yes

Doug Newcomb
Raleigh, NC

                      Frank Warmerdam                                                                                             
                      <warmerdam at pobox.com>         To:      gdal-dev at remotesensing.org                                           
                      Sent by:                      cc:                                                                           
                      gdal-dev-admin at remote         Subject: Re: [Gdal-dev] ogr2ogr on Red Hat Advanced Server 2.1 vs. Red Hat 9  
                      09/05/2003 10:18 AM                                                                                         
                      Please respond to                                                                                           

Doug_Newcomb at fws.gov wrote:
> Frank,
>       I ran valgrind on the cvs version and I got the following:
> [dnewcomb at r4gis athens]$ valgrind massspogr.pl

> ==22641== FATAL: M_PROCMAP_BUF is too small; increase it and recompile
> shape project failed at /usr/local/bin/massspogr.pl line 47, <NWILIST>
> 1.


It seems you ran valgrind on the perl script rather than the ogr2ogr
I would suggest capturing the exact commandline produced by the perl script
and then executing this by hand with valgrind.

A google search suggests the M_PROCMAP_BUF is some sort of valgrind build
constant.  Presumably we are exceeding some valgrind limit for memory
I don't think it is necessarily a significant issue unless it still happens
when running valgrind against ogr2ogr.

I would add we don't necessarily need the leak checking.  I am hoping to
a memory access (illegal write, etc) error that might cause occasional

Best regards,


I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

Gdal-dev mailing list
Gdal-dev at remotesensing.org

More information about the Gdal-dev mailing list