On Tue, 29 Aug 2000, Michael Matz wrote: >Hi, > >On Mon, 28 Aug 2000, Stephan Kulow wrote: >> -------- Original Message -------- >> Subject: Bug#9276: All KDE apps forget to reset signal mask on exec(). >> Resent-Date: Mon, 28 Aug 2000 19:33:02 GMT >> Resent-From: "Robert H. de Vries" >> Resent-To: kde-bugs-dist@master.kde.org >> Resent-CC: owner@bugs.kde.org >> Date: Mon, 28 Aug 2000 21:18:20 +0200 >> From: "Robert H. de Vries" >> Reply-To: "Robert H. de Vries" , 9276@bugs.kde.org >> To: submit@bugs.kde.org >> >> Package: all KDE apps >> Version: 1.92 >> >> When executing an application which uses SIGRTMIN and the application > >SIGRTMIN is the constant for the first "free" signal number; free as in >"usable for realtime (or threading) handling". I'm not aware of many >(actually no) KDE applications which "use" this constant (what do you mean >by use?). It is not exactly a constant in glibc. It is a function returning an integer cleverly disguised as a constant. Whenever an application is linked against libpthread, the value of SIGRTMIN is changed from 32 to 33. Other (in this case my) applications may use SIGRTMIN. When this application is not linked against libpthread the SIGRTMIN value used is 32. If this application is started from any KDE application or if any KDE application is in the pstree, then this signal is blocked. > >> is not linked with -lpthreads, SIGRTMIN is blocked. SIGRTMIN is > >Yep, it's blocked, as normally it's not a signal at all. If the threading >mechanisms uses these signals they have to unblock them themself. This is >not the job of exec() calling applications. They haven't changed the >sigprocnmask, so they have not the job of changing them back. This should >be done in the exec'ed application, if it uses threads. My application doesn't use threads but inherits the mask from the parent application. > >> normally equal to 32. The Linux Pthreads library however uses this >> signal for its own. It increments SIGRTMIN and all blocks the signal. >> After forking and execing another program the signal mask is still >> blocking SIGRTMIN(32 variant). This is quite unexpected. Especially >> konsole and kdeinit should reset the sigprocmask before calling >> exec(2). > >To what should we "reset" the procmask to? We don't change it anywhere, >so, at the point of the exec() it has the same value as in main(). I propose to set it to the empty set. > >What exactly were the problems you encountered with exec*()'s in KDE and >threaded programs? The problem is that the application starts with some signals blocked. Most applications assume that their signal mask is completely empty. My proposal is to do something like this: if (pid = fork()) { /* parent does whatever to save the pid */ } else { /* child */ sigset_t mask; sigemptyset(&mask); sigprocmask(SIG_SETMASK, &mask, NULL); exec(the program you want to start); } The problem is that all KDE applications are apparently linked against libpthread. This library automatically increments SIGRTMIN and blocks the old SIGRTMIN. All child processes inherit this signal mask. The sample code above should solve it with no ill effects for the running application. IMHO libpthread should overload exec so that it resets the signal mask before doing the actual exec. But that is another matter. Robert -- Robert de Vries rhdv@rhdv.cistron.nl