Comments (7)
There appear to be some mistakes in that commit, which don't entirely negate the fact this appears to be a kernel bug, but is making it work poorly. In particular
static void uv__sigaction_set(int signum, struct sigaction *sa) {
uv__sigactions.acts[signum] = *sa;
uv__sigactions.acts_presented_flags[signum] = 1;
}
looks like it is missing a conditional set:
static void uv__sigaction_set(int signum, struct sigaction *sa) {
if (uv__sigactions.acts_presented_flags[signum] == 0)
uv__sigactions.acts[signum] = *sa;
uv__sigactions.acts_presented_flags[signum] = 1;
}
since libuv may re-register its own sigaction to change from SA_RESETHAND => 0, and that would overwrite the correct info for the old sigaction, leading to libuv not correctly unregistering itself later
from libuv.
@slavamuravey fyi
I don't know if there's much we can do from the libuv side as it seems a macos issue
Yes... Guess there isn't much we can do here except maybe add a regression test to ensure we don't forget this tidbit of macos lore and merge another attempt in the future.
from libuv.
@bnoordhuis @vtjnash @santigimeno
Perhaps we should store previous sigaction data ourselves and not rely on the kernel?
Here is an example based on @santigimeno's example:
#define _GNU_SOURCE
#include <stdio.h>
#include <signal.h>
#include <stdlib.h>
void handler(int signum) {
printf("Signal handler called with signal %d\n", signum);
}
int main() {
struct sigaction sa, old_sa;
// Set a signal handler with SA_RESETHAND flag
sa.sa_handler = handler;
sigemptyset(&sa.sa_mask);
sa.sa_flags = SA_RESETHAND;
if (sigaction(SIGINT, &sa, NULL) == -1) {
perror("sigaction");
exit(1);
}
// Here we remember previous sigaction data
old_sa = sa;
// Set a second signal handler without SA_RESETHAND flag
sa.sa_flags = 0;
if (sigaction(SIGINT, &sa, NULL) == -1) {
perror("sigaction");
exit(1);
}
// Check whether the SA_RESETHAND flag is actually propagated
if (old_sa.sa_flags & SA_RESETHAND) {
printf("SA_RESETHAND was set in the old signal handler\n");
} else {
printf("SA_RESETHAND was not set in the old signal handler\n");
}
return 0;
}
from libuv.
Perhaps we should store previous sigaction data ourselves and not rely on the kernel?
I don't think that would work reliably. A third party (like another library) may have changed the signal handler before libuv gets to it.
Longstanding libuv philosophy is that features should either work always or never, not sometimes. Users can code defensively around the first two but not the last one.
from libuv.
@bnoordhuis Ok, then we should wait for changes in macos. After macos behavior will be the same as in linux for our case, we will be able to merge reverted PR again?
from libuv.
Yes, but that may be a while because with macos we generally support the latest-1 or latest-2 releases (e.g. macos 11 and up right now.)
from libuv.
Got it, thanks!
from libuv.
Related Issues (20)
- win: incorrect implementation of kill(0) / ESRCH
- Segment fault when run tty test HOT 4
- GPG keys of maintainers can't be retrieved from https://github.com/ nor https://libuv.org/
- GPG signatures of releases made with an expired key HOT 2
- potential perf regeressions due to io_uring `SQPOLL` HOT 3
- test: udp_multicast_join, udp_multicast_join6 failed under loongarch64 HOT 3
- Abstract socket namespace not work for 1.48 HOT 4
- several tests ha failed HOT 4
- unix udp close crash HOT 9
- linux,udp: don't use sendmmsg for single datagrams
- bug in libuv io_uring causes incorrect event reports to epoll and busy loop HOT 14
- `-Wstringop-overread` warning with libuv v1.48.0 (`unix/tcp.c:295`) with IBM AT17.0 (GCC 13.2.1) HOT 3
- Mixed allocator usage with `realpath` HOT 2
- Test failure with 1.48.0 on OSX x86 HOT 10
- Bug in TCP keep-alive with unix socket
- MSVC compiler bug broke env_vars test in ASAN (x64 windows 2022+asan) HOT 4
- Additional Libuv Metrics HOT 2
- test: flaky fs_event_close_with_pending_event HOT 2
- _alloca Requested memory may have edge problems causing exceptions HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from libuv.