[gdal-dev] Testing the driver

[Javier Jimenez Shaw]

I hate that.
I never use "long" exactly for that problem. When the size is important,
uint64_t and friends are very useful, and well defined.

On Fri, 8 Mar 2024 at 10:16, Abel Pau via gdal-dev <gdal-dev at lists.osgeo.org>
wrote:

> 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>
> *Enviado el:* dijous, 7 de març de 2024 23:32
> *Para:* Abel Pau <a.pau at creaf.uab.cat>; 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
>
>
>
>
>
> 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 at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240308/d57a03bf/attachment-0001.htm>