Skip to content

Node not saving coverage when process is terminated using SIGINT/SIGTERM #35212

Closed as not planned
Closed as not planned
Node not saving coverage when process is terminated using SIGINT/SIGTERM#35212
Labels
coverageIssues and PRs related to Node.js code coverage support.staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.

Description

@aalexgabi
aalexgabi
opened on Sep 15, 2020
  • Version: v14.10.1

What steps will reproduce the bug?

When running this code

function run() {
  if (1) {
    console.log(1);
  } else {
    console.log(2);
  }
}

run();

setTimeout(process.exit, 3000)

If I stop the process using SIGINT/SIGTERM before the timeout kicks in, coverage is not saved.

% NODE_V8_COVERAGE=/tmp/cov node /tmp/t.js
1
^C
% ls /tmp/cov
ls: cannot access '/tmp/cov': No such file or directory
%

What is the expected behavior?

Node coverage should work in the same way as other coverage tools, saving the coverage before terminating the process even if no SIGINT handler is set.

What do you see instead?

No coverage is saved.

Additional information

I know that adding a SIGINT/SIGTERM handler can be used as a workaround but this is not how most applications terminate and has no added value.

process.on('SIGINT', () => process.exit())
process.on('SIGTERM', () => process.exit())

Activity

  1. aalexgabi commented on Sep 15, 2020

    @aalexgabi
    aalexgabi
    on Sep 15, 2020
    Author

    For reference the issue reported by me in c8 repository: bcoe/c8#189

  2. aalexgabi
    changed the title [-]Node not saving coverage when process is terminated using SIGINT and no handler attached[/-] [+]Node not saving coverage when process is terminated using SIGINT/SIGTERM[/+] on Sep 15, 2020

  3. bnoordhuis commented on Sep 16, 2020

    @bnoordhuis
    bnoordhuis
    on Sep 16, 2020
    Member

    This is basically a duplicate of #27406 (which itself is a partial duplicate of #24937) so I'm going to close it as such. Thanks anyway for the report.

  4. bnoordhuis
    closed this as completedon Sep 16, 2020
  5. bnoordhuis
    added
    duplicateIssues and PRs that are duplicates of other issues or PRs.
    on Sep 16, 2020

  6. aalexgabi commented on Oct 4, 2020

    @aalexgabi
    aalexgabi
    on Oct 4, 2020
    Author

    @bnoordhuis I don't see how it's a duplicate at all. Here I'm talking about saving coverage data not cpu prof.

    If I attach an event listener to node process, coverage is dumped so there is no technical limitation to implement this behavior by default.

    A process can receive a signal multiple times and it can delay processing of a signal so there is plenty of time to write the files to the disk.

  7. joyeecheung commented on Oct 4, 2020

    @joyeecheung
    joyeecheung
    on Oct 4, 2020
    Member

    I guess this isn't really a duplicate - even after we fix the same issue with --cpu-prof we would still need to add extra code to handle coverage.

  8. joyeecheung
    reopened this on Oct 4, 2020
  9. joyeecheung
    added
    coverageIssues and PRs related to Node.js code coverage support.
    and removed
    duplicateIssues and PRs that are duplicates of other issues or PRs.
    on Oct 4, 2020

  10. mhdawson commented on Oct 8, 2020

    @mhdawson
    mhdawson
    on Oct 8, 2020
    Member

    @bcoe I know you are up to speed on the coverage front.

  11. bcoe commented on Oct 9, 2020

    @bcoe
    bcoe
    on Oct 9, 2020
    Contributor

    I believe this used to work ™️. When/if we figure out an approach for --cpu-prof, let's make sure we apply it to coverage too.

    Most importantly, let's make sure we add a regression test (could have sworn we had won, funny enough).

  12. joyeecheung commented on Oct 14, 2020

    @joyeecheung
    joyeecheung
    on Oct 14, 2020
    Member

    I took a look and I think we'd need to just create a different watchdog for the profilers. I'll be refactoring the entire profiler connection class for #33807 and I'll look into how to throw a watchdog into the class

  13. Dzenly commented on May 24, 2022

    @Dzenly
    Dzenly
    on May 24, 2022
    Contributor

    Hi! Could someone explain me (or give me a link) how these signal handlers affect v8 coverage behaviour?
    I've read https://v8.dev/blog/javascript-code-coverage, but did not find any signals mention.

    I.e. I would understand if there was recommendation to call v8.takeCoverage() from SIGTERM handler. But how does this work with only process.exit() in SIGTERM handler ?

  14. bnoordhuis commented on May 25, 2022

    @bnoordhuis
    bnoordhuis
    on May 25, 2022
    Member

    @Dzenly Something like process.on("SIGTERM", v8.stopCoverage) is allowed and should work. The caveats around signal handling are about handling them in C++, not JS. The one JS caveat is that process.on("SIGTERM", ...) won't work when the script is stuck in a busy loop.

  15. github-actions commented on Jun 27, 2026

    @github-actions
    github-actionsbot
    on Jun 27, 2026 – with GitHub Actions
    Contributor

    This issue has been marked as stale due to 210 days of inactivity.
    It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

  16. github-actions
    added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Jun 27, 2026

  17. github-actions commented on Jul 28, 2026

    @github-actions
    github-actionsbot
    on Jul 28, 2026 – with GitHub Actions
    Contributor

    This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
    If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.

  18. github-actions
    closed this as not plannedon Jul 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    coverageIssues and PRs related to Node.js code coverage support.staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions