Bug#528557: gdal-bin: gdalinfo segmentation fault with GMT and NetCDF files
Package: gdal-bin Followup-For: Bug #528557 note that in the resolution to bug #495353 (thanks for digging that out) the closing message states that this is fixed in the 1.6.0 package in experiemental, not the 1.5.x packages currently in Sid. You might try installing those and see how it goes. (and the more testing it gets the sooner it moves into Sid) FWIW, I can confirm the segfault in Etch using gdal 1.5.2-3~bpo40+1 from backports.org and the test data attached to bug #495353. Follows is a gdb backtrace of the standard stripped binaries. If needed I can provide a trace against unstripped gdal/trunk self-built binaries but I think that's not needed or useful as Frankie's already on top of the situation. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1244584256 (LWP 14948)] 0xb70a49f0 in NC_var_shape () from /usr/lib/libmfhdf.so.4 (gdb) bt #0 0xb70a49f0 in NC_var_shape () from /usr/lib/libmfhdf.so.4 #1 0xb6f3119f in nc_get_NC () from /usr/lib/libnetcdf.so.3 #2 0xb6ed2bbf in nc__open_mp () from /usr/lib/libnetcdf.so.3 #3 0xb6ed2c48 in nc__open () from /usr/lib/libnetcdf.so.3 #4 0xb6ed2c81 in nc_open () from /usr/lib/libnetcdf.so.3 #5 0xb7abd1ef in GMTDataset::Open () from /usr/lib/libgdal1.5.0.so.1 #6 0xb7bbadc2 in GDALOpen () from /usr/lib/libgdal1.5.0.so.1 #7 0x08049bbd in ?? () #8 0x08aeb040 in ?? () #9 0x in ?? () GMT 4.1.2-1.1 (Etch) says: $ grdinfo 3n24s47w14w.grd 3n24s47w14w.grd: Title: GEBCO One Minute Grid 3n24s47w14w.grd: Command: 1.02 3n24s47w14w.grd: Remark: 3n24s47w14w.grd: Normal node registration used 3n24s47w14w.grd: grdfile format: cs (# 8) 3n24s47w14w.grd: x_min: -47 x_max: -14 x_inc: 0.017 name: user_x_unit nx: 1981 3n24s47w14w.grd: y_min: -24 y_max: 3 y_inc: 0.017 name: user_y_unit ny: 1621 3n24s47w14w.grd: z_min: -7849 z_max: 2585 name: user_z_unit 3n24s47w14w.grd: scale_factor: 1 add_offset: 0 The cs format is GMT 3 netCDF legacy format (short) (depreciated) the work-around is to convert to an old style GMT binary .grd using grdreformat. $ grdreformat 3n24s47w14w.grd 3n24s47w14w_Native.grd=bs # then import into GRASS, GRASS r.in.bin -h -s bytes=2 in=3n24s47w14w_Native.grd out=3n24s47w14w # and set some nice colors GRASS r.colors 3n24s47w14w rules=- EOF nv magenta 0% black -7740 0:0:168 0 84:176:248 0 40:124:0 522 68:148:24 1407 148:228:108 1929 232:228:108 2028 232:228:92 2550 228:160:32 2724 216:116:8 2730 grey 2754 grey 2760 252:252:252 2874 252:252:252 2883 192:192:192 2913 192:192:192 100% 252:252:252 EOF aside: comparing the 2' ETOPO2 data to this version of the 1' GEBCO data it is clear that the ETOPO2 data is far superior even though the resolution is twice as coarse. e.g. the ocean trenches are much better defined and magically new seamounts appear. Is the difference the inclusion of the SS radar altimetry in etopo2? Also it would seem that the entire continental shelf has moves somewhat westward (or is that just further offshore?) in the ETOPO2 data. weird. It would be interesting to compare the two with the GRASS r.roughness addon script. Hamish -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528557: [DebianGIS-dev] Bug#528557: gdal-bin: gdalinfo segmentation fault with GMT and NetCDF files
On Thu, May 14, 2009 at 06:12:58PM +1200, Hamish wrote: Package: gdal-bin Followup-For: Bug #528557 note that in the resolution to bug #495353 (thanks for digging that out) the closing message states that this is fixed in the 1.6.0 package in experiemental, not the 1.5.x packages currently in Sid. You might try installing those and see how it goes. (and the more testing it gets the sooner it moves into Sid) FWIW, I can confirm the segfault in Etch using gdal 1.5.2-3~bpo40+1 from backports.org and the test data attached to bug #495353. Follows is a gdb backtrace of the standard stripped binaries. If needed I can provide a trace against unstripped gdal/trunk self-built binaries but I think that's not needed or useful as Frankie's already on top of the situation. Due to the current status of testing I think I could move the new style hdf4 into sid and wait for testing promotion. I was waiting to have a few updates in testing (- bpo) before moving on, but at this stage it seems we will not have the whole toolchain in testing any time soon. My own schedule was having both HDF4/5 updated in experimental along with gdal 1.6.1 (which fixes a lot of issues) then move all into testing. But this is currently an optimistic idea, we have simply too many migrations in sid... So in the immediate time, I'm going to promote hdf4 in sid, then fix gdal 1.5 series and complete the current plan of support for hdf5. That's the tentative plan, but I still need to re-check current testing global status and blockers. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528557: gdal-bin: gdalinfo segmentation fault with GMT and NetCDF files
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
