ZhengweiZhu opened a new issue, #3118: URL: https://github.com/apache/brpc/issues/3118
**Describe the bug** When BRPC_BTHREAD_TRACER is enabled and the app is linked with cgo library (such as linked with etcd client library which is written in golang), the app will fail to start up as TaskTracer finds SIGURG signal handler is already registered (LINE 346). https://github.com/apache/brpc/blob/4eeb5e260af165291f95f30f0fa64f9ff67ba192/src/bthread/task_tracer.cpp#L334-L350 The root cause is the SIGURG signal is unfortunately used internally as sigPreempt for non-cooperative preemption by golang. <img width="2734" height="524" alt="Image" src="https://github.com/user-attachments/assets/a9e0d265-72bf-4cfc-b1c3-ee2f93ee5d00"; /> ``` file: https://go.dev/src/runtime/signal_unix.go 43 // sigPreempt is the signal used for non-cooperative preemption. 44 // 45 // There's no good way to choose this signal, but there are some 46 // heuristics: 47 // 48 // 1. It should be a signal that's passed-through by debuggers by 49 // default. On Linux, this is SIGALRM, SIGURG, SIGCHLD, SIGIO, 50 // SIGVTALRM, SIGPROF, and SIGWINCH, plus some glibc-internal signals. 51 // 52 // 2. It shouldn't be used internally by libc in mixed Go/C binaries 53 // because libc may assume it's the only thing that can handle these 54 // signals. For example SIGCANCEL or SIGSETXID. 55 // 56 // 3. It should be a signal that can happen spuriously without 57 // consequences. For example, SIGALRM is a bad choice because the 58 // signal handler can't tell if it was caused by the real process 59 // alarm or not (arguably this means the signal is broken, but I 60 // digress). SIGUSR1 and SIGUSR2 are also bad because those are often 61 // used in meaningful ways by applications. 62 // 63 // 4. We need to deal with platforms without real-time signals (like 64 // macOS), so those are out. 65 // 66 // We use SIGURG because it meets all of these criteria, is extremely 67 // unlikely to be used by an application for its "real" meaning (both 68 // because out-of-band data is basically unused and because SIGURG 69 // doesn't report which socket has the condition, making it pretty 70 // useless), and even if it is, the application has to be ready for 71 // spurious SIGURG. SIGIO wouldn't be a bad choice either, but is more 72 // likely to be used for real. ``` Any idea to fix? Maybe choose another signal number for stack trace as we can't change golang's implementation. @chenBright **To Reproduce** **Expected behavior** **Versions** OS: Compiler: brpc: protobuf: **Additional context/screenshots** -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
