[BUG] alsa-lib leaves sound device open for child processes

[BUG] alsa-lib leaves sound device open for child processes

[Sebastian Kapfer]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]


The alsa-lib doesn't set the close-on-exec flag on its PCM device FD's.
The consequence is that processes spawned by alsa-lib clients inherit an
open file handle to the PCM device and thereby block it.

For example, mplayer can disable and re-launch the xscreensaver daemon.
In the alsa-enabled version of mplayer, the xscreensaver process
inherits a pcm handle, although xss can't make use of it. This
effectively forces me to restart xss manually after each mplayer
session.

Suggested fix:

--- src/pcm/pcm_hw.c.orig	2002-10-12 13:49:54.000000000 +0200
+++ src/pcm/pcm_hw.c	2003-02-03 23:07:14.000000000 +0100
@@ -867,6 +867,11 @@
 		ret = -errno;
 		goto _err;
 	}
+	if( fcntl( fd, F_SETFD, FD_CLOEXEC ) != 0 ) {
+		SYSERR("fcntl FD_CLOEXEC failed");
+		ret = -errno;
+		goto _err;
+	}
 	if (ioctl(fd, SNDRV_PCM_IOCTL_PVERSION, &ver) < 0) {
 		SYSERR("SNDRV_PCM_IOCTL_PVERSION failed");
 		ret = -errno;

-- 
Best Regards,   |   Hi! I'm a .signature virus. Copy me into
 Sebastian      |   your ~/.signature to help me spread!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [BUG] alsa-lib leaves sound device open for child processes

[Jaroslav Kysela]

On Mon, 3 Feb 2003, Sebastian Kapfer wrote:

> The alsa-lib doesn't set the close-on-exec flag on its PCM device FD's.
> The consequence is that processes spawned by alsa-lib clients inherit an
> open file handle to the PCM device and thereby block it.
> 
> For example, mplayer can disable and re-launch the xscreensaver daemon.
> In the alsa-enabled version of mplayer, the xscreensaver process
> inherits a pcm handle, although xss can't make use of it. This
> effectively forces me to restart xss manually after each mplayer
> session.
> 
> Suggested fix:
> 
> --- src/pcm/pcm_hw.c.orig	2002-10-12 13:49:54.000000000 +0200
> +++ src/pcm/pcm_hw.c	2003-02-03 23:07:14.000000000 +0100
> @@ -867,6 +867,11 @@
>  		ret = -errno;
>  		goto _err;
>  	}
> +	if( fcntl( fd, F_SETFD, FD_CLOEXEC ) != 0 ) {
> +		SYSERR("fcntl FD_CLOEXEC failed");
> +		ret = -errno;
> +		goto _err;
> +	}
>  	if (ioctl(fd, SNDRV_PCM_IOCTL_PVERSION, &ver) < 0) {
>  		SYSERR("SNDRV_PCM_IOCTL_PVERSION failed");
>  		ret = -errno;

Well, I and Abramo think that it's better to force application developers 
to clean allocated things before they'll call exec(). I believe that not 
only ALSA file descriptors are open after exec() in mplayer.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Takashi Iwai]

At Wed, 5 Feb 2003 12:20:23 +0100 (CET),
Jaroslav wrote:
> 
> Well, I and Abramo think that it's better to force application developers 
> to clean allocated things before they'll call exec().

the problem is not only the explicit exec() call.
without this bit, you'll pass the fds to other processes even by
popen() or system() or whatever.  that is, if your application calls
an external program in the middle, it can block the operation.

i don't see any critical drawback of setting FD_CLOEXEC as default.
the application which needs to pass the alsa-lib's fds _explicitly_
can reset the bit via fcntl() again before calling exec().


Takashi


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Jaroslav Kysela]

On Wed, 5 Feb 2003, Takashi Iwai wrote:

