Bug 378851
| Summary: | XEmacs assertion failure in sound code | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jerry James <loganjerry> |
| Component: | xemacs | Assignee: | Ville Skyttä <ville.skytta> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8 | CC: | wwoods |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-01-09 05:11:17 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: | |||
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))
(load-default-sounds))
Lennart Poettering pointed out on fedora-devel-list that this may be a
manifestation of this bug:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2601
A workaround to this problem is to configure XEmacs with the following option: --with-sound=nonative,noalsa,esd 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 testing. 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. Thanks, Ville! 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping 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. |
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) at eval.c:3915 #12 0x000000000045f16a in execute_optimized_program ( program=0x12 <Address 0x12 out of bounds>, stack_depth=<value optimized out>, constants_data=0xa345b0) at bytecode.c:862 #13 0x000000000048dd37 in Ffuncall (nargs=2, args=0x7ffff242a5b0) at eval.c:3517 #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>) at cmdloop.c:262 #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>) at cmdloop.c:313 #19 0x000000000048813f in xemacs_21_5_b28_x86_64_redhat_linux (argc=1, argv=0x7ffff242aaa8, unused_envp=<value optimized out>, restart=0) at emacs.c:2667 #20 0x0000000000488d20 in main (argc=<value optimized out>, argv=<value optimized out>, unused_envp=<value optimized out>) at emacs.c:3111 Version-Release number of selected component (if applicable): xemacs-21.5.28-5.fc8 How reproducible: Always Steps to Reproduce: 1. Start XEmacs 2. Press Ctrl-g Actual results: XEmacs crashes with an assertion failure. Expected results: XEmacs plays a beep sound. Additional info: I'm the guy who wrote XEmacs' ALSA code in the first place, so this is probably my fault somehow. :-)