From: D. M. M. <mic...@ro...> - 2010-04-27 23:10:23
|
On Tuesday 27 April 2010, Dave Plater wrote: > In fact if you set any synth in a new file and save it and then... Easiest way to reproduce the crash: 1. New document. 2. Assign track 1 to "Synth" and load a plugin (any plugin) 3. Save this file (probably not required, but convenient) 4. File->New 5. Open synth plugin manager, and try to assign plugin #1 to a plugin 6. BOOM! You can repeat it on future runs by starting Rosegarden, hitting Ctrl+R to load the file you saved previously, then Ctrl+N to start a new document, then starting the plugin manager. I spent about an hour looking into this and it's all the time I have. I think this is probably related to the way we used to save things from the studio in the last document for use in the current document when creating a new document. Something is pointing to something that's no longer there, but what, and where elude me. -- D. Michael McIntyre |
From: Dave P. <dp...@we...> - 2010-04-28 06:54:44
|
On 04/28/2010 01:10 AM, D. Michael McIntyre wrote: > On Tuesday 27 April 2010, Dave Plater wrote: > > >> In fact if you set any synth in a new file and save it and then... >> > Easiest way to reproduce the crash: > > 1. New document. > 2. Assign track 1 to "Synth" and load a plugin (any plugin) > 3. Save this file (probably not required, but convenient) > 4. File->New > 5. Open synth plugin manager, and try to assign plugin #1 to a plugin > 6. BOOM! > > You can repeat it on future runs by starting Rosegarden, hitting Ctrl+R to > load the file you saved previously, then Ctrl+N to start a new document, then > starting the plugin manager. > > I spent about an hour looking into this and it's all the time I have. I think > this is probably related to the way we used to save things from the studio in > the last document for use in the current document when creating a new > document. Something is pointing to something that's no longer there, but > what, and where elude me. > You don't even have to load a plugin in step 2, just set track parameters to Synth, save file, step 4 new file (which resets track parameters to general midi device) and then steps 5 and 6. Dave P |
From: Chris C. <ca...@al...> - 2010-04-28 08:30:20
|
On Wed, Apr 28, 2010 at 7:37 AM, Dave Plater <dp...@we...> wrote: > On 04/28/2010 01:10 AM, D. Michael McIntyre wrote: >> 1. New document. >> 2. Assign track 1 to "Synth" and load a plugin (any plugin) >> 3. Save this file (probably not required, but convenient) >> 4. File->New >> 5. Open synth plugin manager, and try to assign plugin #1 to a plugin >> 6. BOOM! > > You don't even have to load a plugin in step 2 And as Michael hinted, you don't have to save the file either. 1. Start RG 2. Assign track 1 to "Synth" 3. File -> New 4. Open synth plugin manager and try to assign plugin #1 to a plugin 5. splat Chris |
From: Chris C. <ca...@al...> - 2010-04-28 09:18:55
|
Turns out to be fairly simple, and a very typical bug for us -- poor management of pointers-into-things when those things are switched about. When setting the synth instrument in the first document, the instrument parameter panel (the thing at the bottom-left of the main window) was told to display that synth instrument. Then a new document was loaded, as a consequence of which that instrument was deleted, and a plugin assignment was made from the synth plugin manager. That invoked a slot on the instrument parameter panel which attempted to do something with the (now deleted) instrument. The underlying cause was that the instrument pointer in the parameter panel was not being reset when the document was changed. Fixed in rev 11881. Incidentally, the reason you had to go through the synth plugin manager to make this crash happen was that that way you can set a plugin without selecting a particular instrument in the parameter panel first, so that the invalid pointer is still sitting around in the panel. Once you know the mechanics of it, you can actually crash it in various different ways, for example: 1. Start RG 2. Assign the first track to an audio instrument 3. File -> New 4. Open the audio mixer window 5. Click one of the plugin buttons for the first audio instrument 6. kersplat (Also fixed in that revision.) This is quite a significant bug, then, which could have bitten quite a few users. Chris |
From: D. M. M. <mic...@ro...> - 2010-04-28 10:41:40
|
On Wednesday 28 April 2010, Chris Cannam wrote: > This is quite a significant bug, then, which could have bitten quite a > few users. 10.04.2 -- D. Michael McIntyre |
From: Julie S <msj...@ya...> - 2010-04-28 12:07:16
|
Hello All, Concerning: > > This is quite a significant bug, then, which could > have bitten quite a > > few users. > > 10.04.2 maybe, let me see what I can dig up today about MMC and another bug Tempo bug in notation view that is reported here: https://bugzilla.novell.com/show_bug.cgi?id=595479 I'll report back this evening. US Eastern Time. Sincerely, Julie S |
From: Julie S <msj...@ya...> - 2010-04-28 14:13:20
|
Hello All (and Dave Platter in-particular), Concerning: > another bug Tempo bug in notation view that is reported > here: > https://bugzilla.novell.com/show_bug.cgi?id=595479 Committed revision 11883 fixes that bug. Tempo changes via Composition->Add Tempo Change... now function correctly for notation / and matrix views. Sincerely, Julie S. |
From: Julie S <msj...@ya...> - 2010-04-28 16:12:23
|
Hello Michael, Concerning: > Cannam wrote: > > This is quite a significant bug, then, which could > have bitten quite a > > few users. > > 10.04.2 > -- > D. Michael McIntyre I'm done with what I can do. One bug fix -- tempo changes, and one dead end (MMC issues). Unless I get more information. So I don't think, I'll be touching the code further anytime soon. Sincerely, Julie S. |
From: Chris C. <ca...@al...> - 2010-04-28 18:11:16
|
On Wed, Apr 28, 2010 at 5:12 PM, Julie S <msj...@ya...> wrote: > I'm done with what I can do. Well, that's not such a bad stack of fixes for a couple of days. And we still have time for an updated release before the end of April. Anyone got any other pending fixes? Michael, will you or shall I? You would probably be more efficient, but I can step in if you're too busy. Chris |
From: D. M. M. <mic...@ro...> - 2010-04-29 03:43:52
|
On Wednesday 28 April 2010, Chris Cannam wrote: > Michael, will you or shall I? You would probably be more efficient, > but I can step in if you're too busy. I am, rather. I was going to say "Oh, I'll just do it, don't worry about it" but that was like nine hours ago now, and it's not looking so good for tomorrow at this rate. -- D. Michael McIntyre |
From: Dave P. <dp...@we...> - 2010-04-28 19:39:12
|
On 04/28/2010 08:11 PM, Chris Cannam wrote: > On Wed, Apr 28, 2010 at 5:12 PM, Julie S <msj...@ya...> wrote: > >> I'm done with what I can do. >> > Well, that's not such a bad stack of fixes for a couple of days. And > we still have time for an updated release before the end of April. > > Anyone got any other pending fixes? > > Michael, will you or shall I? You would probably be more efficient, > but I can step in if you're too busy. > > > Chris > > JFYI, I'm pushing 10.06 svn 11883 to 11.3 seeing as it fixes a couple of bugs and is very stable anyway. Thanks for a great package. Dave P |
From: Chris C. <ca...@al...> - 2010-04-28 20:05:40
|
On Wed, Apr 28, 2010 at 8:38 PM, Dave Plater <dp...@we...> wrote: > JFYI, I'm pushing 10.06 svn 11883 to 11.3 seeing as it fixes a couple of > bugs and is very stable anyway. Hang on -- careful there. Don't let it identify itself as 10.06-something, because that'll be horribly confusing when 10.04.2 comes out and is actually newer than it. Perhaps this is a good reason to have version numbers for development snapshots be based on the prior release number rather than the following one? Chris |
From: Dave P. <dp...@we...> - 2010-04-28 21:34:00
|
On 04/28/2010 10:05 PM, Chris Cannam wrote: > On Wed, Apr 28, 2010 at 8:38 PM, Dave Plater <dp...@we...> wrote: > >> JFYI, I'm pushing 10.06 svn 11883 to 11.3 seeing as it fixes a couple of >> bugs and is very stable anyway. >> > Hang on -- careful there. Don't let it identify itself as > 10.06-something, because that'll be horribly confusing when 10.04.2 > comes out and is actually newer than it. > > Perhaps this is a good reason to have version numbers for development > snapshots be based on the prior release number rather than the > following one? > > > Chris > > If there's more to come after 11883 I'll wait, I'm still waiting on Michel to test anyway, I can only push a version update if it's a bug fix and I've two so far. We're on Milestone 6 which I was lead to believe is the first beta and I've got until around June 17th which is the first release candidate. I'm trying to have the latest version in 11.3. I don't use the .2 in 10.04.2 because it would confuse the hell out of the distro versioning system which updates the release number after every change. It's purely a cosmetic thing having 10.04 when 10.06 is released just after 11.3 is released doesn't look good. Dave P |
From: Dave P. <dp...@we...> - 2010-04-28 09:52:47
Attachments:
bug-586083_new.txt
bug-586083_singet_nees2.rg
|
On 04/28/2010 11:18 AM, Chris Cannam wrote: > Turns out to be fairly simple, and a very typical bug for us -- poor > management of pointers-into-things when those things are switched > about. > > When setting the synth instrument in the first document, the > instrument parameter panel (the thing at the bottom-left of the main > window) was told to display that synth instrument. Then a new > document was loaded, as a consequence of which that instrument was > deleted, and a plugin assignment was made from the synth plugin > manager. That invoked a slot on the instrument parameter panel which > attempted to do something with the (now deleted) instrument. > > The underlying cause was that the instrument pointer in the parameter > panel was not being reset when the document was changed. Fixed in rev > 11881. > > Incidentally, the reason you had to go through the synth plugin > manager to make this crash happen was that that way you can set a > plugin without selecting a particular instrument in the parameter > panel first, so that the invalid pointer is still sitting around in > the panel. Once you know the mechanics of it, you can actually crash > it in various different ways, for example: > > 1. Start RG > 2. Assign the first track to an audio instrument > 3. File -> New > 4. Open the audio mixer window > 5. Click one of the plugin buttons for the first audio instrument > 6. kersplat > > (Also fixed in that revision.) > > This is quite a significant bug, then, which could have bitten quite a > few users. > > > Chris > > There was two bugs open from Michel Munnix caused by this, glad it's fixed at last. There's another one about a segfault in notation editor when splitting a note in the main window with notation editor open. It's a nasty difficult to reproduce one, Here's how it happens pasted direct from the bug :- I can reproduce if I reopen the file and do the following: ctrl-A (select all) N open notation editor set font size to 14 (perhaps not important) go to measure 26, select last note from track 2 (the upper one) get main window in front, click on split track tool click on track 2 separation between measures 26 and 27 -> got the segfault I've attached his backtrace and the file he was working on. I haven't managed to reproduce it myself but he's reproduced with 10.02 release, 10.04 release and the last 10.06 svn 11879. There's two other bugs and an enhancement request still open, if you have the time you can browse them at :- https://bugzilla.novell.com/buglist.cgi?bug_status=ASSIGNED&bug_status=REOPENED&assigned_to=dav...@gm... Thanks Dave P |
From: Chris C. <ca...@al...> - 2010-04-28 12:10:27
|
On Wed, Apr 28, 2010 at 10:52 AM, Dave Plater <dp...@we...> wrote: > I've attached his backtrace and the file he was working on. I haven't > managed to reproduce it myself I can't reproduce it either, I'm afraid. Nor does valgrind say anything is amiss (sometimes it can report on a problem even though there is no crash caused by it). Chris |
From: Dave P. <dp...@we...> - 2010-04-28 12:59:56
|
On 04/28/2010 02:10 PM, Chris Cannam wrote: > On Wed, Apr 28, 2010 at 10:52 AM, Dave Plater <dp...@we...> wrote: > >> I've attached his backtrace and the file he was working on. I haven't >> managed to reproduce it myself >> > I can't reproduce it either, I'm afraid. Nor does valgrind say > anything is amiss (sometimes it can report on a problem even though > there is no crash caused by it). > > > Chris > > I'll try and get Michel to narrow it down to more specific steps to reproduce. Dave P |
From: Dave P. <dp...@we...> - 2010-04-29 07:35:59
Attachments:
bug-599517_studio1.rg
bug-599517_unicornis.rg
|
On 04/28/2010 02:10 PM, Chris Cannam wrote: > On Wed, Apr 28, 2010 at 10:52 AM, Dave Plater <dp...@we...> wrote: > >> I've attached his backtrace and the file he was working on. I haven't >> managed to reproduce it myself >> > I can't reproduce it either, I'm afraid. Nor does valgrind say > anything is amiss (sometimes it can report on a problem even though > there is no crash caused by it). > > > Chris > > I've just found a new bug that wasn't assigned yet : http://bugzilla.novell.com/show_bug.cgi?id=599516 My system has slowed considerably after reproducing it and I'll most probably have to restart. Ater the " processAsynchronousEvents" and "Successfully opened document" messages the system slows to a halt and my hd led stays on, most probably because I have a new mother board with only one pata slot and a primitive pata drive. To reproduce, open attached bug-599517_unicornis.rg then import studio from bug-599517_studio.rg and at least my system survived but Michel reckons his firefox crashed from out of memory, mine survived, maybe because of gdb, and I got this message :- [sequencer] processMappedEvent: Have 66 events in async out queue RosegardenDocument::openDocument: Successfully opened document "/home/davepl/bugs/bug-599517_studio1.rg" [sequencer] processAsynchronousEvents: Have 66 events in async out queue ALSA Client information: 14,0 - (Midi Through, Midi Through Port-0) (DUPLEX) [ctype 2, ptype 655362, cap 99] [sequencer] client list changed ^C Program received signal SIGINT, Interrupt. 0x00007ffff3f84a40 in malloc () from /lib64/libc.so.6 (gdb) (gdb) c Continuing. Qt has caught an exception thrown from an event handler. Throwing exceptions from an event handler is not supported in Qt. You must reimplement QApplication::notify() and catch all exceptions there. terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Program received signal SIGABRT, Aborted. 0x00007ffff3f3f4e5 in raise () from /lib64/libc.so.6 (gdb) Continuing. [Thread 0x7fffe5679910 (LWP 14213) exited] Program terminated with signal SIGABRT, Aborted. The program no longer exists. (gdb) Michel is still using qt 4.5.3 but I'm on 4.6.2 atm so maybe that saved me from more catastrophe. Thanks Dave P |
From: Chris C. <ca...@al...> - 2010-04-29 08:08:03
|
On Thu, Apr 29, 2010 at 8:35 AM, Dave Plater <dp...@we...> wrote: > To reproduce, open attached bug-599517_unicornis.rg then import studio > from bug-599517_studio.rg and at least my system survived but Michel > reckons his firefox crashed from out of memory Fixed in rev 11885 -- thanks! Chris |