Call stack size exceeded of wasm asyncify about wa-sqlite HOT 7 CLOSED

I tried here quolpr@7c0d9bd , but it didn't help. I suspect that this error is about JS VM stack error 🤔

from wa-sqlite.

This isn't a valid SQL(ite) statement, right? Not that it should produce a stack overflow, but I'm wondering if that is part of what triggers the issue.

Nope, it's valid. You can run it with not asyncify build, or you can also paste it to here https://sql.js.org/examples/GUI/ . For me, it even fails with 1...100 range (in the example I used 1...200 VALUES).

I used VALUES in one of my queries and now instead I use CTE like here https://til.simonwillison.net/sqlite/cte-values

from wa-sqlite.

I'm going to mark this WONTFIX. I don't see a compelling reason to use nested VALUES in this way causing the deep recursion here. And unfortunately, even if there is a good reason to do this, the "obvious" ways that Emscripten provides to tune the stack size don't seem to have any effect.

from wa-sqlite.

Can you try:

• Increasing the stack size in the Makefile, or
• Removing SQLITE_USE_ALLOCA from the Makefile

Then rebuild the WASM artifacts. You would need to follow the build instructions on the README. If you don't have the time or the background, I'll get around to it at some point.

from wa-sqlite.

I also made the debug build, and it seems just fail to parse the query:

The bad things about this are that for iOS Safari it seems the stack size is not so big and sometime prepare fails even for simple query like CREATE TABLE ....

And yeah, the weird thing is that the first run doesn't fail 🤔

from wa-sqlite.

Thanks for taking a look! I'm puzzled because I really thought one of those changes would fix it. I'll investigate myself when I can.

This isn't a valid SQL(ite) statement, right? Not that it should produce a stack overflow, but I'm wondering if that is part of what triggers the issue.

from wa-sqlite.

Thanks, I never knew you could use a bare VALUES clause as a statement. Is there a reason you need so many VALUES, as opposed to just:

VALUES (0), (1), (2), ...

The internal functions sqlite3Select() and multiSelect() are mutually recursive, as your debug build stack trace shows, and every VALUES starts a new subquery and introduces another level of recursion.

I think that explains why you're putting so much pressure on the stack, though it doesn't explain why it won't fail on the first try or with dev tools open.

from wa-sqlite.