Hi Simon, On Tue, 20 Feb 2024 at 18:58, Simon Eves via gdal-dev < gdal-dev@lists.osgeo.org> wrote:
> We still have one VERY strange issue whereby FlatGeoBuf export fails in a > very consistent and reproducible form down in the flatbuffer code, but only > in the static build, and only in the full system. I have written a simple > test harness that links the very same static libgdal and does a simple GDAL > startup and FGB export of a single feature and that works fine. It's some > kind of data/stack corruption when it first tries to write to the > flatbuffer on the first feature, which results in a pointer member of the > buffer class becoming 0x100000000000 (always) instead of null, and then it > stops on an assert. There is also one private function in the > vector_downward class which the debugger won't even step into in that > build. I can even put printfs in that function and they don't come out. > I've tried it on CentOS and on Ubuntu, with GCC and Clang, and it's always > the same. Everything else in GDAL works just fine (we have LOTS of > import/export unit tests). This makes zero sense as all the FGB code is > internal to GDAL and compiled together. I've been poking at it for over a > week and it's doing my head in. > One cause of this sort of crash is a header/library mismatch somewhere where a function is expecting different parameters/types than the caller is actually providing. Otherwise, maybe a bug in glibc/libstdc++/gcc/something that's been fixed in the intervening ten years since CentOS 7 was released? If you run your *build* on a modern distro/libc/gcc/etc does it change things? If it's the same, maybe hints more towards the former. ASAN (https://github.com/google/sanitizers/wiki/AddressSanitizer) might help track down stack/heap corruption. Rob :)
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
