[gdal-dev] Testing the driver

[Even Rouault]

> 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/20240307/33aebeff/attachment.htm>