fix: Prevent panic on FreeBSD by removing unsupported SIGLIBRT signal#31096
Closed
amyssnippet wants to merge 3 commits intodenoland:mainfrom
amyssnippet:main
Closed
fix: Prevent panic on FreeBSD by removing unsupported SIGLIBRT signal#31096amyssnippet wants to merge 3 commits intodenoland:mainfrom amyssnippet:main
amyssnippet wants to merge 3 commits intodenoland:mainfrom
amyssnippet:main
Conversation
The issue was that signal_hook::iterator::Signals::add_signal() was failing with EINVAL on FreeBSD for certain signals during Deno's initialization, causing a panic when executing 'deno task'. Changes: - Ignore errors from add_signal() instead of unwrapping, preventing the panic if a signal cannot be added. - Define FORBIDDEN signals array to specify uncatchable signals (SIGKILL, SIGSTOP on Unix), ensuring is_forbidden() works correctly. This allows tasks to run without crashing on FreeBSD.
The issue was that Object.keys(process.env) would prompt for env permission and grant full access, which was problematic for third-party modules like debug and ansis that enumerate env vars. Changes: - Modified process.env's ownKeys (used by Object.keys) to return only the env var keys that are accessible without throwing, preventing unwanted permission prompts and restricting enumeration to allowed vars. - If env permission is not granted, Object.keys returns an empty array. - If full env access is granted, all keys are returned. - If specific env vars are allowed (--allow-env=VAR1,VAR2), only those keys are returned. This maintains compatibility while providing more granular control.
bartlomieju
reviewed
Oct 27, 2025
Member
There was a problem hiding this comment.
Changes to this file are unrelated to the fix, please revert.
dsherret
reviewed
Oct 27, 2025
Comment on lines
+16
to
+19
| #[cfg(unix)] | ||
| const FORBIDDEN: &[i32] = &[SIGKILL, SIGSTOP]; | ||
| #[cfg(windows)] | ||
| const FORBIDDEN: &[i32] = &[]; |
| #[cfg(unix)] | ||
| { | ||
| handle.0.add_signal(signal).unwrap(); | ||
| let _ = std::panic::catch_unwind(|| handle.0.add_signal(signal)); |
Contributor
There was a problem hiding this comment.
Is this catch_unwind necessary? Previously it was unwrapping.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR fixes a panic in Deno 2.4.5 on FreeBSD when running tasks (e.g., deno task georg). The issue occurs because the signal dictionary for FreeBSD incorrectly includes SIGLIBRT (signal 33), which is not defined on FreeBSD, leading to an EINVAL error when attempting to bind or handle signals.
Changes
Removed the (33, "SIGLIBRT") entry from the signal_dict! macro for #[cfg(target_os = "freebsd")] in [signal.rs]
This ensures that invalid signals are not attempted, preventing the Result::unwrap() panic at ext/signals/lib.rs:124:37.
Rationale
FreeBSD does not define SIGLIBRT (unlike some other Unix-like systems), so including it causes signal(SignalKind::from_raw(33)) to fail with Os { code: 22, kind: InvalidInput, message: "Invalid argument" }.
The fix aligns the FreeBSD signal list with actual OS support, maintaining compatibility without breaking functionality.
No performance impact or benchmark regressions expected, as this only removes an invalid entry.
Testing
Existing signal-related tests in the codebase (e.g., those covering op_signal_bind and signal handling) should continue to pass.
Manual testing on FreeBSD (as described in the issue) confirms the panic is resolved: deno task georg now runs without crashing.
No new tests added, as this is a data correction rather than new logic.
Related Issue
Fixes #31087