tursodatabase / tursodatabase/libsql

Function libsql_malloc not found in Wasm module

Open
#153 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
17.2k
Forks
531
Avg merge
1h 12m
Merged PRs (30d)
1

Description

I have been trying to play with libsql and WASM functions as described in this article while using the latest 0.2.1 release and the artifact libsql-0.2.1-wasm-udf.tar.gz from the release download page. Whenever I try to execute a SQL select statement (as described in the article) that calls the encrypt() function I get the following error:

libsql> CREATE TABLE secrets(secret_id, secret);
libsql> INSERT INTO secrets VALUES (1, encrypt('libSQL is great', 's3cr3tp4ss'));
Runtime error: Function libsql_malloc not found in Wasm module
libsql> ^D

The same worked fine in 0.1.0 release I believe.

I have also tried the wasmedge version - libsql-0.2.1-wasm-udf-wasmedge.tar.gz - but this tar is missing some libraries it depends on: libfmt.so.9 and libspdlog.so.1.11 which I managed to grab from the archives. However I get this error:

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:.libs:./usr/lib ./libsql 
./libsql: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by .libs/libwasmedge.so.0)
./libsql: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by ./usr/lib/libspdlog.so.1.11)
./libsql: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by ./usr/lib/libfmt.so.9)

I guess it relies on a different version of libstdc++.so.6 compared to what I have on my Fedora 35 host.

BTW I did manage to get the same WASM function example to run on OSv using version 0.1.0 after adding some minimal file-sealing support to OSv (see https://github.com/cloudius-systems/osv/issues/1224). From my investigation, the wasmtime uses copy-on-write heap mappings which in turn relies on memfd_create which was missing from OSv. The copy-on-write heap mappings support can be turned off by compile option but maybe it makes sense to have it on for libsql. Having said all that I was eager to try to test the version of libsql with wasmedge.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the encrypt() failure with libsql-0.2.1-wasm-udf.tar.gz and compare it with the reported 0.1.0 behavior. Inspect the Wasm UDF path around the missing libsql_malloc export, then separately verify the WasmEdge archive's libfmt.so.9, libspdlog.so.1.11, and libstdc++ dependencies. Done when the documented release artifact runs the SQL example on a supported host.

Written by the indexing model from the issue text.

Assessment

Tech stack
sql, wasm
Domain
databases, infrastructure
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.