[DebianGIS-dev] Bug#528557: gdal-bin: gdalinfo segmentation fault with GMT and NetCDF files
Seb
spluque at gmail.com
Wed May 13 16:51:15 UTC 2009
Package: gdal-bin
Version: 1.5.4-3
Severity: normal
gdalinfo segfaults on my Debian sid AMD64 system with netCDF and GMT
binary rasters. A relevant bug report
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495353) has been
closed, although I get the segfault with the same file. Running
gdalinfo under valgrind on the file supplied in that report I get:
---<--------------------cut here---------------start------------------->---
$ valgrind gdalinfo ~/tmp/3n24s47w14w.grd
==30876== Memcheck, a memory error detector.
==30876== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==30876== Using LibVEX rev 1884, a library for dynamic binary translation.
==30876== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==30876== Using valgrind-3.4.1-Debian, a dynamic binary instrumentation framework.
==30876== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==30876== For more details, rerun with: -v
==30876==
==30876== Invalid read of size 4
==30876== at 0x77BB395: NC_var_shape (in /usr/lib/libmfhdf.so.4.1r4)
==30876== by 0x87709C2: nc_get_NC (in /usr/lib/libnetcdf.so.4.0.0)
==30876== by 0x876E6A0: nc__open_mp (in /usr/lib/libnetcdf.so.4.0.0)
==30876== by 0x5008DB0: GMTDataset::Open(GDALOpenInfo*) (in /usr/lib/libgdal1.5.0.so.1.12.4)
==30876== by 0x50E8BAA: GDALOpen (in /usr/lib/libgdal1.5.0.so.1.12.4)
==30876== by 0x402491: (within /usr/bin/gdalinfo)
==30876== by 0x5DC45A5: (below main) (in /lib/libc-2.9.so)
==30876== Address 0x1052 is not stack'd, malloc'd or (recently) free'd
==30876==
==30876== Process terminating with default action of signal 11 (SIGSEGV)
==30876== Access not within mapped region at address 0x1052
==30876== at 0x77BB395: NC_var_shape (in /usr/lib/libmfhdf.so.4.1r4)
==30876== by 0x87709C2: nc_get_NC (in /usr/lib/libnetcdf.so.4.0.0)
==30876== by 0x876E6A0: nc__open_mp (in /usr/lib/libnetcdf.so.4.0.0)
==30876== by 0x5008DB0: GMTDataset::Open(GDALOpenInfo*) (in /usr/lib/libgdal1.5.0.so.1.12.4)
==30876== by 0x50E8BAA: GDALOpen (in /usr/lib/libgdal1.5.0.so.1.12.4)
==30876== by 0x402491: (within /usr/bin/gdalinfo)
==30876== by 0x5DC45A5: (below main) (in /lib/libc-2.9.so)
==30876== If you believe this happened as a result of a stack overflow in your
==30876== program's main thread (unlikely but possible), you can try to increase
==30876== the size of the main thread stack using the --main-stacksize= flag.
==30876== The main thread stack size used in this run was 8720384.
==30876==
==30876== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 28 from 2)
==30876== malloc/free: in use at exit: 91,045 bytes in 1,080 blocks.
==30876== malloc/free: 1,754 allocs, 674 frees, 153,396 bytes allocated.
==30876== For counts of detected errors, rerun with: -v
==30876== searching for pointers to 1,080 not-freed blocks.
==30876== checked 3,032,160 bytes.
==30876==
==30876== LEAK SUMMARY:
==30876== definitely lost: 24 bytes in 1 blocks.
==30876== possibly lost: 2,602 bytes in 87 blocks.
==30876== still reachable: 88,419 bytes in 992 blocks.
==30876== suppressed: 0 bytes in 0 blocks.
==30876== Rerun with --leak-check=full to see details of leaked memory.
Segmentation fault
---<--------------------cut here---------------end--------------------->---
And with a GMT grid having the following grdinfo output (file name
removed for brevity):
Title: /tmp/gmt.TwU3uJ/S2001001050311_2001001082054.GAC_4km.grd
Command: nearneighbor -V -R45/65/-50/-40 -I4k/4k= -bi7 /tmp/gmt.CpBAtF/dump_b -G/tmp/gmt.TwU3uJ/S2001001050311_2001001082054.GAC_4km.grd -F -N8/1 -S4.5K
Remark:
Pixel node registration used
Grid file format: nf (# 18)
x_min: 45 x_max: 65 x_inc: 0.0508906 name: x nx: 393
y_min: -50 y_max: -39.9996 y_inc: 0.0359728 name: y ny: 278
z_min: 0.08149 z_max: 7.95554 name: z
scale_factor: 1 add_offset: 0
the output of valgrind is:
---<--------------------cut here---------------start------------------->---
$ valgrind gdalinfo gmt.TwU3uJ/S2001001050311_2001001082054.GAC_4km.grd
==30911== Memcheck, a memory error detector.
==30911== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==30911== Using LibVEX rev 1884, a library for dynamic binary translation.
==30911== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==30911== Using valgrind-3.4.1-Debian, a dynamic binary instrumentation framework.
==30911== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==30911== For more details, rerun with: -v
==30911==
==30911== Invalid read of size 4
==30911== at 0x77BB395: NC_var_shape (in /usr/lib/libmfhdf.so.4.1r4)
==30911== by 0x87709C2: nc_get_NC (in /usr/lib/libnetcdf.so.4.0.0)
==30911== by 0x876E6A0: nc__open_mp (in /usr/lib/libnetcdf.so.4.0.0)
==30911== by 0x5008DB0: GMTDataset::Open(GDALOpenInfo*) (in /usr/lib/libgdal1.5.0.so.1.12.4)
==30911== by 0x50E8BAA: GDALOpen (in /usr/lib/libgdal1.5.0.so.1.12.4)
==30911== by 0x402491: (within /usr/bin/gdalinfo)
==30911== by 0x5DC45A5: (below main) (in /lib/libc-2.9.so)
==30911== Address 0x1052 is not stack'd, malloc'd or (recently) free'd
==30911==
==30911== Process terminating with default action of signal 11 (SIGSEGV)
==30911== Access not within mapped region at address 0x1052
==30911== at 0x77BB395: NC_var_shape (in /usr/lib/libmfhdf.so.4.1r4)
==30911== by 0x87709C2: nc_get_NC (in /usr/lib/libnetcdf.so.4.0.0)
==30911== by 0x876E6A0: nc__open_mp (in /usr/lib/libnetcdf.so.4.0.0)
==30911== by 0x5008DB0: GMTDataset::Open(GDALOpenInfo*) (in /usr/lib/libgdal1.5.0.so.1.12.4)
==30911== by 0x50E8BAA: GDALOpen (in /usr/lib/libgdal1.5.0.so.1.12.4)
==30911== by 0x402491: (within /usr/bin/gdalinfo)
==30911== by 0x5DC45A5: (below main) (in /lib/libc-2.9.so)
==30911== If you believe this happened as a result of a stack overflow in your
==30911== program's main thread (unlikely but possible), you can try to increase
==30911== the size of the main thread stack using the --main-stacksize= flag.
==30911== The main thread stack size used in this run was 8720384.
==30911==
==30911== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 28 from 2)
==30911== malloc/free: in use at exit: 93,283 bytes in 1,078 blocks.
==30911== malloc/free: 1,752 allocs, 674 frees, 155,647 bytes allocated.
==30911== For counts of detected errors, rerun with: -v
==30911== searching for pointers to 1,078 not-freed blocks.
==30911== checked 3,034,344 bytes.
==30911==
==30911== LEAK SUMMARY:
==30911== definitely lost: 18 bytes in 1 blocks.
==30911== possibly lost: 2,602 bytes in 87 blocks.
==30911== still reachable: 90,663 bytes in 990 blocks.
==30911== suppressed: 0 bytes in 0 blocks.
==30911== Rerun with --leak-check=full to see details of leaked memory.
Segmentation fault
---<--------------------cut here---------------end--------------------->---
I've seen this problem for more than a year.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'oldstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.29-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages gdal-bin depends on:
ii libc6 2.9-12 GNU C Library: Shared libraries
ii libgcc1 1:4.4.0-4 GCC support library
ii libgdal1-1.5.0 1.5.4-3 Geospatial Data Abstraction Librar
ii libstdc++6 4.4.0-4 The GNU Standard C++ Library v3
gdal-bin recommends no packages.
Versions of packages gdal-bin suggests:
pn python-gdal <none> (no description available)
-- no debconf information
Cheers,
--
Seb
More information about the Pkg-grass-devel
mailing list