On Windows, r.in.pdal consistently crashes with an access violation when it starts processing points.
Environment
Tested with the official conda-forge GRASS 8.5 build:
grass 8.5.0 py311h7721632_1
libpdal-core 2.10.0 h1f91b6b_0
Also tested with the current GRASS 8.6 development conda build:
grass-dev dev py311h82bb817_0
libpdal-core 2.10.2 hd7c2432_4
Windows 11, Python 3.11, micromamba/conda environments.
Reproducer
r.in.pdal -eno input="synthetic_test.las" output=synthetic_test resolution=1
Output:
Reading data...
Overriding projection check and assuming that the CRS of input matches the project's CRS
Running PDAL algorithms...
Scanning points...
The process then exits immediately.
returns:
which corresponds to Windows exception 0xC0000005 (access violation).
Tests performed
The same crash occurs with:
- official conda-forge GRASS 8.5
- GRASS 8.6dev conda build
libpdal-core 2.10.0 and 2.10.2- COPC
.laz
- the same data converted to ordinary
.las
method=meanmethod=n- a minimal GRASS environment without QGIS
The issue does not appear to be related to the input data. I also created a synthetic LAS containing only four simple XYZ points, and r.in.pdal crashes in exactly the same way.
Other PDAL-related operations on the same files work correctly:
pdal info --metadata file.las
works.
r.in.pdal -go input=file.las
works and returns the extent.
v.in.pdal -oc input=file.las output=test spatial=...
also works successfully with exit code 0.
So the failure appears to be specific to the rasterization/point-processing path of r.in.pdal on Windows, rather than PDAL file reading or GRASS-PDAL integration in general.
On Windows,
r.in.pdalconsistently crashes with an access violation when it starts processing points.Environment
Tested with the official conda-forge GRASS 8.5 build:
Also tested with the current GRASS 8.6 development conda build:
Windows 11, Python 3.11, micromamba/conda environments.
Reproducer
Output:
The process then exits immediately.
returns:
which corresponds to Windows exception
0xC0000005(access violation).Tests performed
The same crash occurs with:
libpdal-core2.10.0 and 2.10.2.laz.lasmethod=meanmethod=nThe issue does not appear to be related to the input data. I also created a synthetic LAS containing only four simple XYZ points, and
r.in.pdalcrashes in exactly the same way.Other PDAL-related operations on the same files work correctly:
works.
works and returns the extent.
also works successfully with exit code
0.So the failure appears to be specific to the rasterization/point-processing path of
r.in.pdalon Windows, rather than PDAL file reading or GRASS-PDAL integration in general.