[gdal-dev] Build static GDAL-Lib and static GDAL-Apps

[Robert Coup]

Hi Simon,

On Tue, 20 Feb 2024 at 18:58, Simon Eves via gdal-dev <
gdal-dev at 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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240220/ab59ddc9/attachment.htm>