What causes "fprintf is not supported" in windmill-labs/windmill?

Find and remove/redirect the fprintf call in the code compiled into the module (route diagnostics through a supported channel such as console_log).

windmill-labs/windmill · error

fprintf is not supported

Error message

fprintf is not supported

What it means

The `fprintf` libc stub panics because stdio output is not implemented in the WASM libc shim of the Java parser. The symbol is exported only so linkage succeeds; any call to formatted file-stream output at runtime is a hard failure, since there are no real file streams inside the sandbox.

Source

Thrown at backend/parsers/windmill-parser-java/src/wasm_libc.rs:150

/* --------------------------------- time.h --------------------------------- */

#[no_mangle]
pub unsafe extern "C" fn clock() -> u64 {
    panic!("clock is not supported");
}

/* --------------------------------- ctype.h -------------------------------- */

#[no_mangle]
pub unsafe extern "C" fn isprint(c: c_int) -> bool {
    c >= 32 && c <= 126
}

/* --------------------------------- stdio.h -------------------------------- */

#[no_mangle]
pub unsafe extern "C" fn fprintf(_file: *mut c_void, _format: *const c_void, _args: ...) -> c_int {
    panic!("fprintf is not supported");
}

#[no_mangle]
pub unsafe extern "C" fn fputs(_s: *const c_void, _file: *mut c_void) -> c_int {
    panic!("fputs is not supported");
}

#[no_mangle]
pub unsafe extern "C" fn fputc(_c: c_int, _file: *mut c_void) -> c_int {
    panic!("fputc is not supported");
}

#[no_mangle]
pub unsafe extern "C" fn fdopen(_fd: c_int, _mode: *const c_void) -> *mut c_void {
    panic!("fdopen is not supported");
}

#[no_mangle]

View on GitHub (pinned to e474e8803c)

Solutions

Find and remove/redirect the fprintf call in the code compiled into the module (route diagnostics through a supported channel such as console_log).
Upgrade windmill-parser-java to check whether newer builds handle or route stdio output.
Adjust parsing inputs to avoid the code path that emits C stdio output.
File an issue requesting a stdout/stderr forwarding implementation if the call is from a third-party component you cannot change.

Example fix

// before
fprintf(stderr, "parse failed: %s\n", msg);

// after: use the shim's console_log macro instead of stdio
console_log!("parse failed: {}", msg);

Defensive patterns

Strategy: try-catch

Validate before calling

// Validate input reaches no diagnostics-heavy native path: pre-scan for constructs known to emit C-level output.
if (!input || typeof input !== 'string') throw new Error('invalid parser input');

Try / catch

try {
  const result = parse(input);
} catch (e) {
  if (String(e).includes('fprintf is not supported')) {
    throw new Error('native component attempted stdio output; unsupported in parser WASM');
  }
  throw e;
}

Prevention

Ensure components compiled into the module use console_log! or host callbacks, never stdio.
Review native dependency code for fprintf/stderr usage before building the WASM artifact.
Add a CI smoke test parsing representative inputs to catch stdio paths early.
Upgrade the parser package when stdio shims land upstream.

When it happens

Trigger: Code compiled into the WASM module calls `fprintf(stream, fmt, ...)` (including fprintf(stderr, ...) for diagnostics or fprintf(stdout, ...) for logging).

Common situations: A bundled native/C component writing diagnostics or errors to stderr; transpiled code emitting formatted logs; parsing inputs whose handling path includes C-level printf-style reporting.

Related errors

AI-assisted analysis of windmill-labs/windmill@e474e8803c (2026-09-03). Data as JSON: /api/errors/c108aabe5717c44c. Report an issue: GitHub.