Harness primitive for testing expected crashes / uncaught exceptions

Open

#33 opened on Mar 8, 2026 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty: 5/5
Estimated time: Over a week
Newbie friendliness: 35/100

Issue type: Feature
Clarity: Mostly clear
Activity status: Stale
Tech stack: javascript, node.js
Domain: testing-qa

Research direction

Start by reading test_exception/testFinalizerException.js and test_fatal to compare their subprocess expectations. Design the implementor-provided harness around the proposed expectCrash shape, including stderr matching and exception- or signal-based termination. Done means both affected tests can use the helper and still verify their expected crash outcomes.

Written by the indexing model from the issue text.

Description

Problem

Several upstream Node.js tests verify behavior that causes the process to exit abnormally — uncaught exceptions from finalizers, fatal errors, etc. These tests use a subprocess pattern:

Spawn a child process that loads the addon and triggers the crash
Assert on the child's exit code and stderr output

The CTS currently has no equivalent harness primitive for this pattern.

Affected tests

test_exception/testFinalizerException.js (js-native-api) — finalizer throws during GC, expects process exit with "Error during Finalize" on stderr
test_fatal (node-api) — calls napi_fatal_error, expects process abort with specific message

Proposed solution

Add a harness helper that runs a code snippet in a subprocess and asserts on the outcome:

// Possible API shape:
await expectCrash({
  code: () => {
    const addon = loadAddon('test_exception');
    addon.createExternal();
    // trigger GC...
  },
  stderr: /Error during Finalize/,
  exitCode: (code) => code !== 0,
});

Each implementor would provide the subprocess execution mechanism (e.g., Node.js would use child_process.spawnSync).

Considerations

The helper needs to be implementor-provided since subprocess APIs are runtime-specific
The test code to run in the subprocess may need access to loadAddon and other CTS globals
Some crashes are signal-based (SIGABRT from napi_fatal_error) vs exception-based — the helper should handle both

Dominant language: C
Stars: 18
Forks: 12
PR merge metrics: No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

Read the whole issue, then the project's contributing guide.
Comment on the issue to say you are picking it up — it saves two people doing the same work.
Fork the repository and make your change on a branch.
Open a pull request that references the issue number.

Similar issues

internal.h中，漏掉了1个定义。 Open

Difficulty 1/5 Under an hour Newbie friendliness 95/100

microsoft/mimalloc#1414 · 1 reaction · Opened Sep 23, 2026
Inline assembly tests use 32-bit mnemonic suffixes on platform-`int` operands, so they fail to assemble under gcc/clang Open

Difficulty 2/5 1-3 hours Newbie friendliness 88/100

vlang/v#28870 · Opened Sep 23, 2026
Broadcast Documentation Open

Difficulty 1/5 Under an hour Newbie friendliness 90/100

kovidgoyal/kitty#10516 · Opened Sep 22, 2026
install_library_dev fails on a fresh prefix under the forced -j 8 macOS 27 Open

Difficulty 1/5 Under an hour Newbie friendliness 80/100

hashcat/hashcat#4907 · Opened Sep 22, 2026
kernel: shared_multi_heap: no internal locking, causes heap corruption with CONFIG_ESP_WIFI_HEAP_SPIRAM=y (ppTask vs wpa_supplicant race) Open

Difficulty 2/5 1-3 hours Newbie friendliness 78/100

zephyrproject-rtos/zephyr#120011 · Opened Sep 22, 2026

More C issues