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 <[email protected]> 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 <[email protected]> *En nombre de *Abel Pau > via gdal-dev > *Enviado el:* dijous, 7 de març de 2024 23:42 > *Para:* Even Rouault <[email protected]>; Andrew C Aitchison < > [email protected]>; Daniel Evans <[email protected]> > *CC:* '[email protected]' ([email protected]) < > [email protected]> > *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 <[email protected]> > *Enviado el:* dijous, 7 de març de 2024 23:32 > *Para:* Abel Pau <[email protected]>; Andrew C Aitchison < > [email protected]>; Daniel Evans <[email protected]> > *CC:* '[email protected]' ([email protected]) < > [email protected]> > *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 > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