> At Wed, 5 Feb 2003 12:20:23 +0100 (CET),
> Jaroslav wrote:
> > 
> > Well, I and Abramo think that it's better to force application developers 
> > to clean allocated things before they'll call exec().
> 
> the problem is not only the explicit exec() call.
> without this bit, you'll pass the fds to other processes even by
> popen() or system() or whatever.  that is, if your application calls
> an external program in the middle, it can block the operation.
> 
> i don't see any critical drawback of setting FD_CLOEXEC as default.
> the application which needs to pass the alsa-lib's fds _explicitly_
> can reset the bit via fcntl() again before calling exec().

Do we have any precedence? sockets? fopen? etc.?

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Takashi Iwai]

At Wed, 5 Feb 2003 14:05:36 +0100 (CET),
Jaroslav wrote:
> 
> On Wed, 5 Feb 2003, Takashi Iwai wrote:
> 
> > At Wed, 5 Feb 2003 12:20:23 +0100 (CET),
> > Jaroslav wrote:
> > > 
> > > Well, I and Abramo think that it's better to force application developers 
> > > to clean allocated things before they'll call exec().
> > 
> > the problem is not only the explicit exec() call.
> > without this bit, you'll pass the fds to other processes even by
> > popen() or system() or whatever.  that is, if your application calls
> > an external program in the middle, it can block the operation.
> > 
> > i don't see any critical drawback of setting FD_CLOEXEC as default.
> > the application which needs to pass the alsa-lib's fds _explicitly_
> > can reset the bit via fcntl() again before calling exec().
> 
> Do we have any precedence? sockets? fopen? etc.?

it has nothing to do with what type of file descriptor is used, or
for what purpose.

i meant simply which behavior is _safer_.
sure, we can leave it as it was, and let users debug all.
IMO, however, the FD_CLOEXEC would lead to less bugs, if you think
which possibility is higher, whether to pass the fd intentionally,
or not,


Takashi


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Chris Rankin]

Speaking as a userspace developer, I expect file
descriptors to be inherited by child processes unless
I explicitly request otherwise. Yes, I usually make
sure that I *DO* request otherwise, but that's not the
point...

Cheers,
Chris

 --- Takashi Iwai <tiwai@suse.de> wrote: > At Wed, 5
Feb 2003 14:05:36 +0100 (CET),
> Jaroslav wrote:
> > 
> > On Wed, 5 Feb 2003, Takashi Iwai wrote:
> > 
> > > At Wed, 5 Feb 2003 12:20:23 +0100 (CET),
> > > Jaroslav wrote:
> > > > 
> > > > Well, I and Abramo think that it's better to
> force application developers 
> > > > to clean allocated things before they'll call
> exec().
> > > 
> > > the problem is not only the explicit exec()
> call.
> > > without this bit, you'll pass the fds to other
> processes even by
> > > popen() or system() or whatever.  that is, if
> your application calls
> > > an external program in the middle, it can block
> the operation.
> > > 
> > > i don't see any critical drawback of setting
> FD_CLOEXEC as default.
> > > the application which needs to pass the
> alsa-lib's fds _explicitly_
> > > can reset the bit via fcntl() again before
> calling exec().
> > 
> > Do we have any precedence? sockets? fopen? etc.?
> 
> it has nothing to do with what type of file
> descriptor is used, or
> for what purpose.
> 
> i meant simply which behavior is _safer_.
> sure, we can leave it as it was, and let users debug
> all.
> IMO, however, the FD_CLOEXEC would lead to less
> bugs, if you think
> which possibility is higher, whether to pass the fd
> intentionally,
> or not,
> 
> 
> Takashi
> 
> 
>
-------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =
> Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
>
https://lists.sourceforge.net/lists/listinfo/alsa-devel 

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Paul Davis]

>Speaking as a userspace developer, I expect file
>descriptors to be inherited by child processes unless
>I explicitly request otherwise. Yes, I usually make
>sure that I *DO* request otherwise, but that's not the
>point...

the question is not about inheritance by child processes. its about
close-on-exec behaviour. nobody is proposing any change to the
situation after a simple fork(2).

--p


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Chris Rankin]

Fair enough, but my point is that I'd expect the
close-on-exec flag NOT to be set unless I explicitly
set it myself. Same as with every other way of getting
a file descriptor.

Chris

 --- Paul Davis <paul@linuxaudiosystems.com> wrote: >
