v0.5.18 codegen regression: Fastify + MySQL binaries segfault at startup

[proggeramlug]

Summary

Binaries compiled with perry 0.5.18 that use http-server (Fastify) + database-mysql features segfault immediately on startup. The same source code compiles and runs correctly with perry 0.4.51.

Reproduction

Any TypeScript file that imports Fastify and mysql2, compiled on Linux x86_64:

perry compile main.ts -o my-server   # with perry 0.5.18
./my-server                           # SIGSEGV immediately

The same file compiled with perry 0.4.51 runs fine.

Even a minimal Fastify-only app (no MySQL) fails to start when compiled with 0.5.18 — the binary exits silently with no output.

Environment

• Platform: Linux x86_64 (Ubuntu, Cherry Servers)
• Perry versions tested:
  • 0.4.51 — works
  • 0.5.18 (both release binary and source-built) — segfaults
• Runtime: Tested with both prebuilt libs and source-built (cargo build --release -p perry-runtime -p perry-stdlib). Same result.
• Features used: crypto, database-mysql, http-server, http-client, websocket

Additional detail

When the auto-optimize feature rebuilds the runtime with the exact feature set, compilation succeeds with no linker warnings, but the resulting binary still segfaults (signal 11 / SIGSEGV) on the first instruction.

Separate issue: gc() symbol mismatch

The runtime exports the manual GC trigger as js_gc_collect (gc.rs:326), and the codegen declares it as js_gc_collect (runtime_decls.rs:1450), but calling gc() from TypeScript emits a reference to the bare symbol gc — which doesn't exist in the linked runtime. This results in:

