Bug 555950

Summary: [abrt] crash in metacity-2.28.0-14.fc12
Product: [Fedora] Fedora Reporter: Bill Davidsen <davidsen>
Component: pulseaudioAssignee: Lennart Poettering <lpoetter>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: lkundrak, lpoetter, mschmidt, otaylor, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard: abrt_hash:08db2bb4dd3260971127b450007837e6813d61c0
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-01-18 14:55:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace none

Description Bill Davidsen 2010-01-16 00:00:20 UTC
abrt 1.0.3 detected a crash.

How to reproduce
-----
1. boot into GNOME
2. click any desktop but current
3.

Comment
-----
GNOME is really not usable. FC12 not usable.
The older kernel metacity crashes, the newer 2.6.32.9 the touchpad doesn't work
This is by far the worst release since FC2!

Attached file: backtrace
cmdline: metacity
component: metacity
executable: /usr/bin/metacity
kernel: 2.6.31.9-174.fc12.i686.PAE
package: metacity-2.28.0-14.fc12
rating: 4
reason: Process was terminated by signal 6 (Aborted)

Comment 1 Bill Davidsen 2010-01-16 00:00:23 UTC
Created attachment 384745 [details]
File: backtrace

Comment 2 Michal Schmidt 2010-01-18 12:33:46 UTC
This is an assertion failure at:
pa_assert_se(pthread_mutex_unlock(&m->mutex) == 0);
What version of glibc do you have?

Comment 3 Lennart Poettering 2010-01-18 14:55:37 UTC

*** This bug has been marked as a duplicate of bug 551055 ***

Comment 4 Bill Davidsen 2010-01-18 15:18:22 UTC
(In reply to comment #3)
> 
> *** This bug has been marked as a duplicate of bug 551055 ***    

I note that in the process of marking duplicates information is being lost. One of my several reports of this had the glibc information requested which was lost when the bug was marked as dup. Now this one is marked as needinfo, so it will get no attention.

Why isn't the bug which is in needinfo state marked as a dup of the one which has the information? Going by age only results in the original bug in needinfo and all other which have submitters ready to provide information being ignored.

I have two laptops and a desktop unusable and waiting migration back to FC11 because this bug is not being addressed, and our reports are just being hung on a dead report.

I assume this is just bad policy and not an effort to clear the bug queue.

Comment 5 Michal Schmidt 2010-01-18 15:43:02 UTC
(In reply to comment #4)
> I note that in the process of marking duplicates information is being lost. One
> of my several reports of this had the glibc information requested which was
> lost when the bug was marked as dup.

I assume you're talking about bug 551299. From what I see, it was closed as a duplicate _before_ you posted the glibc version to it.
Anyway, thanks for the requested information, I'll copy it to the open BZ.

Comment 6 Owen Taylor 2010-01-18 15:47:50 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > 
> > *** This bug has been marked as a duplicate of bug 551055 ***    
> 
> I note that in the process of marking duplicates information is being lost. One
> of my several reports of this had the glibc information requested which was
> lost when the bug was marked as dup. Now this one is marked as needinfo, so it
> will get no attention.

It's a legitimate concern in general, and generally the best thing to do in this case is to simply add a comment to the main bug report pointing out that the necessary information has been supplied in a particular duplicate and ask that needinfo be cleared.

In this case, this is definitely on Lennart's radar... it's not being neglected because the bug is in needinfo. I don't have a full understanding of this bug, but my understanding is that the problem lies somewhere between glibc and the kernel, and a fix is pending.