Bug 549247

Summary:

[abrt] crash in gstreamer-0.10.25.1-2.fc13

Product:

[Fedora] Fedora

Reporter:

Peng Huang <phuang>

Component:

glibc

Assignee:

Andreas Schwab <schwab>

Status:

CLOSED DUPLICATE

QA Contact:

Fedora Extras Quality Assurance <extras-qa>

Severity:

medium

Docs Contact:

Priority:

low

Version:

rawhide

CC:

ajax, jakub, lkundrak, lpoetter, schwab, wtogami

Target Milestone:

---

Target Release:

---

Hardware:

i686

OS:

Linux

Whiteboard:

abrt_hash:182906d9326f5586b1df56f299fd1a52be2224b3

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2009-12-21 12:18:19 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 Peng Huang 2009-12-21 03:29:48 UTC

abrt 1.0.2 detected a crash.

How to reproduce
-----
1. gst-launch audiotestsrc ! pulsesink 

Comment: execute gst-launch audiotestsrc ! pulsesink 
Attached file: backtrace
cmdline: /usr/bin/gst-launch-0.10 audiotestsrc ! pulsesink
component: gstreamer
executable: /usr/bin/gst-launch-0.10
kernel: 2.6.32.2-14.fc13.i686
package: gstreamer-0.10.25.1-2.fc13
rating: 3
reason: Process was terminated by signal 6 (Aborted)

Comment 1 Peng Huang 2009-12-21 03:29:51 UTC

Created attachment 379546 [details]
File: backtrace

Comment 2 Peng Huang 2009-12-21 03:39:56 UTC

Assertion 'pthread_mutex_unlock(&m->mutex) == 0' failed at pulsecore/mutex-posix.c:108, function pa_mutex_unlock(). Aborting.


I think the problem is in pulseaudio .

Comment 3 Peng Huang 2009-12-21 04:42:18 UTC

I put some printf in pulsecore/mutex-posix.c, and use ./thread-mainloop-test to reproduce this problem. It seems crash is caused by thread 0xb786e730 unlock the mutex locked by thread 0xb786db70.

[phuang@phuang-notebook src]$ ./thread-mainloop-test
Lock thread=0xb786e730 m=0x9942008
Lock thread=0xb786e730 m=0x9942008 OK
UnLock thread=0xb786e730 m=0x9942008
UnLock thread=0xb786e730 m=0x9942008 OK
Lock thread=0xb786e730 m=0x9942260
Lock thread=0xb786e730 m=0x9942260 OK
UnLock thread=0xb786e730 m=0x9942260
UnLock thread=0xb786e730 m=0x9942260 OK
Lock thread=0xb786db70 m=0x9942008
Lock thread=0xb786db70 m=0x9942008 OK
UnLock thread=0xb786db70 m=0x9942008
UnLock thread=0xb786db70 m=0x9942008 OK
Lock thread=0xb786e730 m=0x9942008
Lock thread=0xb786e730 m=0x9942008 OK
waiting 5s (signal)
Lock thread=0xb786db70 m=0x9942008
Lock thread=0xb786db70 m=0x9942008 OK
UnLock thread=0xb786db70 m=0x9942008
UnLock thread=0xb786db70 m=0x9942008 OK
Lock thread=0xb786db70 m=0x9942008
Lock thread=0xb786db70 m=0x9942008 OK
TIME EVENT START
wait completed
signal accepted
UnLock thread=0xb786e730 m=0x9942008
UnLock thread=0xb786e730 m=0x9942008 FAILED
Lock thread=0xb786e730 m=0x99422d8
Lock thread=0xb786e730 m=0x99422d8 OK
UnLock thread=0xb786e730 m=0x99422d8
UnLock thread=0xb786e730 m=0x99422d8 OK
Assertion 'i == 0' failed at pulsecore/mutex-posix.c:114, function pa_mutex_unlock(). Aborting.

Comment 4 Peng Huang 2009-12-21 07:24:28 UTC

I downgraded glibc from 2.11.90-4 to 2.11-4. This problem disappeared.
It seems the problem is in pthread library.

Comment 5 Lennart Poettering 2009-12-21 12:18:19 UTC


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