>Speaking as a userspace developer, I expect file
> >descriptors to be inherited by child processes
> unless
> >I explicitly request otherwise. Yes, I usually make
> >sure that I *DO* request otherwise, but that's not
> the
> >point...
> 
> the question is not about inheritance by child
> processes. its about
> close-on-exec behaviour. nobody is proposing any
> change to the
> situation after a simple fork(2).
> 
> --p 

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Chris Rankin]

 --- Sebastian Kapfer <sebastian_kapfer@web.de> wrote:
> May I ask what the child process is supposed to to
> with a raw ALSA file
> descriptor? AFAICT, developers are supposed to use
> the alsa-lib API, and
> not write to FD's. So the underlying file descriptor
> looks to me like a
> mere implementation detail which 99% of all users
> shouldn't need to care about.

I consider this situation analogous to the
relationship between file descriptors and FILE*
pointers. By your argument, libc should probably set
the FD_CLOEXEC flag here, too. But it doesn't.

Chris


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Sebastian Kapfer]

On Wed, 5 Feb 2003 22:39:22 +0000 (GMT)
Chris Rankin <rankincj@yahoo.com> wrote:

>  --- Sebastian Kapfer <sebastian_kapfer@web.de> wrote:
> > May I ask what the child process is supposed to to
> > with a raw ALSA file
> > descriptor? AFAICT, developers are supposed to use
> > the alsa-lib API, and
> > not write to FD's. So the underlying file descriptor
> > looks to me like a
> > mere implementation detail which 99% of all users
> > shouldn't need to care about.
> 
> I consider this situation analogous to the
> relationship between file descriptors and FILE*
> pointers. By your argument, libc should probably set
> the FD_CLOEXEC flag here, too. But it doesn't.

Can you explain _why_ this is the case? I can find a use for stdio FD's
in the new process either. The exec'd process can't even know which FD
corresponds to which file.

-- 
Best Regards,   |   Hi! I'm a .signature virus. Copy me into
 Sebastian      |   your ~/.signature to help me spread!


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Chris Rankin]

 --- Sebastian Kapfer <sebastian_kapfer@web.de> wrote:
> I can find a use for stdio FD's
> in the new process either. The exec'd process can't
> even know which FD corresponds to which file.

I'm assuming from the context of your message that you
meant "CAN'T find a use ... either". But the whole
point of a general purpose API (which is what libc is
and presumably is what ALSA aspires to have) is to
support *ALL* possible uses, whether you can imagine
them or not.

The API does not *need* to set the FD_CLOEXEC flag,
and so it should not. It is the height of arrogance to
assume that something has no use simply because you
can't imagine using it.

Chris


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Paul Davis]

>The API does not *need* to set the FD_CLOEXEC flag,
>and so it should not. It is the height of arrogance to
>assume that something has no use simply because you
>can't imagine using it.

there's a little detail you're forgetting. unless the hw supports
multi-open and the current number of subunits is below the limit of
the number of opens, then having the descriptor will cause all other
attempts to access the device to block (unless they explicitly request
non-blocking open, which means they then have to unset that flag for
normal application operation). this means that even if the parent has
closed the ALSA device, the child still (unwittingly) has it open. its
easy to imagine situations where the user will be completely puzzled
to find that another program cannot start up because they believe they
exited from the previous audio program. they don't understand that the
child process it started (say, a bug reporting system) still has the
device open.

this is quite different from how file descriptors that refer to disk
files, ttys and most other devices operate.

of course, its questionable whether the block-on-open approach is
correct, but so far discussions on this list have supported it.

--p


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Chris Rankin]

 --- Paul Davis <paul@linuxaudiosystems.com> wrote:
> there's a little detail you're forgetting. unless
> the hw supports multi-open and the current number of
> subunits is below the limit of the number of opens,
> then having the descriptor will cause all other
> attempts to access the device to block (unless they
> explicitly request non-blocking open, which means
> they then have to unset that flag for normal
> application operation

I hadn't forgotten. The situation to which you are
referring is called "a bug in the *application*".
Determining the destinies of resources, delivery of
signals etc when spawning child processes is the
application-programmer's responsibility.

And yes, I have tracked down bugs like this before.
And I *did* fix the application.

Chris


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Paul Davis]

>> there's a little detail you're forgetting. unless
>> the hw supports multi-open and the current number of
>> subunits is below the limit of the number of opens,
>> then having the descriptor will cause all other
>> attempts to access the device to block (unless they
>> explicitly request non-blocking open, which means
>> they then have to unset that flag for normal
>> application operation
>
>I hadn't forgotten. The situation to which you are
>referring is called "a bug in the *application*".

not clearly so. there are very few resources accessed via a file
descriptor that require this being done. 

the fact that an application has to understand this only adds to the
problems with the block-on-open design.

--p


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Takashi Iwai]

At Fri, 7 Feb 2003 13:58:48 +0000 (GMT),
Chris Rankin wrote:
> 
>  --- Paul Davis <paul@linuxaudiosystems.com> wrote:
> > there's a little detail you're forgetting. unless
> > the hw supports multi-open and the current number of
> > subunits is below the limit of the number of opens,
> > then having the descriptor will cause all other
> > attempts to access the device to block (unless they
> > explicitly request non-blocking open, which means
> > they then have to unset that flag for normal
> > application operation
> 
> I hadn't forgotten. The situation to which you are
> referring is called "a bug in the *application*".
> Determining the destinies of resources, delivery of
> signals etc when spawning child processes is the
> application-programmer's responsibility.
> 
> And yes, I have tracked down bugs like this before.
> And I *did* fix the application.

i don't think it's a bug of the alsa-lib, too.
it's a bug of mplayer.  mplayer should be fixed.  period.

but, the problem is that this kind of bugs can be rarely found (nor
appear).  on the contrary, if FD_CLOEXEC is set, you'll be able to
notice what's wrong.  that's what i mentioned "safer".


Takashi


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Chris Rankin]

 --- Takashi Iwai <tiwai@suse.de> wrote:
> i don't think it's a bug of the alsa-lib, too.
> it's a bug of mplayer.  mplayer should be fixed. 
> period.

Hooray! ;-)

> but, the problem is that this kind of bugs can be
> rarely found (nor appear).

I found lsof to be a most useful tool.

> on the contrary, if
> FD_CLOEXEC is set, you'll be able to notice what's

On the contrary, if FD_CLOEXEC is set then these kind
of bugs will be harder to spot because the library
will bury the bodies. But the application bugs will
still be there.

Chris


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Sebastian Kapfer]

On Thu, 6 Feb 2003 23:10:34 +0000 (GMT)
Chris Rankin <rankincj@yahoo.com> wrote:

>  --- Sebastian Kapfer <sebastian_kapfer@web.de> wrote:
> > I can find a use for stdio FD's
> > in the new process either. The exec'd process can't
> > even know which FD corresponds to which file.
> 
> I'm assuming from the context of your message that you
> meant "CAN'T find a use ... either".

You're right, sorry :)

> But the whole point of a general purpose API (which is what libc is
> and presumably is what ALSA aspires to have) is to
> support *ALL* possible uses, whether you can imagine
> them or not.

Setting FD_CLOEXEC automatically doesn't make the library less powerful.
You can still unset the flag yourself __if you really need the feature__
of inherited ALSA FD's. But wouldn't FD_CLOEXEC be the "reasonable
default" setting, which is correct for 99% of all applications?

> It is the height of arrogance to assume that something has no use
> simply because you can't imagine using it.

I'm not implying that this feature should be banned... in fact it can't
be banned. As long as the programmer can retrieve the underlying FD
number from the ALSA library, he can always (un)set FD_CLOEXEC. My point
is that the current default behaviour is (at least IMHO) unfortunate.

-- 
Best Regards,   |   Hi! I'm a .signature virus. Copy me into
 Sebastian      |   your ~/.signature to help me spread!


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Chris Rankin]

 --- Sebastian Kapfer <sebastian_kapfer@web.de> wrote:
