loading spatial extension fails in fedora-clang

[Cidree]

Hello,

I am developing a package to work with the spatial extension called duckspatial.

When the examples are run in <r-devel-linux-x86_64-fedora-clang> I get these check results, suggesting that R aborts after running:

DBI::dbExecute(conn, "LOAD spatial;")

Indeed, I tried the code in the REPREX and fails. Do you know if there's some incompatibility with this operating system, or any clue why this is failing?

REPREX in <r-devel-linux-x86_64-fedora-clang>

## load package
library(duckdb)
 
## connect to in memory database
conn <- dbConnect(duckdb::duckdb())

## install extension in <r-devel-linux-x86_64-fedora-clang>
dbExecute(conn, "LOAD spatial;")

[krlmlr]

Thanks. I see, on macOS:

library(duckdb)
#> Loading required package: DBI

conn <- dbConnect(duckdb::duckdb())

dbExecute(conn, "LOAD spatial")
#> Error in `duckdb_result()` at duckdb-r/R/dbSendQuery__duckdb_connection_character.R:16:3:
#> ! rapi_execute: Failed to run query
#> Error: IO Error: Extension "/Users/kirill/Library/Application Support/org.R-project.R/R/duckdb/extensions/v1.2.2/osx_arm64/spatial.duckdb_extension" not found.
#> Extension "spatial" is an existing extension.
#> 
#> Install it first using "INSTALL spatial".

dbExecute(conn, "INSTALL spatial")
#> [1] 0
dbExecute(conn, "LOAD spatial")
#> [1] 0

^{Created on 2025-04-20 with reprex v2.1.1}

[krlmlr]

Can you replicate the Fedora results in a Docker container?

[Cidree]

Hello @krlmlr

I replicated the results in rhub/clang18:

docker pull rhub/clang18
docker run -it rhub/clang18 bash

apt update
apt install -y r-base r-base-dev
R

R Under development (unstable) (2025-04-18 r88159) -- "Unsuffered Consequences"
Copyright (C) 2025 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

options(repos = c(CRAN = "https://cloud.r-project.org"))
install.packages("duckdb")

The downloaded source packages are in
        ‘/tmp/Rtmp8r5P0M/downloaded_packages’
> library(duckdb)
Loading required package: DBI
> conn <- dbConnect(duckdb())
> dbExecute(conn, "INSTALL spatial")
[1] 0
> dbExecute(conn, "LOAD spatial")

 *** caught segfault ***
address (nil), cause 'unknown'

Traceback:
 1: rethrow_rapi_execute(res@stmt_lst$ref, res@arrow, res@connection@bigint ==     "integer64")
 2: duckdb_execute(res)
 3: duckdb_result(connection = conn, stmt_lst = stmt_lst, arrow = arrow)
 4: .local(conn, statement, ...)
 5: dbSendQuery(conn, statement, ...)
 6: dbSendQuery(conn, statement, ...)
 7: dbSendStatement(conn, statement, ...)
 8: dbSendStatement(conn, statement, ...)
 9: dbExecute(conn, "LOAD spatial")
10: dbExecute(conn, "LOAD spatial")

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: install.packages("duckdb")

[Cidree]

In rhub/fedora-clang:latest I didn't find any errors.

In rhub/clang20 I found the same error as in my previous response.

[krlmlr]

Thanks. Both clang18 and clang20 images use rig to install R, and are based on Ubuntu. The rhub/fedora-clang image seems to have been pushed one year ago or more, the source might be https://github.com/r-hub/rhub-linux-builders/blob/master/fedora-clang/Dockerfile, based on https://github.com/r-hub/rhub-linux-builders/blob/master/fedora/Dockerfile, ultimately based on fedora:36. How did you install R on the Fedora image?

Trying to replicate on clang20 now.

[krlmlr]

The rhub/clang18 images come with R preinstalled. The apt install r-base command also installs the release version of R, but the R command still uses the version that comes with the image.

