Bug 129421

gaim-0.81-0.FC2 fails in the same way.

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
/usr/lib/libstdc++.so.6
#4  0x4f4529f1 in std::string::assign () from /usr/lib/libstdc++.so.6
#5  0x4f714978 in Arts::Dispatcher::Dispatcher () from
/usr/lib/libmcop.so.1
#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?)
(gdb)

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.

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 :-)

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). 

I forced gaim to use ESD, so everything works now.

Daniel, please feel free to close.

Well, this is a libao bug, so reassigning.

Can anyone here still reproduce this bug?

i still see occasional reports of it in our tracker, but i myself have
not attempted to reproduce it. 

Easier than anything, Colin. I've ran "yum update" on FC2

gaim-0.82-0.FC2
libao-0.8.4-2.1

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

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
problem.

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

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
library.

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

Correction to the arts version: arts-1.2.3-3

shouldn't happen just on changing the preference. should happen on
first attempt to play a sound after changing the preference. 

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
/usr/lib/libmcop.so.1
#5  0x4f730c4e in std::_Deque_base<Arts::Notification,
std::allocator<Arts::Notification> >::_M_initialize_map () from
/usr/lib/libmcop.so.1
#6  0x4f73040e in Arts::NotificationManager::removeClient ()
   from /usr/lib/libmcop.so.1
#7  0x4f71d106 in Arts::Object_base::~Object_base () from
/usr/lib/libmcop.so.1
#8  0x4f738037 in Arts::TmpGlobalComm_impl::~TmpGlobalComm_impl ()
   from /usr/lib/libmcop.so.1
#9  0x4f719ce6 in Arts::Object_base::_destroy () from
/usr/lib/libmcop.so.1
#10 0x4f719ef7 in Arts::Object_skel::_release () from
/usr/lib/libmcop.so.1
#11 0x4f710e73 in Arts::Dispatcher::~Dispatcher () from
/usr/lib/libmcop.so.1
#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 ?? ()
(gdb)

> 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?

This appears to work:

MALLOC_CHECK_=0 gaim

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?  

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.