Description of problem: 1. Start Rosegarden 2. Set a track to use ZynAddSubFX (DSSI) as a Synth Plug In 3. Put some notes in that track using the Notation Editor 4. Press Play The first note will play, but the computer will crash before the second note is played. This error is repeatable always. Version-Release number of selected component: rosegarden4-12.04-3.fc17 Additional info: libreport version: 2.0.14 abrt_version: 2.0.13 backtrace_rating: 4 cmdline: rosegarden crash_function: Master::AudioOut kernel: 3.5.4-2.fc17.x86_64 truncated backtrace: :Thread no. 1 (10 frames) : #0 Master::AudioOut at /usr/src/debug/ZynAddSubFX-2.4.2/src/Misc/Master.cpp:306 : #1 Master::GetAudioOutSamples at /usr/src/debug/ZynAddSubFX-2.4.2/src/Misc/Master.cpp:476 : #2 DSSIaudiooutput::runSynth at /usr/src/debug/ZynAddSubFX-2.4.2/src/Output/DSSIaudiooutput.cpp:454 : #3 Rosegarden::DSSIPluginInstance::run at src/sound/DSSIPluginInstance.cpp:988 : #4 Rosegarden::AudioInstrumentMixer::processBlock at src/sound/AudioProcess.cpp:1836 : #5 Rosegarden::AudioInstrumentMixer::processBlocks at src/sound/AudioProcess.cpp:1677 : #6 Rosegarden::AudioInstrumentMixer::kick at src/sound/AudioProcess.cpp:2041 : #7 Rosegarden::JackDriver::jackProcess at src/sound/JackDriver.cpp:795 : #8 Jack::JackClient::CallProcessCallback at ../common/JackClient.cpp:590 : #9 Jack::JackClient::ExecuteThread at ../common/JackClient.cpp:557
Created attachment 622965 [details] File: core_backtrace
Created attachment 622966 [details] File: environ
Created attachment 622967 [details] File: backtrace
Created attachment 622968 [details] File: limits
Created attachment 622969 [details] File: cgroup
Created attachment 622970 [details] File: maps
Created attachment 622971 [details] File: dso_list
Created attachment 622972 [details] File: var_log_messages
Created attachment 622973 [details] File: open_fds
The crash occurs inside zynaddsubfx code. Therefore reassigning to zynaddsubfx. On a side note, it would be better to report such issues directly to the upstream developers.
I'm terribly sorry, I didn't realise that when ABRT asks me to file a bug report it doesn't actually mean it. Just to be clear, are you suggesting I should ignore it in future?
For redhat-brewed software, it is a great feature to have the backtraces filed at a central location, and the responsible developers can go through them when they are fixing bugs. But not all software distributed by Fedora are written by Fedora or redhat devs. We just distribute the packages. The problem is, the user won't know where to file a bug before doing some research. But fixing the bugs is all about research, isn't it? The best way to go with crashes (to my opinion) is to identify the upstream developers, have ABRT print out the backtrace instead of sending the backtrace to this bugzilla, and send the backtrace to the upstream developers directly. For now this has to be done manually, but from what I heard, ABRT will support filing bugs to upstream trackers in the future. If the user takes the easy route and submits the bug report here, he is at the mercy of the package maintainer. Some maintainers just ignore the ABRT-filed bugs; either they don't have time, or they don't know how to read code/debug (not all packagers are coders). The situation is even worse when the users don't supply the "steps the reproduce". Even when the user supplies this information, sometimes (as is the case with this particular bug report) the packager cannot reproduce the crash. The best he can do at this point is to become the middle man and forward the backtrace to upstream developers. The developers will come with further questions and requests, which will need to be forwarded back to the user. You see my point? I think that a good way to avoid this inefficiency is to communicate the developers directly.
Thanks for the reply; in future I'll only report bugs here when it's something that Red Hat develops - stuff like systemd or colord or SELinux and not for stuff like Rosegarden.
I can't reproduce this bug running Rosegarden under KDE. It might be something specific to the parts/instruments you have loaded in the DSSI plugin What parts are you using? Further to what Orcan said, I do appreciate bugs being logged in Bugzilla, especially if there is a link to upstream's tracker so that we are aware of any patches as they become available.
Thanks Brendan. Fluidsynth-DSSI doesn't produce any sort of GUI under GNOME in Fedora 17. I'm using Fedora 17 GNOME 64-bit and have downloaded all the packages from the repository. If I start JACK and then type jack-dssi-host fluidsynth-dssi.so I get no GUI - so I can't even load soundfonts into the plug-in.
If I type: /usr/lib64/dssi/fluidsynth-dssi/FluidSynth-DSSI_gtk -test I can see the gui and it works fine. With Jack working, if I try /usr/lib64/dssi/fluidsynth-dssi/FluidSynth-DSSI_gtk I get: fsd-gui starting (pid 1910)... Segmentation fault (core dumped) In Rosegarden I get: AudioInstrumentMixer::setPlugin(10000, 999, dssi:/usr/lib64/dssi/fluidsynth-dssi.so:FluidSynth-DSSI) But it says no GUI is available and the editor button does not work.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. 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 '17'. 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 17'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 17 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, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. 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.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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.