If the target system is Fedora, will the rhub/clang18 tests help us understand the failure there? We'll see.

[krlmlr]

I'm seeing the same error on rhub/clang18:

FROM rhub/clang18
RUN R -q -e 'options(repos = c(CRAN = "https://cloud.r-project.org")); install.packages("duckdb")'

R -q -e 'library(duckdb); conn <- dbConnect(duckdb()); dbExecute(conn, "INSTALL spatial"); dbExecute(conn, "LOAD spatial")'

[krlmlr]

Loading required package: DBI
[1] 0

 *** caught segfault ***
address 0x315f5f3374538e, cause 'memory not mapped'

Traceback:
 1: rethrow_rapi_execute(res@stmt_lst$ref, res@arrow, res@connection@bigint ==     "integer64")
 2: duckdb_execute(res)
 3: duckdb_result(connection = conn, stmt_lst = stmt_lst, arrow = arrow)
 4: .local(conn, statement, ...)
 5: dbSendQuery(conn, statement, ...)
 6: dbSendQuery(conn, statement, ...)
 7: dbSendStatement(conn, statement, ...)
 8: dbSendStatement(conn, statement, ...)
 9: dbExecute(conn, "LOAD spatial")
10: dbExecute(conn, "LOAD spatial")
An irrecoverable exception occurred. R is aborting now ...
Segmentation fault

[krlmlr]

@Maxxen: We can't seem to load the prebuilt spatial extension when compiling the duckdb R package with clang. Is this expected? How to work around or fix? Thanks!

[Cidree]

Hi, and thanks for having a look at this.
I also tried to install and load other extensions, and the error also appears. For aws:

> dbExecute(conn, "INSTALL aws")
[1] 0
> dbExecute(conn, "LOAD aws")

 *** caught segfault ***
address (nil), cause 'unknown'

Traceback:
 1: rethrow_rapi_execute(res@stmt_lst$ref, res@arrow, res@connection@bigint ==     "integer64")
 2: duckdb_execute(res)
 3: duckdb_result(connection = conn, stmt_lst = stmt_lst, arrow = arrow)
 4: .local(conn, statement, ...)
 5: dbSendQuery(conn, statement, ...)
 6: dbSendQuery(conn, statement, ...)
 7: dbSendStatement(conn, statement, ...)
 8: dbSendStatement(conn, statement, ...)
 9: dbExecute(conn, "LOAD aws")
10: dbExecute(conn, "LOAD aws")

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace

[carlopi]

Just to be sure, which duckdb version AND duckdb self-reported platform?

Basically output of both:

PRAGMA version;
PRAGMA platform;

[carlopi]

If this is true for different extensions, this is most likely at the intersection of how duckdb builds extensions AND how duckdb-r is built.

On the duckdb-r side, I would recomend having a test such as the one introduced in https://github.com/duckdb/duckdb-odbc/pull/88/files.
This might fail on random hashes due to missing extension, and that might be fine, but should never segfault IF extension is there (that is, if the extensions were built for that hash). And on releases it can be made mandatory.

We are still cleaning up this duckdb side, but there should be now a mechanism to trigger builds when extensions are available, see https://github.com/duckdb/duckdb/blob/main/.github/workflows/NotifyExternalRepositories.yml that communicates to duckdb-odbc and duckdb-java that a given hash has extensions properly built.

---

This does not solve the problem, but would have allowed to catch this earlier / validate this to be working. Happy to help track this down and help duckdb side.

[Cidree]

Just to be sure, which duckdb version AND duckdb self-reported platform?

Basically output of both:

PRAGMA version;
PRAGMA platform;

HI @carlopi. Here are the outputs:

> dbGetQuery(conn, "PRAGMA version;")
  library_version  source_id
1          v1.2.1 8e52ec4395
> dbGetQuery(conn, "PRAGMA platform;")
          platform
1 linux_amd64_gcc4