Description of problem:
When an alert is triggered and I want to have the details to assess which corrective action to take, I found some insconsistencies :
-sometimes the trapped program is mentioned as "None", which is not really useful,
-sometime in the same report, the faulty program is correcly named,
-sometimes the indicated faulty program is NOT the one that just got trapped, but the previous programme that raised an alert (possibly several days before, and is generally completely different of the current one).


Version-Release number of selected component (if applicable):
Release number unknown (no "About" window available in "SELinux Alert Browser" main window), but it is the current release for F14.
(3.0.28-1.fc14 as reported bu PackageKit).

How reproducible:
Systematic (provided of course that alerts could be raised as needed).

Steps to Reproduce:
0. Initial state: no alerts.

1. Try to start a program that triggers bug #652297 (or 680540 as well) : audacity, GIMP, Gnash, ... 
As mentioned in the Comment97 of #652297 (https://bugzilla.redhat.com/show_bug.cgi?id=652297#c97), the source of the alert is probably not the executable itself, but a common shared library.
Say for instance you try to start "audacity".

2. The execstack alert should raise. The source process is correctly identifed in the "SELinux Alert Browser" main window ("/usr/bin/audacity" in this case), and is shown as "alert 1 of 1".

3. Click on the "Details" button to get more information.
Here below is the beginning of the output (my locale is French, hence the mixture of English and French in the report below, but it should be understandable anyway):

"SELinux is preventing /usr/bin/audacity from using the execstack access on a process.

*****  Plugin allow_execstack (53.1 confiance) suggéré************************

Siyou believe that 
None
should not require execstack
Alorsyou should clear the execstack flag and see if /usr/bin/audacity works correctly.
Report this as a bug on None.
You can clear the exestack flag by executing:
Faire
execstack -c None
[etc...]
"

Above the faulty program is named "None" unless the path is correct. Additionally, I'm not sure that an "execstack -c None" command would produce any useful effect... ;-)

I should mention that in the 3rd option (plugin catchall), the program is named correctly:

"*****  Plugin catchall (5.76 confiance) suggéré*******************************

Siyou believe that audacity should be allowed execstack access on processes labeled unconfined_t by default.
Alorsyou should report this as a bug.
You can generate a local policy module to allow this access. [etc...]"

Here above the program is correctly named ("audacity").

But that's not all. Just close the Details window and the Alert Browser, taking no corrective action at the moment. Do not delete the alert, mimicing the fact that you have not made up your mind about what to do right now.

4. Wait some time if you want, then try to start a different program that triggers the same alert (say this time you try to start gnash).

5. In the Alert Browser window :
- the current alert is still "1 of 1", despite this is the 2nd alert,
- the indicated faulty program is still "/usr/bin/audacity", and NOT /usr/bin/gtk-gnash" as it should be.
The "Details" button yields the same report as before (with "None", "audacity" or "/usr/bin/audacity"), despite that the raw audit reports are correctly reporting the faulty program to be "gtk-gnash".
Extract of the reported details for plugin catchall:

"*****  Plugin catchall (5.76 confiance) suggéré*******************************

Siyou believe that audacity should be allowed execstack access on processes labeled unconfined_t by default.
[... same as above ...]
Additional Information:
Contexte source               unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
                              023
Contexte cible                unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
                              023
Objets du contexte            Unknown [ process ]
Source                        audacity
Chemin de la source           /usr/bin/audacity
Port                          <Inconnu>
Hôte                          (removed)
Paquetages RPM source         gnash-0.8.8-4.fc14

[the "source" is mentioned as "audacity", its path is "/usr/bin/audacity", but the source RPM is "gnash-0.8.8-4.fc14"... Strange, isn't it ?
(cont'd below)]

Paquetages RPM cible          
RPM de la statégie            selinux-policy-3.9.7-31.fc14
Selinux activé                True
Type de stratégie             targeted
Mode strict                   Enforcing
Nom de l'hôte                 (removed)
Plateforme                    Linux (removed) 2.6.35.11-83.fc14.i686 #1 SMP Mon Feb
                              7 07:04:18 UTC 2011 i686 i686
Compteur d'alertes            2

[alerts count is correct (this is the 2nd alert, despite the main window sticks to "alert 1 of 1").
(cont'd below)]

[...]
Messages d'audit bruts 
type=AVC msg=audit(1298728447.667:24754): avc:  denied  { execstack } for  pid=11492 comm="gtk-gnash" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
{etc...]"

["gtk-gnash" is correctly reported in the raw audit report above].

  
Actual results:
See above.

Expected results:
See above.

Additional info:
I understand that the latter issue (during the second trapping) could involve "setroubleshoot-plugins" rather than "setroubleshoot" itself, but the result errors are mixed.