Allow to set -if (input format) option in gdalmdiminfo

m-mohr commented 2 years ago

Expected behavior and actual behavior.

Some of the NOAA GEFS GRIB2 files don't have a file extension and I'd like to use gdalmdiminfo to read information about them. While I can rename them locally, in larger deployments it would be nice to be able to enforce a specific input file format regardless of any automatic detection. So it would be nice to get the -if option as it is present in gdalinfo also for gdalmdiminfo. Also, the returned message is not very informative: "Segmentation fault"

Steps to reproduce the problem.

gdalmdiminfo -stats geavg.t00z.pgrb2a.0p50.f000

Returns: "Segmentation fault"

Ideally I could do:

gdalmdiminfo -if GRIB2 -stats geavg.t00z.pgrb2a.0p50.f000

You can download the file here: https://github.com/stactools-packages/noaa-gefs/blob/main/tests/data-files/ncep/atmos/geavg.t00z.pgrb2a.0p50.f000

Operating system

Ubuntu 20.04.4 LTS (through WSL)

GDAL version and provenance

GDAL 3.4.0 (I don't find an -if option in the latest manual, so I assume the version is irrelevant here)

rouault commented 2 years ago

Also, the returned message is not very informative: "Segmentation fault"

I can't reproduce that with a master build or with docker run --rm -it -v $PWD:$PWD osgeo/gdal:alpine-normal-3.4.0 gdalmdiminfo -stats $PWD/geavg.t00z.pgrb2a.0p50.f000

rouault commented 2 years ago

Also, the returned message is not very informative: "Segmentation fault"

Do you have a way to run under gdb and display where it crashes ?

m-mohr commented 2 years ago

@rouault Thanks. I just had to google what gdb is, so I assume no but let me try...

So I installed gdb, but gdb --args gdalmdiminfo geavg.t00z.pgrb2a.0p50.f000 doesn't seem right. It stops at "(No debugging symbols found in gdalmdiminfo)". Is this correct or is it just not working with an "installed" version?

rouault commented 2 years ago

It stops at "(No debugging symbols found in gdalmdiminfo)". Is this correct or is it just not working with an "installed" version?

you can still try to "run", and when it crashes "bt" to get the stack trace, but it will be moderately useful (at best it will just display function/method names, not line numbers). To get something more useful, you'll need to "./configure --enable-debug [other options] && make clean && make && make install" Or perhaps try with latest master with "cmake -DCMAKE_BUILD_TYPE=Debug [other options]"

you can also "apt install valgrind", and "valgrind gdalmdiminfo geavg.t00z.pgrb2a.0p50.f000"

m-mohr commented 2 years ago

The part about running in gdb is a bit confusing honestly, but valgrind gives the following:

$ valgrind gdalmdiminfo geavg.t00z.pgrb2a.0p50.f000
==569== Memcheck, a memory error detector
==569== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==569== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==569== Command: gdalmdiminfo geavg.t00z.pgrb2a.0p50.f000
==569==
==569== Invalid read of size 1
==569==    at 0x483EF46: strlen (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==569==    by 0x4F3016F: ??? (in /usr/lib/libgdal.so.30.0.0)
==569==    by 0x4F31294: ??? (in /usr/lib/libgdal.so.30.0.0)
==569==    by 0x5348CBD: GDALOpenEx (in /usr/lib/libgdal.so.30.0.0)
==569==    by 0x1093EC: ??? (in /usr/bin/gdalmdiminfo)
==569==    by 0x5F30082: (below main) (libc-start.c:308)
==569==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==569==
==569==
==569== Process terminating with default action of signal 11 (SIGSEGV)
==569==  Access not within mapped region at address 0x0
==569==    at 0x483EF46: strlen (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==569==    by 0x4F3016F: ??? (in /usr/lib/libgdal.so.30.0.0)
==569==    by 0x4F31294: ??? (in /usr/lib/libgdal.so.30.0.0)
==569==    by 0x5348CBD: GDALOpenEx (in /usr/lib/libgdal.so.30.0.0)
==569==    by 0x1093EC: ??? (in /usr/bin/gdalmdiminfo)
==569==    by 0x5F30082: (below main) (libc-start.c:308)
==569==  If you believe this happened as a result of a stack
==569==  overflow in your program's main thread (unlikely but
==569==  possible), you can try to increase the size of the
==569==  main thread stack using the --main-stacksize= flag.
==569==  The main thread stack size used in this run was 8388608.
==569==
==569== HEAP SUMMARY:
==569==     in use at exit: 3,473,008 bytes in 28,802 blocks
==569==   total heap usage: 37,396 allocs, 8,594 frees, 7,071,953 bytes allocated
==569==
==569== LEAK SUMMARY:
==569==    definitely lost: 0 bytes in 0 blocks
==569==    indirectly lost: 0 bytes in 0 blocks
==569==      possibly lost: 170,352 bytes in 39 blocks
==569==    still reachable: 3,302,656 bytes in 28,763 blocks
==569==                       of which reachable via heuristic:
==569==                         length64           : 2,220,360 bytes in 23,133 blocks
==569==         suppressed: 0 bytes in 0 blocks
==569== Rerun with --leak-check=full to see details of leaked memory
==569==
==569== For lists of detected and suppressed errors, rerun with: -s
==569== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault

Does this help at all?

rouault commented 2 years ago

```shell
Does this help at all?

not really. A GDAL debug build without optimization would be needed to get something that can be exploited

OSGeo / gdal