[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: [Fwd: Bug#9276: All KDE apps forget to reset signal mask on exec().]
From:       "Robert H. de Vries" <rhdv () rhdv ! cistron ! nl>
Date:       2000-08-29 16:30:07
[Download RAW message or body]

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" <rhdv@rhdv.cistron.nl>
>> 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" <rhdv@rhdv.cistron.nl>
>> Reply-To: "Robert H. de Vries" <rhdv@rhdv.cistron.nl>, 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

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic