FINALLY! I discovered the problem. I was using “unsigned long” as 4 bytes variable. On windows it’s like that.
BUT on linux this kind of variable has a 8-bytes size. This caused a mess in linux (but not in wondows). So, mistery closed!!!!! Thanks you all. De: gdal-dev <gdal-dev-boun...@lists.osgeo.org> En nombre de Abel Pau via gdal-dev Enviado el: dijous, 7 de març de 2024 23:42 Para: Even Rouault <even.roua...@spatialys.com>; 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 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<mailto:even.roua...@spatialys.com>> Enviado el: dijous, 7 de març de 2024 23:32 Para: Abel Pau <a....@creaf.uab.cat<mailto:a....@creaf.uab.cat>>; Andrew C Aitchison <and...@aitchison.me.uk<mailto:and...@aitchison.me.uk>>; Daniel Evans <daniel.fred.ev...@gmail.com<mailto:daniel.fred.ev...@gmail.com>> CC: 'gdal-dev@lists.osgeo.org' (gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>) <gdal-dev@lists.osgeo.org<mailto: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
