OSGeo
Segmentation fault in openfilegdb driver during reading attribute table
Expected behavior and actual behavior.
While trying to get info on a Geodatabase (which unfortunately I am not allowed to disclose) both with gdalinfo and ogrinfo I get a Segmentation fault (core dumped) error:
GDAL 3.8.0
Error occurred in /gdal/ogr/ogrsf_frmts/openfilegdb/filegdbtable.cpp at line 1476
GDAL 3.7.3
Error occurred in /gdal/ogr/ogrsf_frmts/openfilegdb/filegdbtable.cpp at line 1477
When using the -json flag with ogrinfo, only the errors are given to stderr. Without the flag, it becomes apparent that ogrinfo reads until a certain Attribute Table is reached and fails after outputting this much:
Layer name: fras_ras_TN202306_Rev01_NW3_TRACKS_LIN
Geometry: None
Feature Count: 0
Layer SRS WKT:
(unknown)
FID Column = raster_id
raster_flags: Integer (0.0)
description: String (65.0)
storage_def: Binary (0.0)
gdalinfo only gives the errors, and no information, with or without -json.
Steps to reproduce the problem.
Run gdalinfo or ogrinfo on this certain faulty geodatabase folder - which unfortunately I'm not allowed to share. If any specific information on it is required, I'm happy to share it.
Operating system
- MacOS Ventura (GDAL 3.7.3).
- alpine-small-3.8.0 image
GDAL version and provenance
- GDAL 3.7.3 installed via homebrew on MacOS
- GDAL 3.8.0 from alpine-small-3.8.0.
Without a reproducer, it is unlikely someone else can fix it. A debug build with the stack trace where it crashes could help. But it might be simplier if you can share the dataset privately with me (even.rouault at spatialys.com)
Thanks for the reply. Unfortunately I'm also not allowed to share more privately, as it's sensitive data. But I can try obtaining the stack trace.
Maybe you could try to create test data by using your current work flow but some non-sensitive data.
Yeah, a script that runs only in some section of the data, and split them again until you found the row or what rows causes this, after that would be a lot easier to create a non-sensite data for a reprex.
Sorry to keep you waiting on this!
I now created a ticket in our company for providing you with more information (either changing the GDB or at least using valgrind). Both valgrind and tools for editing geodatabases are not yet part of our competences, thus it might take some more time.
Small finding about this Geodatabase: It appears, that it has an unusual Raster layer inside it. Usually a raster layer named Foobar is stored via five tables - fras_aux_Foobar, fras_blk_Foobar, fras_bnd_Foobar, fras_ras_Foobar and Foobar. In this particular database the first four are on the root level, and the fifth one (without any "fras" prefix) is stored within a group instead.
Not sure if this helps and is related to the issue, but it is something new we noticed. The ticket for providing you with more information for debugging is in our company backlog
Unfortunately not. As I'm on parental leave for quite some time I can only report back on it later this year. Maybe the ticket will bubble up earlier in the team and a colleague of mine will report back. Sorry to keep this dangling like this - is it okay to keep this issue on hold for a few months longer?
18.04.2024 18:01:44 Even Rouault @.***>:
@MichiHo[https://github.com/MichiHo] any update on this?
— Reply to this email directly, view it on GitHub[https://github.com/OSGeo/gdal/issues/8698#issuecomment-2064362405], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AC7RUU4WEHPZF2TOKWDBAFDY57U6NAVCNFSM6AAAAAA7IZJGOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRUGM3DENBQGU]. You are receiving this because you were mentioned. [Verfolgungsbild][https://github.com/notifications/beacon/AC7RUU5233NZKG5IR57XV6TY57U6NA5CNFSM6AAAAAA7IZJGOOWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT3BOV2K.gif]
is it okay to keep this issue on hold for a few months longer?
yes, no problem