Bug 470000

Crash secondly:

--------
System: Linux 2.6.27.4-68.fc10.i686 #1 SMP Thu Oct 30 00:49:42 EDT 2008 i686
X Vendor: The X.Org Foundation
X Vendor Release: 10502000
Selinux: No
Accessibility: Disabled
GTK+ Theme: Nodoka
Icon Theme: Fedora

Memory status: size: 3026124800 vsize: 3026124800 resident: 54812672 share: 24596480 rss: 54812672 rss_rlim: 18446744073709551615
CPU usage: start_time: 1225867782 rtime: 2245 utime: 1917 stime: 328 cutime:4 cstime: 17 timeout: 0 it_real_value: 0 frequency: 100

Backtrace was generated from '/usr/bin/pidgin'

0x00110416 in __kernel_vsyscall ()
#0  0x00110416 in __kernel_vsyscall ()
#1  0x005ce777 in poll () from /lib/libc.so.6
#2  0x00727742 in ?? () from /lib/libglib-2.0.so.0
#3  0x00727dd2 in g_main_loop_run () from /lib/libglib-2.0.so.0
#4  0x058cc489 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#5  0x080c6b86 in main (argc=1, argv=0xbf92a9d4) at gtkmain.c:888
The program is running.  Quit anyway (and detach it)? (y or n) [answered Y; input not from terminal]


----------- .xsession-errors ---------------------
E: shm.c: mmap() failed: Cannot allocate memory
E: shm.c: mmap() failed: Cannot allocate memory
E: shm.c: mmap() failed: Cannot allocate memory
E: shm.c: mmap() failed: Cannot allocate memory
E: shm.c: mmap() failed: Cannot allocate memory
E: shm.c: mmap() failed: Cannot allocate memory
E: shm.c: mmap() failed: Cannot allocate memory
E: shm.c: mmap() failed: Cannot allocate memory
E: shm.c: mmap() failed: Cannot allocate memory
E: shm.c: mmap() failed: Cannot allocate memory
E: shm.c: mmap() failed: Cannot allocate memory
E: shm.c: mmap() failed: Cannot allocate memory
E: shm.c: mmap() failed: Cannot allocate memory
E: shm.c: mmap() failed: Cannot allocate memory
pidgin: pulse.c:203: pulse_new: Assertion `p->context' failed.
--------------------------------------------------

It has crashed the third time, the same backtrace output with the second time.

The backtrace doesn't show anything useful at all. Please install relevant debuginfo with "debuginfo-install pidgin".

> pidgin: pulse.c:203: pulse_new: Assertion `p->context' failed.

This looks like it may be crashing in pulse when trying to play a sound - if you disable sounds does it stop crashing?

Also what protocols and plugins do you use?

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This almost for sure is either a a pulseaudio or gstreamer problem. Pidgin seems to leak two threads per played sound, until the point no stack is left for new threads. Will attach a backtrace that shows pidgin having 72 threads after a few hours of use.

FWIW, I'm using ICQ, MSN, IRC protocols and only stock pidgin plugins, but I think the issue is clear. I don't know though whether the actual issue is in pidgin, gstreamer or pulseaudio, although I suspect the latter.

Created attachment 325549 [details]
GDB output

GDB output showing pidgin having an insane number of threads

FWIW, package versions:
pidgin-2.5.2-1.fc10.i386
gstreamer-0.10.21-2.fc10.i386
pulseaudio-0.9.13-6.fc10.i386

Danny, could you please test this:
1) rpm -qa 'pulseaudio* alsa-plugins-pulseaudio'
   Note everything here so you can reinstall it later.
2) Un-install all of those RPMS.
3) Reboot.
4) Log into your desktop.  It should be outputting all sound directly to the ALSA device.
5) Redo your pidgin tests.

Does sound work?  Does it still leak threads?

Danny, here is an alternate test.  Have it use aplay command instead of gstreamer for sound output.  Does the problem go away?

Please try both of these tests and report back.

http://developer.pidgin.im/ticket/7519
This bug is likely the same mentioned here.  Upstream pidgin considers this to be a gstreamer problem and not their fault.

