libaoss.so hole?

libaoss.so hole?

[Joe Hsu]

    I've tested over and over. With my limited number of computers,
I've found this problem only happens in the computers with intel8x0
audio chips:

    I have an oss application which registers SIGCHLD signal handler
in the beginning and then opens /dev/dsp, and then forks a child
process. If the child process dies, the father process would receive a
SIGCHLD process and then free the allocated resources and then exit.

    Without pre-loading libaoss.so, everything goes well. With
libaoss.so pre-loaded, my applications exit in the computers with
intel8x0 audio chips because my application receives SIGCHLD signal
and thinks its process were dead. But in fact, it does not fork the
child process yet.

    After I turn on the ALSA_OSS_DEBUG environment variable,
libaoss.so first tried to open /dev/dsp0 but in vain. Then it tried a
alsa-default device successfully. I can see that every time libaoss.so
tries to opena pcm device with a new thread. And thta's the source of
the un-expected SIGCHLD signal.

    However, other computers with other audio chips go through the
same process (/dev/dsp0 failed and then alsa-default  device
successfully), but my application does not receive any un-expected
SIGCHLD signal before forking its own child process.

    I guess this is a hole. Any body thinks so ?


--
The sun is shinny but the ice is slippery.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642

Re: libaoss.so hole?

[Takashi Iwai]

At Fri, 17 Mar 2006 21:12:25 +0800,
Joe Hsu wrote:
> 
>     I've tested over and over. With my limited number of computers,
> I've found this problem only happens in the computers with intel8x0
> audio chips:
> 
>     I have an oss application which registers SIGCHLD signal handler
> in the beginning and then opens /dev/dsp, and then forks a child
> process. If the child process dies, the father process would receive a
> SIGCHLD process and then free the allocated resources and then exit.
> 
>     Without pre-loading libaoss.so, everything goes well. With
> libaoss.so pre-loaded, my applications exit in the computers with
> intel8x0 audio chips because my application receives SIGCHLD signal
> and thinks its process were dead. But in fact, it does not fork the
> child process yet.
> 
>     After I turn on the ALSA_OSS_DEBUG environment variable,
> libaoss.so first tried to open /dev/dsp0 but in vain. Then it tried a
> alsa-default device successfully. I can see that every time libaoss.so
> tries to opena pcm device with a new thread. And thta's the source of
> the un-expected SIGCHLD signal.

No, aoss has no single code calling any thread functions...


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: libaoss.so hole?

[Dirk Jagdmann]

>     I have an oss application which registers SIGCHLD signal handler
> in the beginning and then opens /dev/dsp, and then forks a child
> process. If the child process dies, the father process would receive a
> SIGCHLD process and then free the allocated resources and then exit.

I don't see any problem here if you did your code right.
1) fork() does return the pid of the child
2) in your SIGCHLD handler call wait(int*) which returns the pid of the 
terminated process.
3) If the pid from fork() and wait() match you can do your cleanup()
4) If they don't match, simply ignore the signal, as some other process 
(probably from the alsa lib) has died.

-- 
---> Dirk Jagdmann ^ doj / cubic
----> http://cubic.org/~doj
-----> http://llg.cubic.org


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: libaoss.so hole?

[Joe Hsu]

2006/3/18, Dirk Jagdmann <doj@cubic.org>:
> >     I have an oss application which registers SIGCHLD signal handler
> > in the beginning and then opens /dev/dsp, and then forks a child
> > process. If the child process dies, the father process would receive a
> > SIGCHLD process and then free the allocated resources and then exit.
>
> I don't see any problem here if you did your code right.
> 1) fork() does return the pid of the child
> 2) in your SIGCHLD handler call wait(int*) which returns the pid of the
> terminated process.
> 3) If the pid from fork() and wait() match you can do your cleanup()
> 4) If they don't match, simply ignore the signal, as some other process
> (probably from the alsa lib) has died.
>
> --
> ---> Dirk Jagdmann ^ doj / cubic
> ----> http://cubic.org/~doj
> -----> http://llg.cubic.org
>
    Of course. I know what you mean. But that is like a work around to
me. And I did a work around too. Since many oss developers didn't
think about the oss-to-alsa layer, this layer must be as transparent
as possible.
    Well, just my own opinion.
--
The sun is shinny but the ice is slippery.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642

Re: libaoss.so hole?

[Joe Hsu]

A
     And if it will not be that transparent in the future, please add
some comments in the document or it would be a bug caused by the
ignorance of oss application developers and by the in-complete
documnets. And that kind of bug is sometimes not easy to hunt down if
the application is big.

2006/3/18, Joe Hsu <nagual.hsu@gmail.com>:
>    Of course. I know what you mean. But that is like a work around to
> me. And I did a work around too. Since many oss developers didn't
> think about the oss-to-alsa layer, this layer must be as transparent
> as possible.
>    Well, just my own opinion.
> --
> The sun is shinny but the ice is slippery.
>


--
The sun is shinny but the ice is slippery.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642

Re: libaoss.so hole?

[nagual.hsu]

Takashi Iwai <tiwai <at> suse.de> writes:

> 
> >     After I turn on the ALSA_OSS_DEBUG environment variable,
> > libaoss.so first tried to open /dev/dsp0 but in vain. Then it tried a
> > alsa-default device successfully. I can see that every time libaoss.so
> > tries to opena pcm device with a new thread. And thta's the source of
> > the un-expected SIGCHLD signal.
> 
> No, aoss has no single code calling any thread functions...
> 
> Takashi
> 

    Maybe, it's the dmix and it is turned on as default since version
 1.0.10. I tried this with version 1.0.10.

    Check the following code run on computers with intel8x0 chips 
pre-loading libaoss.so:

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>
#include <signal.h>

void handler(int signum)
{
	fprintf(stderr, "signal...%d == SIGCHLD??\n", signum);
	return;
}

int main(int argc, char *argv[])
{
	int fd;
	signal(SIGCHLD, handler);
	signal(SIGTERM, handler);
	
	fd = open("/dev/dsp", O_WRONLY);
	fprintf(stderr, "success...\n");
	close(fd);
	return 0;
}






-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: libaoss.so hole?

[Takashi Iwai]

At Sat, 18 Mar 2006 07:27:02 +0800,
Joe Hsu wrote:
> 
> A
>      And if it will not be that transparent in the future, please add
> some comments in the document or it would be a bug caused by the
> ignorance of oss application developers and by the in-complete
> documnets. And that kind of bug is sometimes not easy to hunt down if
> the application is big.

Agreed.  Patches are always welcome :)


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642