>> Setting FD_CLOEXEC automatically doesn't make the
> library less powerful.
> You can still unset the flag yourself __if you
> really need the feature__
> of inherited ALSA FD's. But wouldn't FD_CLOEXEC be
> the "reasonable
> default" setting, which is correct for 99% of all
> applications?

Most of those "99% of all applications" don't spawn
child processes at all and so don't care one way or
another. (And did you know that 98.68% of all
statistics are invented ;-)?)

All of the remaining applications should be
considering what will happen to their resources on
exec(), and I see no reason why careless programmers
should have a few of their bugs swept under the rug
for them.

Chris


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Jaroslav Kysela]

On Fri, 7 Feb 2003, [iso-8859-1] Chris Rankin wrote:

>  --- Sebastian Kapfer <sebastian_kapfer@web.de> wrote:
> >> Setting FD_CLOEXEC automatically doesn't make the
> > library less powerful.
> > You can still unset the flag yourself __if you
> > really need the feature__
> > of inherited ALSA FD's. But wouldn't FD_CLOEXEC be
> > the "reasonable
> > default" setting, which is correct for 99% of all
> > applications?
> 
> Most of those "99% of all applications" don't spawn
> child processes at all and so don't care one way or
> another. (And did you know that 98.68% of all
> statistics are invented ;-)?)
> 
> All of the remaining applications should be
> considering what will happen to their resources on
> exec(), and I see no reason why careless programmers
> should have a few of their bugs swept under the rug
> for them.

I fully agree here.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Sebastian Kapfer]

On Sat, 8 Feb 2003 12:50:01 +0100 (CET)
Jaroslav Kysela <perex@suse.cz> wrote:

> > All of the remaining applications should be
> > considering what will happen to their resources on
> > exec(), and I see no reason why careless programmers
> > should have a few of their bugs swept under the rug
> > for them.
> 
> I fully agree here.

Well, obviously we're getting nowhere by continuing this thread. I'll
try to get a fix for this bug into mplayer CVS. Thanks anyway for your
opinions.

-- 
Best Regards,   |   Hi! I'm a .signature virus. Copy me into
 Sebastian      |   your ~/.signature to help me spread!


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Sebastian Kapfer]

On Sat, 8 Feb 2003 12:50:01 +0100 (CET)
Jaroslav Kysela <perex@suse.cz> wrote:

> > All of the remaining applications should be
> > considering what will happen to their resources on
> > exec(), and I see no reason why careless programmers
> > should have a few of their bugs swept under the rug
> > for them.
> 
> I fully agree here.

Can anyone comment on exactly how an alsa-lib client app should make
sure that exec'd processes don't inherit file handles? I can't find a
way to know the FD number which alsa-lib uses. snd_pcm_file_descriptor
is gone. What replaced it?

-- 
Best Regards,   |   Hi! I'm a .signature virus. Copy me into
 Sebastian      |   your ~/.signature to help me spread!


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Jaroslav Kysela]

On Sat, 8 Feb 2003, Sebastian Kapfer wrote:

> On Sat, 8 Feb 2003 12:50:01 +0100 (CET)
> Jaroslav Kysela <perex@suse.cz> wrote:
> 
> > > All of the remaining applications should be
> > > considering what will happen to their resources on
> > > exec(), and I see no reason why careless programmers
> > > should have a few of their bugs swept under the rug
> > > for them.
> > 
> > I fully agree here.
> 
> Can anyone comment on exactly how an alsa-lib client app should make
> sure that exec'd processes don't inherit file handles? I can't find a
> way to know the FD number which alsa-lib uses. snd_pcm_file_descriptor
> is gone. What replaced it?

The applications should use snd_pcm_close() function (or related one 
snd_*_close()). Note that more complex plugins can use more file 
descriptors so the application is not able to enumerate them.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Takashi Iwai]

At Sat, 8 Feb 2003 20:53:14 +0100 (CET),
Jaroslav wrote:
> 
> On Sat, 8 Feb 2003, Sebastian Kapfer wrote:
> 
> > On Sat, 8 Feb 2003 12:50:01 +0100 (CET)
> > Jaroslav Kysela <perex@suse.cz> wrote:
> > 
> > > > All of the remaining applications should be
> > > > considering what will happen to their resources on
> > > > exec(), and I see no reason why careless programmers
> > > > should have a few of their bugs swept under the rug
> > > > for them.
> > > 
> > > I fully agree here.
> > 
> > Can anyone comment on exactly how an alsa-lib client app should make
> > sure that exec'd processes don't inherit file handles? I can't find a
> > way to know the FD number which alsa-lib uses. snd_pcm_file_descriptor
> > is gone. What replaced it?
> 
> The applications should use snd_pcm_close() function (or related one 
> snd_*_close()). Note that more complex plugins can use more file 
> descriptors so the application is not able to enumerate them.

maybe it's just whipping a dead horse, but let me take this issue back
again.


there might be some situations in which you cannot call *_close()
functions.  for example, if you are sharing the handle with several
threads and want to start an external program from one of the
threads.

in such a case, the only correct method is to call fcntl(CLOEXEC).

and the problem is exactly what you wrote above.
it's difficult to get fds if the plugin becomes complex.


hence, i propose to create a new function as analogy to
snd_pcm_nonblock():

	int snd_pcm_set_close_at_exec(snd_pcm_t *pcm, int close);

applications need to call only this for every type of pcm.


comments please?


Takashi


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Jaroslav Kysela]

On Wed, 12 Feb 2003, Takashi Iwai wrote:

> At Sat, 8 Feb 2003 20:53:14 +0100 (CET),
> Jaroslav wrote:
> > 
> > On Sat, 8 Feb 2003, Sebastian Kapfer wrote:
> > 
> > > On Sat, 8 Feb 2003 12:50:01 +0100 (CET)
> > > Jaroslav Kysela <perex@suse.cz> wrote:
> > > 
> > > > > All of the remaining applications should be
> > > > > considering what will happen to their resources on
> > > > > exec(), and I see no reason why careless programmers
> > > > > should have a few of their bugs swept under the rug
> > > > > for them.
> > > > 
> > > > I fully agree here.
> > > 
> > > Can anyone comment on exactly how an alsa-lib client app should make
> > > sure that exec'd processes don't inherit file handles? I can't find a
> > > way to know the FD number which alsa-lib uses. snd_pcm_file_descriptor
> > > is gone. What replaced it?
> > 
> > The applications should use snd_pcm_close() function (or related one 
> > snd_*_close()). Note that more complex plugins can use more file 
> > descriptors so the application is not able to enumerate them.
> 
> maybe it's just whipping a dead horse, but let me take this issue back
> again.
> 
> 
> there might be some situations in which you cannot call *_close()
> functions.  for example, if you are sharing the handle with several
> threads and want to start an external program from one of the
> threads.
> 
> in such a case, the only correct method is to call fcntl(CLOEXEC).

Not really:

	int i = sysconf(_SC_OPEN_MAX);
	while (--i >= 3) {
		if (i != do_not_close_fd[])
			close(i);
	}
	exec(...);

But it's true that the application cannot filter ALSA's file descriptors 
in this case (to pass only specific interfaces to executed process). We 
have similar troubles with shm.

I'd propose to have a function 'snd_pcm_free_system_resources()' which 
will close all open file descriptors, detaches all shm handles and cleans 
all resources necessary before exec() or after fork():

int snd_pcm_free_system_resources(snd_pcm_t *pcm, int memory);

When memory != 0, it will free all memory resources.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [BUG] alsa-lib leaves sound device open for child processes

[Chris Rankin]

 --- Paul Davis <paul@linuxaudiosystems.com> wrote:
> not clearly so. there are very few resources
> accessed via a file
> descriptor that require this being done.

You think? Try unmounting a filesystem or unloading
the ide-cd kernel module if (say) xscreensaver has
been spawned by (say) xine, but xine has carelessly
leaked a file descriptor to a movie file, DVD device
etc. (But not with current versions of xine... ;-)

> the fact that an application has to understand this
> only adds to the
> problems with the block-on-open design.

Save me from application programmers who don't
understand what they're doing... ;-/!

Chris


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com