On 11/08/2010 07:22 PM, Ranjan Maitra wrote:
> % strace -f -s 256 -p 1589
>
> The following keeps on scrolling:
>
> [pid 1589] ppoll([{fd=5, events=POLLIN}, {fd=21, events=POLLIN},
> {fd=9, events=0}, {fd=4, events=POLLIN}, {fd=20, events=POLLIN},
> {fd=26, events=POLLIN}, {fd=31, events=POLLIN|POLLERR|POLLHUP},
> {fd=31, events=0}, {fd=30, events=POLLIN}, {fd=29, events=POLLIN},
> {fd=22, events=POLLIN}, {fd=25, events=POLLIN}, {fd=16,
> events=POLLIN}, {fd=19, events=POLLIN}, {fd=15,
> events=POLLIN|POLLERR|POLLHUP}, {fd=15, events=0}, {fd=14,
> events=POLLIN}, {fd=13, events=POLLIN}, {fd=7, events=POLLIN}], 19,
> NULL, NULL, 8) = 1 ([{fd=9, revents=POLLHUP}])
>
> Killing pulseaudio (the process) seems to take care of it, and the
> temperature cools.
It's important to be exact here. That is a single line from the output
of strace. Is every single line of output identical? Do they all end
with "= 1 ([{fd=9, revents=POLLHUP}])"?
If so, that indicates that pulseaudio has lost connection to something
which was attached to file descriptor 9. It's not clear to me where
this bug is.
First, I would assume that any time that pulseaudio gets HUP on one of
its fds, it should close that fd and stop polling it.
However, pulseaudio is polling fd 9 with no "events" requested. In that
case, I believe that either glibc or Linux (the kernel) is at fault. No
events should be returned for that fd. The documentation isn't
perfectly clear on what actually happens when no events are specified,
so this may be a bug or it may not be.
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
