Your message dated Sat, 23 May 2009 12:11:47 +0200
with message-id <20090523101146.ga4...@frankie.is-a-geek.org>
and subject line Fixed in experimental
has caused the Debian Bug report #528557,
regarding gdal-bin: gdalinfo segmentation fault with GMT and NetCDF files
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
528557: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528557
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
Package: gdal-bin
Version: 1.6.0-3
This is the same netcdf issue fixed by proper building of the -alt
flavor for HDF4.
--
Francesco P. Lovergine
--- End Message ---
_______________________________________________
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel
