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@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-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> > *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 >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
