Repository navigation
Windows fatal exceptions 0xC0000409 and 0xE06D7363 with libpg-query@16.2.0 via SafeQL #81
Description
Activity
- changed the title
[-]Windows fatal exceptions `0xC0000409` and `0xE06D7363` with SafeQL [/-][+]Windows fatal exceptions `0xC0000409` and `0xE06D7363` with `libpg-query@16.2.0` via SafeQL[/+]on Sep 8, 2024 Is there a way to reproduce this error in a Github Action? I don't use windows, only use it in CI/CD & Github Actions
I guess that the first issue should also appear on Windows CI on GitHub Actions, using the code provided by @ProchaLu in ts-safeql/safeql#243 and
database.tsin his reproduction repo:import postgres from 'postgres'; const sql = postgres(); export async function getUsers1() { // 💥 Missing comma after `users.id` causes libpg-query crash return await sql<Users[]>` SELECT users.id users.name FROM users `; }
Here's an example of running SafeQL in a GitHub Actions workflow for Windows (includes database setup, ESLint + SafeQL setup):
- GitHub Actions workflow: https://github.com/upleveled/preflight-test-project-next-js-passing/blob/153ed997b8624979d40f5d09a3d1a8a449f8e810/.github/workflows/ci.yml
- project repo: https://github.com/upleveled/preflight-test-project-next-js-passing
Although, the tricky part may be that on Windows, running
eslint .doesn't actually show a crash, it exits with code 127 and no more details:$ pnpm eslint . --max-warnings 0 (node:11440) ExperimentalWarning: Importing JSON modules is an experimental feature and might change at any time (Use `node --trace-warnings ...` to show where the warning was created) $ echo $? 127
In the VS Code ESLint extension, it shows this error code
0xC0000409/STATUS_STACK_BUFFER_OVERRUN(3221226505).But since this error will not be surfaced, it's possible that the GitHub Actions workflow for Windows would need to test the exit code to make sure that there is no crash.
@Newbie012 any clue why (as described above) running
eslint .will exit with code 127 (no error message), but the VS Code ESLint extension will report the real error code0xC0000409/STATUS_STACK_BUFFER_OVERRUN(3221226505)?Is this a bug in SafeQL that
libpg-querycrashes don't cause a SafeQL error message on the ESLint command line interface?@pyramation Yes, I was able to reproduce this in a GitHub Actions workflow for Windows. Running
eslint .exits with 127 and no details, but using a script to capture the real exit code shows 3221226505 (0xC0000409 STATUS_STACK_BUFFER_OVERRUN), confirming the crash.Running
pnpm eslint . --max-warnings 0in GitHub Actions results in this error:Error: Process completed with exit code 1.Running the script instead correctly captures the crash in this run:
Run echo "Running eslint.mjs..." Running eslint.mjs... ESLint exited with code: 3221226505 (0xC0000409) Error: Process completed with exit code 127.
Although, the tricky part may be that on Windows, running
eslint .doesn't actually show a crash, it exits with code 127 and no more details:I can confirm this by running ESLint via a script instead of calling
pnpm eslint .directly. The script runs ESLint using Node and captures the actual exit code instead of letting it be masked by the CLI wrapper. This surfaced the real error(0xC0000409), which suggests that SafeQL may not be handlinglibpg-querycrashes properly.Reacted by Karl HorkyReacted by Karl HorkyReacted by Karl HorkyWe just published all versions under WASM, so this should not be an issue :)
we support 13, 14, 15, 16, 17 now — try out the latest!
Reacted by Karl HorkyReacted by Karl HorkyReacted by Karl Horky
Windows users of
libpg-query@16.2.0via SafeQL have reported crashes:Error code
0xC0000409(STATUS_STACK_BUFFER_OVERRUN)Error code
0xC0000409(aka error code3221226505) (akaSTATUS_STACK_BUFFER_OVERRUN) occurred when linting SQL with errors in it (missing commas and parentheses):libpg-query@16.2.0: SafeQL crashes with error code 127, error code 3221226505 ts-safeql/safeql#243 (comment)Researching a bit led me to this:
How do you diagnose the exception code 0xc0000409 on Windows? | Stack Overflow
Error code
0xE06D7363Error code
0xE06D7363(aka error code3765269347) occurred when linting Prisma SQL code (code currently unknown):Research led to this:
C++ Loadlibrary() error 3765269347
I am wondering whether this is a general problem or deficiency with how
libpg-queryis built on Windows, or whether it's an issue with how SafeQL is interacting withlibpg-query?Last
libpg-queryWindows PRs:cc @pyramation @aquariuslt @Newbie012