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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org