Runtime error: null function or function signature mismatch

[mackwic]

What happens?

~~When using list_has_any() in a query repetitively, we get a RuntimeError: null function or function signature mismatch from the worker.~~

EDIT: the list_has_any() function call was embedded inside a sub-query. We've been able to reproduce the bug without the function call and only a SELECT.

After that, any query throws an OOM from the worker.

The first query never throws, and if queried slowly, it is ~~always~~ often OK.

I'm not clear on what to share to help, I'll add whatever I can. 😅

Some debugger screenshots

To Reproduce

One example of a failed request could be:

SELECT DISTINCT
  ON ("pointcles"."id") "pointcles".*
FROM
  "pointcles",
  (
    SELECT DISTINCT
      ON ("messages"."id") "messages".*
    FROM
      "messages"
    WHERE
      "messages"."id" IN (
        'msg-01HGGK43J10NN9CTNWX96CAB8C',
        'msg-7d65d57b-3e01-47f7-9877-2d0fc737434f',
        'msg-01HGGMV7M4VY15GS9NN6XPH5Z4',
        'msg-da27fdea-9344-4f17-8158-2c0ffdd5ae35'
      )
    ORDER BY
      "messages"."date" DESC NULLS LAST
    LIMIT
      20
    OFFSET
      0
  ) AS "messages"
WHERE
  pointcles.message_id = messages.id

See the following video reproducing the bug: https://synps.is/8qeVTzD (password is duckdb)

Browser/Environment:

Chrome 119

Device:

Macbook Pro M1 Pro (we reproduce on other devices)

DuckDB-Wasm Version:

1.28.0

DuckDB-Wasm Deployment:

https://app.synopsis-studio.com

Full Name:

Thomas WICKHAM

Affiliation:

Synopsis

[carlopi]

This is a very strange issue, but investigating it it's going to be not trivial.

The null dereference means the system is an unrelyable state, and basically all is lost (some things might work, but guarantees are off).

If you can ideally take a snapshot of the state of the database just before the crash I should try to concentrate on the first error ("Error while executing query" in the video, 0:17) and try to check whether database is in a sane state / something weird happened there. If you have instrumentations, you could also potentially try to replay all of this in an native duckdb potentially?

it's out of the support policy.

[mackwic]

Hi @carlopi thank you for your answer. I understand it is out of the support policy and hard to troubleshoot.

Just to be clear, when you say take a snapshot of the state, you mean a JS heap snapshot from the browser, right ?

If you have instrumentations, you could also potentially try to replay all of this in an native duckdb potentially?

Good idea. I suspect it's a browser issue, we may exceed the memory budget allowed to the worker, or it may be a bug somewhere in the duckdb::web::io namespace (I hope not).

[carlopi]

I meant of the database state, and then you would have to export it / save it SQL side.

[mackwic]

Understood. Should we close this issue or are you interested that I update this issue with our findings/resolutions/workarounds?

[FurcyPin]

I don't know if this is related, but I encountered the same error message while using duckdb-wasm on a table with index.

I made a minimal working example to showcase it: https://github.com/FurcyPin/duckdb-wasm-minimal-bug-example

Hope this helps.