parquet file exported from QGIS causes crash when loaded into a project

[freeshrugsxd]

What is the bug or the crash?

After exporting a layer to geoparquet with GEOMETRY_ENCODING set to GEOARROW it crashes QGIS when loaded into a project.

See the attached sample project. The provided parquet file was exported from the geojson that is already loaded into the project. Just add the parquet file to trigger the crash.

parquet_export_bug.zip

Steps to reproduce the issue

1. add / create any layer
2. export to parquet file with GEOMETRY_ENCODING set to GEOARROW
3. add newly created parquet file to project

Versions

QGIS version	3.38.0-Grenoble
QGIS code revision	37aa618
Qt version	5.15.13
Python version	3.12.4
GDAL/OGR version	3.9.0
PROJ version	9.4.0
EPSG Registry database version	v11.004 (2024-02-24)
GEOS version	3.12.2-CAPI-1.18.2
SQLite version	3.45.1
PDAL version	2.6.3
PostgreSQL client version	16.2
SpatiaLite version	5.1.0
QWT version	6.2.0
QScintilla2 version	2.14.1
OS version	Windows 10 Version 2009

Active Python plugins

Name	Version
db_manager	0.1.20
grassprovider	2.12.99
MetaSearch	0.3.6
processing	2.12.99

Supported QGIS version

• I'm running a supported QGIS version according to the roadmap.

New profile

• I tried with a new QGIS profile

Additional context

Python Stack Trace
Windows fatal exception: access violation

Thread 0x000027a8 (most recent call first):


Stack Trace

arrow::StructArray::fields :
CPLODBCDriverInstaller::RemoveDriver :
CPLODBCDriverInstaller::RemoveDriver :
CPLODBCDriverInstaller::RemoveDriver :
CPLODBCDriverInstaller::RemoveDriver :
QgsSQLiteExpressionCompiler::operator= :
QgsAbstractFeatureIterator::nextFeature :
QgsVectorLayerFeatureIterator::fetchFeature :
QgsAbstractFeatureIterator::nextFeature :
QgsVectorLayerProfileResults::visitFeaturesInRange :
QgsVectorLayerProfileResults::visitFeaturesInRange :
QgsVectorLayerProfileResults::visitFeaturesInRange :
QgsMapRendererParallelJob::renderLayerStatic :
QgsProfilePlotRenderer::replaceSourceInternal :
QgsMapRendererParallelJob::renderingFinished :
QgsProfilePlotRenderer::cancelGenerationWithoutBlocking :
QtConcurrent::ThreadEngineBase::run :
QThreadPoolPrivate::reset :
QThread::start :
BaseThreadInitThunk :
RtlUserThreadStart :


QGIS Info
QGIS Version: 3.38.0-Grenoble
QGIS code revision: 37aa6188bc
Compiled against Qt: 5.15.13
Running against Qt: 5.15.13
Compiled against GDAL: 3.9.0
Running against GDAL: 3.9.0


System Info
CPU Type: x86_64
Kernel Type: winnt
Kernel Version: 10.0.19045

[agiudiceandrea]

The crash doesn't occur on Windows 10 using QGIS 3.34.5 or QGIS 3.36.1 from OSGeo4W. I suspect the issue may be due to some library used by QGIS and may have been triggered by the "load of updates in OSGeo4W" https://lists.osgeo.org/pipermail/qgis-user/2024-April/054334.html.

Here another crash report using QGIS 3.38.0 (OSGeo4W) with GDAL/OGR 3.9.1 on Windows 10

Python Stack Trace
Windows fatal exception: access violation

Thread 0x00002b40 (most recent call first):
  


Stack Trace


arrow::Array::IsValid :
arrow::Array::IsNull :
CPLODBCDriverInstaller::RemoveDriver :
CPLODBCDriverInstaller::RemoveDriver :
QgsSQLiteExpressionCompiler::operator= :
QgsAbstractFeatureIterator::nextFeature :
QgsVectorLayerFeatureIterator::fetchFeature :
QgsAbstractFeatureIterator::nextFeature :
QgsVectorLayerProfileResults::visitFeaturesInRange :
QgsVectorLayerProfileResults::visitFeaturesInRange :
QgsVectorLayerProfileResults::visitFeaturesInRange :
QgsMapRendererParallelJob::renderLayerStatic :
QgsProfilePlotRenderer::replaceSourceInternal :
QgsMapRendererParallelJob::renderingFinished :
QgsProfilePlotRenderer::cancelGenerationWithoutBlocking :
QtConcurrent::ThreadEngineBase::run :
QThreadPoolPrivate::reset :
QThread::start :
BaseThreadInitThunk :
RtlUserThreadStart :




QGIS Info
QGIS Version: 3.38.0-Grenoble
QGIS code revision: 37aa6188bc
Compiled against Qt: 5.15.13
Running against Qt: 5.15.13
Compiled against GDAL: 3.9.0
Running against GDAL: 3.9.1



System Info
CPU Type: x86_64
Kernel Type: winnt
Kernel Version: 10.0.18362

[rouault]

GDAL upstream bug. Fix in OSGeo/gdal#10815