Red Hat Bugzilla – Bug 378851
XEmacs assertion failure in sound code
Last modified: 2009-01-09 00:11:17 EST
Description of problem:
In Fedora 8, any use of sound by XEmacs leads to an assertion failure in the
sound code. The easiest way to trigger the problem is to press Ctrl-g in a
fresh XEmacs. The inability to use Ctrl-g seriously hampers the usability of
XEmacs. The crash message is:
xemacs: pcm_params.c:2351: sndrv_pcm_hw_params: Assertion `err >= 0' failed.
Fatal error (6).
... followed by the usual XEmacs crash message. The Lisp backtrace only shows
that "ding" was called. The C backtrace is as follows:
#0 0x0000003838e31357 in kill () from /lib64/libc.so.6
#1 0x0000000000487014 in fatal_error_signal (sig=6) at emacs.c:3800
#2 <signal handler called>
#3 0x0000003838e30ec5 in raise () from /lib64/libc.so.6
#4 0x0000003838e32970 in abort () from /lib64/libc.so.6
#5 0x0000003838e2a11f in __assert_fail () from /lib64/libc.so.6
#6 0x0000003848c59a68 in XtManageChild () from /lib64/libasound.so.2
#7 0x0000003848c55403 in snd_pcm_hw_params () from /lib64/libasound.so.2
#8 0x00000000004ac0a4 in alsa_play_sound_data (
data=0x7ffff2429f70 "RIFFT\002", length=604, volume=75) at alsaplay.c:369
#9 0x000000000056a883 in Fplay_sound (sound=<value optimized out>,
volume=<value optimized out>, device=<value optimized out>) at sound.c:388
#10 0x000000000056aaa5 in Fding (no_terminate=9302320, sound=9267664,
device=<value optimized out>) at sound.c:537
#11 0x000000000048e001 in Ffuncall (nargs=3, args=0x7ffff242a3c8)
#12 0x000000000045f16a in execute_optimized_program (
program=0x12 <Address 0x12 out of bounds>,
stack_depth=<value optimized out>, constants_data=0xa345b0)
#13 0x000000000048dd37 in Ffuncall (nargs=2, args=0x7ffff242a5b0)
#14 0x000000000048e5cc in call1 (fn=<value optimized out>,
arg0=<value optimized out>) at eval.c:4567
#15 0x00000000004902e5 in condition_case_1 (handlers=<value optimized out>,
bfun=0x469b10 <command_loop_1>, barg=9302320, hfun=0x469c80 <cmd_error>,
harg=9302320) at eval.c:1930
#16 0x0000000000469c30 in command_loop_2 (unused_dummy=<value optimized out>)
#17 0x000000000048c630 in internal_catch (tag=<value optimized out>,
func=0x469c00 <command_loop_2>, arg=9302320, threw=0x0, thrown_tag=0x0,
backtrace_before_throw=0x0) at eval.c:1552
#18 0x0000000000469ec0 in initial_command_loop (load_me=<value optimized out>)
#19 0x000000000048813f in xemacs_21_5_b28_x86_64_redhat_linux (argc=1,
argv=0x7ffff242aaa8, unused_envp=<value optimized out>, restart=0)
#20 0x0000000000488d20 in main (argc=<value optimized out>,
argv=<value optimized out>, unused_envp=<value optimized out>)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start XEmacs
2. Press Ctrl-g
XEmacs crashes with an assertion failure.
XEmacs plays a beep sound.
I'm the guy who wrote XEmacs' ALSA code in the first place, so this is probably
my fault somehow. :-)
This works fine for me with a freshly installed xemacs; did you have to do
something to enable ALSA magic? I just get a PC Speaker beep rather than
anything through the audio device.
Sorry, I added this to my .xemacs/init.el so long ago that I had forgotten all
about it. Try this:
(if (or (featurep 'alsa-sound) (featurep 'native-sound))
Lennart Poettering pointed out on fedora-devel-list that this may be a
manifestation of this bug:
A workaround to this problem is to configure XEmacs with the following option:
This is probably a good change to make permanently in F8+ anyway, since it makes
XEmacs talk directly to the PulseAudio daemon. I've been using an XEmacs
configured that way all day, and haven't had a single crash.
Hm, I remember there's a long history of crash reports on xemacs-beta about
XEmacs and EsounD and AFAIU that's the reason why its autodetection is off by
default in XEmacs's build upstream; has something significant happened in this
area so that those crashes should no longer happen?
Yes, you are right. However, any use of XEmacs' ALSA sound code in F8+ results
in an immediate crash every time. I've been using the ESD code for several days
now without a single crash. Also, those reports were against "real" ESD, not
PulseAudio-pretending-to-be-ESD, although that may not matter.
Ok. I tried to reproduce the crash with 21.5.28-5.fc8 on x86_64, KDE with aRts
enabled but all system sounds disabled, no pulseaudio, no esd, but failed.
Could you give me an exact recipe how you can trigger the crash? I applied your
init.el snippet from comment 2 and added a similar featurep for esd-sound for
Hitting Ctrl-G in a scratch buffer I can hear something (like cracks or the
like) from speakers, but there's no crash. After configuring with
--with-sound=nonative,noalsa,esd there's no sound whatsoever anymore, but I
suppose that's because I don't have esd running nor pulseaudio enabled.
I'm using GNOME with xemacs-21.5.28-5.fc8. I have access to two machines, one
i386 and one x86_64. I get the same crash on both. Using the comment 2
snippet, I can start XEmacs, press Ctrl-g, and get the reported crash. These
are default Fedora 8 installs; I've done nothing to the sound settings since
installing. Since this appears to be a PulseAudio bug, you'll have to be
running PulseAudio to get the crash. We already know that "real" ALSA works.
You get this crash if you are using alsa-plugins-pulseaudio.
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '8'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 8's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 8 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.