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 <and...@aitchison.me.uk>
Enviado el: dijous, 7 de març de 2024 1:01
Para: Daniel Evans <daniel.fred.ev...@gmail.com>
CC: Abel Pau <a....@creaf.uab.cat>; 'gdal-dev@lists.osgeo.org'
(gdal-dev@lists.osgeo.org) <gdal-dev@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
and...@aitchison.me.uk
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
