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?). > 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. > 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(). What exactly were the problems you encountered with exec*()'s in KDE and threaded programs? Ciao, Michael.