Hi, It’s in debug mode, yes, as you suggested. yes, it crashes in the same way. Same big number.
It crashes because of the variable is not read from the file (this variable should be 1). But debugging in windows (where not crashes) this variable is set when opening the layer, and then I suppose has the value corrupted at some point. So I am going to put my old fashion printf on. Thanks again! De: Even Rouault <even.roua...@spatialys.com> Enviado el: dijous, 7 de març de 2024 23:32 Para: Abel Pau <a....@creaf.uab.cat>; Andrew C Aitchison <and...@aitchison.me.uk>; Daniel Evans <daniel.fred.ev...@gmail.com> CC: 'gdal-dev@lists.osgeo.org' (gdal-dev@lists.osgeo.org) <gdal-dev@lists.osgeo.org> Asunto: Re: [gdal-dev] Testing the driver At #10 we can see the variable nNum set to a non-sense megabignumber. Is it on a -DCMAKE_BUILD_TYPE=Debug build ? Otherwise stack traces and variable content in the debugger might look like garbage because of optimizations. If it is a debug build, then there's likely some memory corruption or uninitialized variable in your code. Valgrind is generally a great tool to spot that. Otherwise add good old printf() statements to track down where the corruption starts. And given your Python sample code, I assume you could more easily reproduce the issue in a pure native context, just running "ogrinfo -al -q autotest/ogr/data/miramon/Polygons/SimplePolygons/SimplePolFile.pol" (if it doesn't crash, try running it under gdb or valgrind) -- http://www.spatialys.com My software is free, but my time generally not.
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
