Bug 666055

These execstack attempts occur continuously, 237 in about 20 mins.  Trapping and logging them is eating about 6% of the CPU.

Disabling the plugins one at a time, it seems to stop when I disable the facebook plugin.

Never mind, just did a bunch more execstacks with facebook disabled.  Changing back to generic pidgin - not sure whether purple or a plugin is responsible.

I'm guessing that these correspond to attempts to play sound events, do they
stop if you turn off sounds in preferences? This is probably a gstreamer or
gstreamer-plugin issue rather than Pidgin itself.

Your guess seems to be correct.  And there are some interesting hits when googling wavparse*:sink.  For instance: http://www.mail-archive.com/openafs-info@openafs.org/msg33362.html  Change component to gstreamer?  Or try to narrow it down more?

To be specific: when I check "mute sounds", the problem goes away (with sound).  When I uncheck mute, several dozen execstack attempts occur for every sound played.  The sounds *do* play.

I am able to reproduce the problem consistently on several systems with different sound hardware.  Clicking "Preview" in the pidgin sound preferences generates 61 execstack attempts (but the sound plays).  Clicking sound event preview in gnome-volume-control or ekiga does *not* cause execstack traps, so it is not clear that gstreamer is the problem.

This problem also occours when using rhythmbox or radiotray! So WTF is going on here??

Ok, rhythmbox has no problem with OGG or MP3.  But try to even look at a WAV, and you get the execstack traps.  So this is definitely a gstreamer issue, and only affects WAV files.  Is wavparse in the main gstreamer package?

The wavparse plugin is in gstreamer-plugins-good

Here is the selinux log for rhythmbox:

type=AVC msg=audit(1293636087.961:25754): avc:  denied  { execstack } for  pid=21509 comm="wavparse0:sink" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
type=SYSCALL msg=audit(1293636087.961:25754): arch=40000003 syscall=125 success=no exit=-13 a0=bfef1000 a1=1000 a2=1000007 a3=b764029c items=0 ppid=1 pid=21509 auid=902 uid=902 gid=902 euid=902 suid=902 fsuid=902 egid=902 sgid=902 fsgid=902 tty=(none) ses=1 comm="wavparse0:sink" exe="/usr/libexec/rhythmbox-metadata" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
[ repeat 61 times ]

Each attempt to inspect a WAV using gstreamer in any application results in exactly 61 execstack attempts.

If F12, it seems that there were crashes playing sounds.  For instance:

https://bugzilla.redhat.com/show_bug.cgi?id=593351

Now in F14, the problem is caught earlier by selinux (which is good).  Is there a simple way to get a stack trace at the point where selinux traps the execstack?

Bug #593351 is unrelated to this issue.

Bug #652297 is about a similar issue (execstack required when not expected), see Bug #652297 comment #5 for how to check for any (other) libraries on your system that might be requiring execstack (they may be being pulled in by gstreamer)

Also see https://bugzilla.rpmfusion.org/show_bug.cgi?id=1560 and https://bugzilla.rpmfusion.org/show_bug.cgi?id=1584 and if you have xvidcore from rpmfusion installed try running execstack -c /usr/lib/libxvidcore.so.4.2

I ran into another execstack issue in totem:

type=AVC msg=audit(1294182565.290:34871): avc:  denied  { execstack } for  pid=27600 comm="totem-audio-pre" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
type=SYSCALL msg=audit(1294182565.290:34871): arch=40000003 syscall=125 success=no exit=-13 a0=bfb55000 a1=1000 a2=1000007 a3=bfb53c5c items=0 ppid=1 pid=27600 auid=902 uid=902 gid=101 euid=902 suid=902 fsuid=902 egid=101 sgid=101 fsgid=101 tty=(none) ses=1 comm="totem-audio-pre" exe="/usr/bin/totem-audio-preview" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

This was from "hover play" of an mp3 in nautilus.

*** Bug 668281 has been marked as a duplicate of this bug. ***

gnome-sound-recorder is also afflicted:

type=AVC msg=audit(1295298423.941:23901): avc:  denied  { execstack } for  pid=20250 comm="gnome-sound-rec" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
type=SYSCALL msg=audit(1295298423.941:23901): arch=40000003 syscall=125 success=no exit=-13 a0=bfb73000 a1=1000 a2=1000007 a3=bfb7200c items=0 ppid=1 pid=20250 auid=902 uid=902 gid=902 euid=902 suid=902 fsuid=902 egid=902 sgid=902 fsgid=902 tty=(none) ses=2 comm="gnome-sound-rec" exe="/usr/bin/gnome-sound-recorder" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

Is it recommended to allow execstack access for needed gstreamer apps?  What is the best way to do that?

This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping