[gdal-dev] Testing the driver

Abel Pau a.pau at creaf.uab.cat
Thu Mar 7 14:12:18 PST 2024


Hi,
I think that I found the way to debug and the trace makes me ask a question that can be interesting to everybody who uses python and it's not an expert, like me.

In my test I do:
ds = gdal.OpenEx("data/miramon/Polygons/SimplePolygons/SimplePolFile.pol")
lyr = ds.GetLayer(0)
assert lyr is not None, "Failed to get layer"
assert lyr.GetFeatureCount() == 3
assert lyr.GetGeomType() == ogr.wkbPolygon
f = lyr.GetNextFeature()

And at that moment there is a backtrace available:
#9  0x00007ffff4b3d86c in CPLRealloc (pData=0x0, nNewSize=667227037326010464) at /gdal/port/cpl_conv.cpp:280
#10 0x00007ffff5cb638a in MMResizeMiraMonPolygonArcs (pFID=0x555556456358, nMax=0x555556456348,
    nNum=4653387708260263558, nIncr=0, nProposedMax=0) at /gdal/ogr/ogrsf_frmts/miramon/mm_wrlayr.c:4464
#11 0x00007ffff5cc33e4 in MMGetMultiPolygonCoordinates (hMiraMonLayer=0x555556446fd0, i_pol=1, flag_z=0)
    at /gdal/ogr/ogrsf_frmts/miramon/mm_rdlayr.c:353
#12 0x00007ffff5cc3dfb in MMGetGeoFeatureFromVector (hMiraMonLayer=0x555556446fd0, i_elem=1)
    at /gdal/ogr/ogrsf_frmts/miramon/mm_rdlayr.c:614
#13 0x00007ffff5ca6d63 in OGRMiraMonLayer::GetFeature (this=0x555556419300, nFeatureId=1)
    at /gdal/ogr/ogrsf_frmts/miramon/ogrmiramonlayer.cpp:860
#14 0x00007ffff5ca6598 in OGRMiraMonLayer::GetNextRawFeature (this=0x555556419300)
    at /gdal/ogr/ogrsf_frmts/miramon/ogrmiramonlayer.cpp:696
#15 0x00007ffff5cac1df in OGRGetNextFeatureThroughRaw<OGRMiraMonLayer>::GetNextFeature (this=0x555556419300)
    at /gdal/ogr/ogrsf_frmts/ogrsf_frmts.h:455
#16 0x00007ffff5cac186 in OGRMiraMonLayer::GetNextFeature (this=0x555556419300)
    at /gdal/ogr/ogrsf_frmts/miramon/ogrmiramon.h:109
#17 0x00007ffff60e860b in OGR_L_GetNextFeature (hLayer=0x555556419300)

At #10 we can see the variable nNum set to a non-sense megabignumber.
This variable is set during Opening... 

But my question is: The opening is in ds = gdal.OpenEx("data/miramon/Polygons/SimplePolygons/SimplePolFile.pol")
The variable is stored in a C++ class member (in a old fashion C struct) but available that it's filled in the opening.

After that, lyr = ds.GetLayer(0) is called.
And after that when lyr.GetNextFeature() is called... is this nNum set before still alive?
Or perhaps I should read every time I Get a Next Feature?

Thanks for answering this question!

Thanks Daniel for your pacience.



-----Mensaje original-----
De: Andrew C Aitchison <andrew at aitchison.me.uk> 
Enviado el: dijous, 7 de març de 2024 1:01
Para: Daniel Evans <daniel.fred.evans at gmail.com>
CC: Abel Pau <a.pau at creaf.uab.cat>; '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

On Wed, 6 Mar 2024, Daniel Evans via gdal-dev wrote:

> Is it worth moving this in-depth discussion to a PR or similar for the 
> new driver?
>
> My thinking is that a lengthy discussion on memory leak detection 
> techniques in C++, how to run tests in Python, etc., aren't topics 
> relevant to most GDAL mailing list subscribers.

Maybe so, but how to develop gdal is surely on-topic for gdal-dev ?

I"m still following and learning.

-- 
Andrew C. Aitchison                      Kendal, UK
                    andrew at aitchison.me.uk


More information about the gdal-dev mailing list