[gdal-dev] Testing the driver

[Abel Pau]

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-bounces at 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.rouault at spatialys.com>; Andrew C Aitchison <andrew at aitchison.me.uk>; Daniel Evans <daniel.fred.evans at gmail.com>
CC: 'gdal-dev at lists.osgeo.org' (gdal-dev at lists.osgeo.org) <gdal-dev at 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.rouault at spatialys.com<mailto:even.rouault at spatialys.com>>
Enviado el: dijous, 7 de març de 2024 23:32
Para: Abel Pau <a.pau at creaf.uab.cat<mailto:a.pau at creaf.uab.cat>>; Andrew C Aitchison <andrew at aitchison.me.uk<mailto:andrew at aitchison.me.uk>>; Daniel Evans <daniel.fred.evans at gmail.com<mailto:daniel.fred.evans at gmail.com>>
CC: 'gdal-dev at lists.osgeo.org' (gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>) <gdal-dev at lists.osgeo.org<mailto:gdal-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240308/7db018c7/attachment-0001.htm>