Bug 129421 - gaim segfaults due to libao
Summary: gaim segfaults due to libao
Alias: None
Product: Fedora
Classification: Fedora
Component: libao
Version: 2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: John (J5) Palmieri
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-08-08 20:12 UTC by Pete Zaitcev
Modified: 2013-03-13 04:46 UTC (History)
5 users (show)

Clone Of:
Last Closed: 2006-10-28 15:09:35 UTC

Attachments (Terms of Use)

Description Pete Zaitcev 2004-08-08 20:12:38 UTC
This started after the last update (gaim-0.80-1.FC2), which kinda
fixed Yahoo again (if only gaim stayed up). The gaim intercepts
SIGSEGV, so bug-buddy is useless. Not that it would do much good,
because -debuginfo RPM is not available on download.fedora.redhat.com.

When running with -d, this is seen:

oscar: Received message from wimcoekaerts with charset 0 0
free(): invalid pointer 0x9571aa0!
Gaim has segfaulted and attempted to dump a core file.

So, it segfaults on first message from AIM.

Comment 1 Pete Zaitcev 2004-08-08 20:13:39 UTC
gaim-0.81-0.FC2 fails in the same way.

Comment 3 Pete Zaitcev 2004-08-08 22:36:12 UTC
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -150355840 (LWP 4282)]
0x0099d20c in _int_free () from /lib/tls/libc.so.6
(gdb) where
#0  0x0099d20c in _int_free () from /lib/tls/libc.so.6
#1  0x0099e73b in free () from /lib/tls/libc.so.6
#2  0x4f471785 in operator delete () from /usr/lib/libstdc++.so.6
#3  0x4f4528df in std::string::_Rep::_M_destroy () from
#4  0x4f4529f1 in std::string::assign () from /usr/lib/libstdc++.so.6
#5  0x4f714978 in Arts::Dispatcher::Dispatcher () from
#6  0x006da094 in arts_backend_init () from /usr/lib/libartscbackend.so.0
#7  0x007422b6 in arts_init () from /usr/lib/libartsc.so.0
#8  0x006ed8c9 in ao_plugin_test () from /usr/lib/ao/plugins-2/libarts.so
#9  0x00df435f in ?? () from /usr/lib/libao.so.2
#10 0x00df3560 in ?? () from /usr/lib/libao.so.2
#11 0x08f7ec20 in ?? ()
#12 0xffffffff in ?? ()
#13 0x00df6100 in ?? () from /usr/lib/libao.so.2
#14 0x08f7ec2a in ?? ()
#15 0x0810d5cc in imhtmltoolbar_info.1 ()
#16 0xfef1e428 in ?? ()
#17 0x00df4eb2 in ao_default_driver_id () from /usr/lib/libao.so.2
Previous frame identical to this frame (corrupt stack?)

Comment 4 Pete Zaitcev 2004-08-08 22:39:24 UTC
I see now. The stupid thing is trying to use arts, which is not
active in my session. However, I do not see a way to change it.
The gaim preferences are on "Automatic", and there's no global
setting on the desktop.

Comment 5 Mark Doliner 2004-08-09 00:44:04 UTC
This is very similar to redhat bug 126430.  It seems like there was
another Gaim/sound bug recently that turned out to be a problem with
arts or libao or something, but I don't remember the details or have a
link to it.  With Luck, Luke will know what I'm talking about and post
the bug number when he gets back from Florida :-)

Comment 6 Luke Schierer 2004-08-11 19:14:19 UTC
yeah, we use libao for all things sound. and libao has issues with
arts currently (as per the backtrace above and others).  i'm not sure
why libao is deciding to use arts on your system, but you can force it
to use something else as per http://gaim.sourceforge.net/faq.php#q22

I'm afraid i don't know the bug number(s) involved, as i've been
closing them, but changing to esd, oss, or alsa should work around
this (it has for others with the same backtrace). 

Comment 7 Pete Zaitcev 2004-08-11 19:37:00 UTC
I forced gaim to use ESD, so everything works now.

Daniel, please feel free to close.

Comment 8 Warren Togami 2004-08-11 21:05:09 UTC
Well, this is a libao bug, so reassigning.

Comment 9 Colin Walters 2004-09-03 01:51:47 UTC
Can anyone here still reproduce this bug?

Comment 10 Luke Schierer 2004-09-03 01:56:23 UTC
i still see occasional reports of it in our tracker, but i myself have
not attempted to reproduce it. 

Comment 11 Pete Zaitcev 2004-09-03 02:37:56 UTC
Easier than anything, Colin. I've ran "yum update" on FC2


Now, it's quite enough to go to Preferences, change the "ESD"
to "Automatic" and the gaim collapses without even exiting
the dialog.

Comment 12 Colin Walters 2004-09-09 21:22:53 UTC
I just installed a fresh FC2 box with the latest updates, new user
account, and I went into "Internet->IM", and the default was already
"Automatic".  Changing it to ESD then back to Automatic didn't cause a

Do I have to have an AIM account?  What else is needed to reproduce
this problem?

Comment 13 Pete Zaitcev 2004-09-09 21:46:18 UTC
Yes I do have an AIM account. The thing collapses even if I am
not logged in though.

I have no idea "what else is needed to reproduce the problem".
I thought it was a developer's job to figure that out by posting
skillfuly framed questions to the user :-)

One possible hint may be that I do have arts installed
(arts-2.2.2-9), only it is not running. Obviously you cannot
enter arts_init() as in the backtrace if you do not have that

And OF COURSE the default is "Automatic" for all new users,
this is how the bug came about (see comment #4).

Comment 14 Pete Zaitcev 2004-09-09 23:10:08 UTC
Correction to the arts version: arts-1.2.3-3

Comment 15 Luke Schierer 2004-09-09 23:33:38 UTC
shouldn't happen just on changing the preference. should happen on
first attempt to play a sound after changing the preference. 

Comment 16 Pete Zaitcev 2004-09-10 00:17:01 UTC
What Luke says sounds natural, but for some reason something
initializes arts as soon as you select "Automatic" in the dialog,
even before you hit "OK" (no kidding!). Here's the trace:

[Thread debugging using libthread_db enabled]
[New Thread -151101312 (LWP 4924)]

free(): invalid pointer 0x96da7f0!
free(): invalid pointer 0x96daa40!
free(): invalid pointer 0x96daa70!
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -151101312 (LWP 4924)]
0x0099d6be in malloc_consolidate () from /lib/tls/libc.so.6
(gdb) where
#0  0x0099d6be in malloc_consolidate () from /lib/tls/libc.so.6
#1  0x0099ccaa in _int_malloc () from /lib/tls/libc.so.6
#2  0x0099c09d in malloc () from /lib/tls/libc.so.6
#3  0x4f472a47 in operator new () from /usr/lib/libstdc++.so.6
#4  0x4f730bcc in std::_Deque_base<Arts::Notification,
std::allocator<Arts::Notification> >::_M_create_nodes () from
#5  0x4f730c4e in std::_Deque_base<Arts::Notification,
std::allocator<Arts::Notification> >::_M_initialize_map () from
#6  0x4f73040e in Arts::NotificationManager::removeClient ()
   from /usr/lib/libmcop.so.1
#7  0x4f71d106 in Arts::Object_base::~Object_base () from
#8  0x4f738037 in Arts::TmpGlobalComm_impl::~TmpGlobalComm_impl ()
   from /usr/lib/libmcop.so.1
#9  0x4f719ce6 in Arts::Object_base::_destroy () from
#10 0x4f719ef7 in Arts::Object_skel::_release () from
#11 0x4f710e73 in Arts::Dispatcher::~Dispatcher () from
#12 0x007c201f in arts_backend_init () from /usr/lib/libartscbackend.so.0
#13 0x001ec2b6 in arts_init () from /usr/lib/libartsc.so.0
#14 0x003488c9 in ao_plugin_test () from /usr/lib/ao/plugins-2/libarts.so
#15 0x00df435f in ?? () from /usr/lib/libao.so.2
#16 0x0000000a in ?? ()
#17 0x00000000 in ?? ()

Comment 17 Warren Togami 2004-09-10 01:11:39 UTC
> free(): invalid pointer 0x96da7f0!

Aren't these messages glibc catching a memory use error and aborting?
 Pete, does it still crash if you run gaim with MALLOC_CHECK_=0?

Comment 18 Pete Zaitcev 2004-09-10 02:06:09 UTC
This appears to work:


Comment 19 Colin Walters 2004-09-13 17:26:11 UTC
Pete, can you try using valgrind?  That should show the real source of
the problem (a backtrace in malloc_consolidate is often just a symptom
of an earlier error).

Also, can you try creating a new user account and seeing what it takes
to reproduce from there?  

Comment 20 John Thacker 2006-10-28 15:09:35 UTC
Closing per lack of response.  Also note that FC1 and FC2 are no longer
supported even by Fedora Legacy.  If this still occurs on FC3 or FC4, please
assign to that version and Fedora Legacy.  If it still occurs on FC5 or FC6,
please reopen and assign to the correct version.

Note You need to log in before you can comment on or make changes to this bug.