<div dir="ltr"><div>Hi Simon,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 20 Feb 2024 at 18:58, Simon Eves via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div><div>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?<span class="gmail-Apple-converted-space"> </span></div><div><br></div><div>If you run your <u>build</u> on a modern distro/libc/gcc/etc does it change things? If it's the same, maybe hints more towards the former. </div><div><br></div><div>ASAN (<a href="https://github.com/google/sanitizers/wiki/AddressSanitizer">https://github.com/google/sanitizers/wiki/AddressSanitizer</a>) might help track down stack/heap corruption.</div><div><br></div><div>Rob :)</div><div><br></div></div></div>