Description of problem: Audacity regularly causes X to abort, losing work. Version-Release number of selected component (if applicable): audacity-1.3.11-0.1.beta.fc12.x86_64 xorg-x11-server-Xorg-1.7.6-1.fc12.x86_64 kernel-2.6.32.9-70.fc12.x86_64 kdelibs-4.4.1-6.fc12.x86_64 How reproducible: Doesn't always happen, even when repeating similar steps, but it happens frequently, after about 10-15 minutes work. Steps to Reproduce: 1. Use audacity. 2. Keep using it. 3. Boom - there you go. Actual results: X session aborts and you're taken back to the display manager login Expected results: audacity doesn't take down X Additional info: Sometimes I get a core, sometimes I don't. Next time I get one I'll add it to this report. /var/log/messages shows: Mar 26 15:56:50 moria abrt[2517]: can't read /proc/1563/exe link Mar 26 15:56:50 moria kdm[1513]: X server for display :0 terminated unexpectedly Mar 26 15:56:50 moria kernel: [drm:drm_mode_getfb] *ERROR* invalid framebuffer id This only ever happens to me when using Audacity which is why I've assigned it to that component. The operation in Audacity depends, sometimes I'm zooming in/out, sometimes I'm deleting a selected region (e.g. shift-K then ctrl-K) and sometimes I'm exporting to a wav file. I might have several audacity windows open, in each one I'm only working on single stereo tracks a few seconds long, imported from a wav file, then trimming silence from the beginning and end and then exporting back to wav (overwriting the original file I imported.)
that didn't take long. /var/log/messages shows: Mar 26 16:34:27 moria abrt[3738]: saved core dump of pid 2522 (/usr/bin/Xorg) to /var/cache/abrt/ccpp-1269621267-2522.new/coredump (65416 bytes) Mar 26 16:34:27 moria abrtd: Directory 'ccpp-1269621267-2522' creation detected Mar 26 16:34:27 moria kdm[1513]: X server for display :0 terminated unexpectedly Mar 26 16:34:27 moria kernel: eu-unstrip[3744]: segfault at 7f328aa0d000 ip 0000003e21206c3d sp 00007fff09292e40 error 4 in libelf-0.145.so[3e21200000+14000] Mar 26 16:34:27 moria kernel: [drm:drm_mode_getfb] *ERROR* invalid framebuffer id Mar 26 16:34:28 moria abrt[3746]: saved core dump of pid 3744 (/usr/bin/eu-unstrip) to /var/cache/abrt/ccpp-1269621267-3744.new/coredump (425984 bytes) Mar 26 16:34:28 moria abrtd: New crash /var/cache/abrt/ccpp-1269621267-2522, processing Mar 26 16:34:28 moria abrtd: Registered Action plugin 'RunApp' Mar 26 16:34:28 moria abrtd: RunApp('/var/cache/abrt/ccpp-1269621267-2522','test x"`cat component`" = x"xorg-x11-server-Xorg" && cp /var/log/Xorg.0.log .') Mar 26 16:34:28 moria abrtd: Directory 'ccpp-1269621267-3744' creation detected Mar 26 16:34:28 moria abrtd: New crash /var/cache/abrt/ccpp-1269621267-3744, processing Mar 26 16:34:28 moria abrtd: RunApp('/var/cache/abrt/ccpp-1269621267-3744','test x"`cat component`" = x"xorg-x11-server-Xorg" && cp /var/log/Xorg.0.log .') abrt is no use, it shows: warning: section .gnu.liblist not found in /usr/lib/debug/usr/bin/Xorg.debug warning: section .gnu.conflict not found in /usr/lib/debug/usr/bin/Xorg.debug "/var/cache/abrt/ccpp-1269621267-2522/coredump" is not a core dump: File truncated No shared libraries loaded at this time. No symbol "__abort_msg" in current context. No symbol "__glib_assert_msg" in current context. The only useful info from abrt is: Reason: Process /usr/bin/Xorg was killed by signal 6 (SIGABRT)
(In reply to comment #0) > How reproducible: > Doesn't always happen, even when repeating similar steps, but it happens > frequently, after about 10-15 minutes work. What audio IO is set up in the Edit|Preferences|Audio IO tab for device for playback and recording ? Could you confirm whether you experience the same issue if you repeat various of your (sometimes) reproducible steps, but never playback or record audio during the session ?
I don't see an Audio IO tab. Under Devices I have ALSA as Interface Host, that's the only option. Playback and Recording devices are 'default' I *think* it still happens if I never play/record audio, but less often. I'll try to confirm that in the next day or two...
It still causes X to abort even without playing or recording any audio. I ran "audacity *" in a directory with 37 wav files, and audacity still took out my X server. It hadn't even finished opening all the files, and I hadn't clicked anything or started to do anything yet. I've had it with audacity, I'll use something else instead.
P.S. the largest file was 1.44MB and most were under 1MB, on a quadcore with 4GB so there's no issue with resources
I've edited and imported/exported dozens of audio tracks in this version of Audacity without any such problems. > Mar 26 16:34:27 moria kernel: eu-unstrip[3744]: segfault at 7f328aa0d000 > ip 0000003e21206c3d sp 00007fff09292e40 error 4 > in libelf-0.145.so[3e21200000+14000] Huh? libelf? That's not related to Audacity. > Mar 26 16:34:27 moria kernel: [drm:drm_mode_getfb] *ERROR* invalid > framebuffer id Driver bug?
(In reply to comment #6) > I've edited and imported/exported dozens of audio tracks in this version of > Audacity without any such problems. Dozens? wow, surely not? Forgive the sarcasm, but I've *attempted* to do many hundreds, and had dozens of crashes. As I said, it doesn't happen every time and isn't repeatable, so the fact it works on dozens of files is hardly conclusive proof of anything. > > Mar 26 16:34:27 moria kernel: eu-unstrip[3744]: segfault at 7f328aa0d000 > > ip 0000003e21206c3d sp 00007fff09292e40 error 4 > > in libelf-0.145.so[3e21200000+14000] > > Huh? libelf? That's not related to Audacity. Obviously. That's another problem, reported as Bug 577310 > > Mar 26 16:34:27 moria kernel: [drm:drm_mode_getfb] *ERROR* invalid > > framebuffer id > > Driver bug? Could be
I no longer get the invalid framebuffer id error, but my X server still crashes when I run audacity, now /var/log/messages shows: Apr 18 12:53:15 moria kdm[1499]: X server for display :0 terminated unexpectedly I can reproduce the crash reliably now, but it needs 6.5MB of wave files. If anyone wants to try to reproduce the problem (possibly they'll need to be running the Xorg radeon driver) let me know and I'll make the files available
> the fact it works on dozens of files is hardly conclusive > proof of anything. > it needs 6.5MB of wave files I don't understand your sarcasm in the earlier comment. What I wrote is what I meant. The "dozens of audio tracks" is plural, where "dozens" can be anything in N*12 with N>1. What may be reproducible for you is simply not reproducible here. Audacity has imported, _edited_ and exported more than 6.5 GB (!) of WAV files in the same project session, which is a lot more than your 6.5MB. It should not be seen as proof of anything. Audacity contains bugs, and it has suffered from various race conditions (and hard to reproduce side-effects) in earlier beta releases. With regard to X server crashes, there's still wxWidgets (= wxGTK) between Audacity and X. > possibly they'll need to be > running the Xorg radeon driver xorg-x11-drv-ati? # lspci|grep VGA 01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3450
(In reply to comment #9) > > the fact it works on dozens of files is hardly conclusive > > proof of anything. > > > it needs 6.5MB of wave files > > I don't understand your sarcasm in the earlier comment. What I wrote is what I > meant. The "dozens of audio tracks" is plural, where "dozens" can be anything > in N*12 with N>1. What may be reproducible for you is simply not reproducible > here. Audacity has imported, _edited_ and exported more than 6.5 GB (!) of WAV > files in the same project session, which is a lot more than your 6.5MB. that 6.5MB is the minimal set with which I can reproduce the problem, not the entire set of files I'm working with. I could provide a much larger tarball that fails for me, but in order to be helpful I tried to reduce it to the smallest set. let's not get into a pissing contest of who's edited more files, my point (which you agreed with) is that editing some number of files successfully doesn't prove anything, I get crashes with some other value, so quoting numbers is meaningless. So anyway, I have a 6.5MB tarball that can reproduce the problem. The files are copyrighted, not by me, so I'm not going to post them to bugzilla, but if someone wants to try to reproduce this crash I will provide them. > It should not be seen as proof of anything. Audacity contains bugs, and it has > suffered from various race conditions (and hard to reproduce side-effects) in > earlier beta releases. With regard to X server crashes, there's still wxWidgets > (= wxGTK) between Audacity and X. > > > possibly they'll need to be > > running the Xorg radeon driver > > xorg-x11-drv-ati? Yes > # lspci|grep VGA > 01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3450 FWIW I have 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon HD 3300 Graphics
Hi Jonathon, Just wanted to check if you continued using audacity, fedora 12 and if so, whether this problem is still present ? I would like to try to reproduce with your source material (however, that seems unlikely to be the direct cause), with a step by step of actions you take. If you can place the archive somewhere I'll dl it and reply for you to remove it. Would you also be able to repeat the process with the current audacity 1.3.12-beta, which has been built and continues to work fine for me in F12 ? yum --enablerepo=updates-testing update audacity Positive or negative feedback should be left in the comment section at: https://admin.fedoraproject.org/updates/audacity-1.3.12-0.4.beta.fc12
Hi David, sorry for not responding sooner. I've now upgraded to F13 but still have the same problem with audacity 1.3.12-0.4 I've emailed you the URL of a tar file containing some WAVs, I can reproduce the crash just by saying 'audacity *' and it kills my X server before opening all files. I'm running the latest updates from F13: xorg-x11-server-Xorg-1.8.2-2.fc13.x86_64 xorg-x11-drv-ati-6.13.0-1.fc13.x86_64 audacity-1.3.12-0.4.beta.fc13.x86_64
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 '12'. 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 12'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 12 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
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. 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 '13'. 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 13'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 13 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 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 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.