undefined reference to `gc'

The workaround is adding a #[no_mangle] pub extern "C" fn gc() alias in gc.rs, but the codegen should either emit js_gc_collect for gc() calls, or the runtime should export the bare gc symbol.

This matters for long-running servers: without periodic gc(), the runtime's memory tracking accumulates and RSS grows unbounded, eventually causing memory corruption and crashes.

[proggeramlug]

Update: v0.5.19 fixes the segfault but introduces new issues

Pulled latest source, built perry 0.5.19 from source. The Fastify binary no longer segfaults — it starts up and listens. However two new issues:

1. MySQL createPool returns invalid handle

DB init error: Invalid connection handle

The pool is created via:

function createDbPool(): Pool {
  return mysql.createPool({
    host: process.env.PERRY_DB_HOST || 'localhost',
    port: parseInt(process.env.PERRY_DB_PORT || '3306', 10),
    user: process.env.PERRY_DB_USER || 'perry',
    password: process.env.PERRY_DB_PASSWORD || '',
    database: process.env.PERRY_DB_NAME || 'perry_hub',
  });
}
const db = createDbPool();

This works correctly when compiled with perry 0.4.51 ("DB ready, loaded 26 licenses"). With 0.5.19 the pool handle appears invalid and all subsequent db.execute() calls fail.

2. Auth string comparison may be broken

The admin endpoints return FORBIDDEN even with the correct Bearer token. The auth check uses:

if (!auth.endsWith(ADMIN_SECRET) || !auth.startsWith('Bearer ')) {

This works with 0.4.51 but rejects valid tokens with 0.5.19. Possibly related to string comparison changes in the new codegen.

3. WebSocket server not starting

No "Perry Hub WebSocket server listening on port 3457" log line appears, suggesting the WebSocketServer constructor or .on('listening', ...) is broken.

Currently running the 0.4.51-compiled binary (without gc()) as it's the only version that fully works.

[proggeramlug]

Update: v0.5.20 fixes WebSocket + segfault, but config objects passed to native FFI are empty

Pulled and built v0.5.20. Good progress:

• WebSocket server now starts (v0.5.18 codegen regression: Fastify + MySQL binaries segfault at startup #28 item 3 ✓)
• No segfault (v0.5.18 codegen regression: Fastify + MySQL binaries segfault at startup #28 item 1 ✓)
• Admin auth works (v0.5.18 codegen regression: Fastify + MySQL binaries segfault at startup #28 item 2 ✓)

But the MySQL issue remains. Root cause now isolated with debug logging added to js_mysql2_create_pool:

TypeScript source:

const db = mysql.createPool({
  host: 'localhost',
  port: 3306,
  user: 'perry',
  password: 'perry',
  database: 'perry_hub',
});

Runtime output:

[DEBUG] parsed config: host=localhost port=3306 user=root database=None
[DEBUG] connect error: Access denied for user 'root'@'localhost' ... for url: mysql://root:@localhost:3306?ssl-mode=disabled

parse_mysql_config walks the object via js_object_get_field_by_name(obj_ptr, key) for each field. In v0.5.20 none of the fields are found — every value falls back to MySqlConfig::default() (root/empty/localhost/None).

Same source compiled with v0.4.51 works correctly (reads user: "perry", database: Some("perry_hub"), etc.), so the object literal IS being constructed with the right fields — it's just that the field lookup from the native FFI side (by-name) returns nothing.

Reproducer (anything similar will show it): mysql.createPool({host, port, user, password, database}) — all five fields come back as defaults.

Feels like object-literal keys or the key-lookup path in the runtime changed shape between 0.5.19 and 0.5.20, and the FFI helpers that read keys by name (js_object_get_field_by_name) haven't been updated. Might also affect other stdlib modules that parse config objects this way (pg, mongodb, redis, etc.).

[proggeramlug]

Root cause: ABI mismatch for JSValue args in native FFI calls

Not a missing-field problem — the object pointer never makes it into the callee. System V AMD64 ABI mismatch between LLVM call site and Rust function signature.

Evidence

Added eprintln! at the top of js_mysql2_create_pool:

[PERRY DEBUG] parse_mysql_config called, config bits=0x0000000000000000
  is_pointer=false is_null=false is_undef=false is_bool=false is_number=true

Checked the emitted LLVM IR at the call site (PERRY_SAVE_LL):

%r3 = call i64 @js_object_alloc(i32 0, i32 5)
; ... js_object_set_field_by_name for each key ...
%r23 = or i64 %r3, 9222527611924643840      ; 0x7FFD_0000_0000_0000 = POINTER_TAG
%r24 = bitcast i64 %r23 to double
%r25 = call i64 @js_mysql2_create_pool(double %r24)

The IR is correct: object handle is OR'd with POINTER_TAG and bitcast to double.

The mismatch

• LLVM declares declare i64 @js_mysql2_create_pool(double) — arg passed in XMM0 (float register) on SysV AMD64.
• Rust has pub extern "C" fn js_mysql2_create_pool(config: JSValue) where JSValue is #[repr(transparent)] struct JSValue { bits: u64 } — treated as an integer, expected in RDI (integer register).

Caller puts bits in XMM0, callee reads RDI → gets 0. That's why every field parses as default.

Confirmed fix

Changed the Rust signature to take f64 and reinterpret inside:

pub unsafe extern "C" fn js_mysql2_create_pool(config_f: f64) -> Handle {
    let config = JSValue::from_bits(config_f.to_bits());
    ...
}

Result:

[ABI-TEST] f64-variant got bits=0x7ffd7ac99ddff018   # proper NaN-boxed pointer
Query result: [{"test":1}]                            # works

Scope

This affects every stdlib FFI function that takes a JSValue parameter (or anything whose repr is u64) and whose NativeModSig lists the arg as NA_F64. Quick grep of NATIVE_MODULE_TABLE in crates/perry-codegen/src/lower_call.rs shows this pattern is used for fastify register/reply/ctx, mysql2, pg, mongodb, and others.

Proper fix directions

Either:

1. Runtime side — change every extern "C" fn foo(x: JSValue) used as NA_F64 target to extern "C" fn foo(x: f64) and reinterpret internally. Works but brittle.
2. Codegen side — when a NativeArgKind::F64 signature is really carrying JSValue bits, declare the call with i64 instead of double, and pass the %r23 = or i64 ... value directly (no bitcast-to-double). This matches the Rust JSValue (transparent u64) ABI. Cleaner.

(Worked in 0.4.51, presumably because either the JSValue repr or the codegen's arg-type choice was different at the time.)