[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
x86-linux.
==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==
==22843==
==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==
==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
(../sysdeps/generic/libc-start.c:129)
==22843== by 0x8049100: (within /usr/local/bin/ogr2ogr)
==22843==
==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==
==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
shown.
==22843== To see them, rerun with: --show-reachable=yes
==22843==
Doug Newcomb
USFWS
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
sensing.org
09/05/2003 10:18 AM
Please respond to
gdal-dev
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>
line
> 1.
Doug,
It seems you ran valgrind on the perl script rather than the ogr2ogr
program.
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
tracking.
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
find
a memory access (illegal write, etc) error that might cause occasional
failure.
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
http://remotesensing.org/mailman/listinfo/gdal-dev
More information about the Gdal-dev
mailing list