Danny was this an issue in F9 as well?

(In reply to comment #9)
> Danny, here is an alternate test.  Have it use aplay command instead of
> gstreamer for sound output.  Does the problem go away?
> 
> Please try both of these tests and report back.

I didn't try those yet, but I wrote an exceedingly simple test program which basically is some copy'n'paste from pidgin. It leaks threads, too, so at least we have a very simple test case. It plays a wav file each 5 seconds, and per play 5 threads are started and only one is closed.
Will attach the test tool to this bug.

> http://developer.pidgin.im/ticket/7519
> This bug is likely the same mentioned here.  Upstream pidgin considers this to
> be a gstreamer problem and not their fault.

Looks like they're right.

Created attachment 325586 [details]
Tets tool

Compile with 
gcc -o test `pkg-config --cflags --libs gstreamer-0.10 glib-2.0` test.c

Doesn't leak any threads anymore after adding a proper glib main loop integration...can anyone confirm?

(In reply to comment #10)
> Danny was this an issue in F9 as well?

Not that I'm aware of. At least pidgin did never crash for me.

> Doesn't leak any threads anymore after adding a proper glib main loop
> integration...can anyone confirm?

What exactly does this mean to your test.c?

(In reply to comment #12)
> Created an attachment (id=325586) [details]
> Tets tool
> 
> Compile with 
> gcc -o test `pkg-config --cflags --libs gstreamer-0.10 glib-2.0` test.c
> 
> Doesn't leak any threads anymore after adding a proper glib main loop
> integration...can anyone confirm?

Bah, I spoke too soon. I just noticed that gstreamer was configured to use ALSA for me, so it's the expected behaviour to not leak threads (per play attempt, 5 threads are started and ended). Reconfiguring gstreamer to use pulseaudio directly results in thread leak (6 threads are started, 5 are shut down).

(In reply to comment #14)
> > Doesn't leak any threads anymore after adding a proper glib main loop
> > integration...can anyone confirm?
> 
> What exactly does this mean to your test.c?

My first version of test.c didn't have glib main loop integration ;-)
Sorry for the confusion.

#gstreamer says that this is likely a bug in libgstpulse.  It came from an independent gstreamer-plugins-pulse in F-9, and it was later merged into gstreamer-plugins-good for F-10.  I tried building gstreamer-plugins-pulse on F-10, but it is incompatible as sound coming through it is completely garbled.  We probably need Lennart to fix this.

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

Created attachment 327050 [details]
backtrace from pidgin

I too have had problems with this, and I have attached a traceback that I got out of gdb.

I have changed from Pidgin's setting of 'Automatic' for the audio device to 'ALSA', and the problem has not reoccurred.

More backtraces of pidgin will not be helpful.  This is clearly a problem in gstreamer's pulseaudio sink or pulseaudio.

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

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

This problem occurs when using the gstreamer alsa sink with the pulseaudio alsa plugin as well as when using the gstreamer pulseaudio sink, so either the same bug exists in both places, or the bug is in the pulseaudio libraries.

I've been having problems in rhythmbox and the developer suggested that the crashed were most likely pa related and that this bug in particular looked to be similar.

I've file a few backtraces at b.g.o and the main bug can be viewed here: http://bugzilla.gnome.org/show_bug.cgi?id=565844

This is not a PA bug. The GSTreamer folks broke the PA plugin for GStreamer by adding a borked "probe" interface implementation to it. The bad commit is this:

http://webcvs.freedesktop.org/gstreamer/gst-plugins-good/ext/pulse/pulsesink.c?r1=1.3&r2=1.4

It creates a reference loop between the probe object and the sink object.

I am working on a fix.

I've posted this note upstream. 

http://bugzilla.gnome.org/show_bug.cgi?id=567746a

bah, fixed url is:

http://bugzilla.gnome.org/show_bug.cgi?id=567746

Ok, got a preliminary blessing for my patch from the gst folks.

I have now added this patch to the rawhide packages. We can push this into F-10 too after some testing. So, please try out the fixed rawhide packages.

Fixed in 0.10.11-3.

http://kojipkgs.fedoraproject.org/packages/gstreamer-plugins-good/0.10.11/
Everyone, please test the latest fc10 build here and report back.

Created attachment 329062 [details]
backtrace from pidgin-bugreport.txt

Seems still crash:

...
Detaching after fork from child process 7921.
Detaching after fork from child process 7922.
Detaching after fork from child process 7923.
Detaching after fork from child process 7924.
Detaching after fork from child process 7925.
Detaching after fork from child process 7926.
Detaching after fork from child process 7927.

Program received signal SIGSEGV, Segmentation fault.
0x012bf109 in ?? () from /usr/lib/purple-2/autoprofile.so
(gdb) thread apply all backtrace

Thread 1 (Thread 0xb7fce750 (LWP 7908)):
#0  0x012bf109 in ?? () from /usr/lib/purple-2/autoprofile.so
#1  0x07185e06 in ?? () from /lib/libglib-2.0.so.0
#2  0x071856d8 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#3  0x07188d83 in ?? () from /lib/libglib-2.0.so.0
#4  0x071892a2 in g_main_loop_run () from /lib/libglib-2.0.so.0
#5  0x07352459 in IA__gtk_main () at gtkmain.c:1200
#6  0x080c705e in main ()
(gdb)

---------
$ rpm -qa *pidgin* *gstreamer* *pulseaudio*
xine-lib-pulseaudio-1.1.15-3.fc10.i386
pulseaudio-libs-0.9.13-6.fc10.i386
pulseaudio-esound-compat-0.9.13-6.fc10.i386
gstreamer-plugins-farsight-0.12.9-3.fc10.i386
gstreamer-plugins-base-0.10.21-2.fc10.i386
pulseaudio-libs-glib2-0.9.13-6.fc10.i386
gstreamer-python-0.10.12-1.fc10.i386
pulseaudio-core-libs-0.9.13-6.fc10.i386
gstreamer-plugins-good-0.10.11-4.fc11.i386
PackageKit-gstreamer-plugin-0.3.12-1.fc10.i386
pulseaudio-module-x11-0.9.13-6.fc10.i386
gstreamer-0.10.21-2.fc10.i386
alsa-plugins-pulseaudio-1.0.18-2.fc10.i386
gstreamer-plugins-flumpegdemux-0.10.15-4.fc10.i386
pulseaudio-module-gconf-0.9.13-6.fc10.i386
gstreamer-debuginfo-0.10.21-2.fc10.i386
gstreamer-tools-0.10.21-2.fc10.i386
kde-settings-pulseaudio-4.1-4.20081031svn.fc10.noarch
totem-gstreamer-2.24.3-1.fc10.i386
pulseaudio-utils-0.9.13-6.fc10.i386
pulseaudio-0.9.13-6.fc10.i386

(In reply to comment #30)
> Created an attachment (id=329062) [details]
> backtrace from pidgin-bugreport.txt
> 
> Seems still crash:

This is a completely different crash, this time it is caused by the "autoprofile" plugin. Please file a separate bug report, against the correct component (autoprofile plugin comes from purple-plugin_pack srpm).
 
> Thread 1 (Thread 0xb7fce750 (LWP 7908)):
> #0  0x012bf109 in ?? () from /usr/lib/purple-2/autoprofile.so
> #1  0x07185e06 in ?? () from /lib/libglib-2.0.so.0
> #2  0x071856d8 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
> #3  0x07188d83 in ?? () from /lib/libglib-2.0.so.0
> #4  0x071892a2 in g_main_loop_run () from /lib/libglib-2.0.so.0
> #5  0x07352459 in IA__gtk_main () at gtkmain.c:1200
> #6  0x080c705e in main ()
> (gdb)

gstreamer-plugins-good-0.10.11-4.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/gstreamer-plugins-good-0.10.11-4.fc10

gstreamer-plugins-good-0.10.11-4.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update gstreamer-plugins-good'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-0659

gstreamer-plugins-good-0.10.11-4.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

I am still seeing what looks like this problem in rawhide with:

gstreamer-plugins-good-0.10.13-2.fc11.i386
pidgin-2.5.4-2.fc11.i386
pulseaudio-0.9.14-2.fc11.i386