Thread: [Audacity-devel] Debug build crash
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Shane M. <smu...@um...> - 2002-03-25 17:09:13
|
As mentioned earlier, the toolbar code I checked in will compile on windows and linux, and will execute fine unless you are using the wxwindows libraries built with the debug checking. In that case an assertion fails when the first AudacityProject class is initiated, and the program crashes. I couldn't see any obvious bugs, so it may be something subtle that will take me a while to root out, or perhaps even wxwindows bug that may require a substantial workaround. The most obvious difference between the two versions of this class is that the new version contained a wxwindows array (created with the WX_DEFINE_ARRAY() macro). I won't have much time to fix this until later this week, so I tagged the toolbar snapshot as "ToolBar_Debug_Build_Broken" and re-committed older versions of the files that changed. CVS head should now work for debug builds--just without the new toolbar code. |
From: Brian G. <bm...@ya...> - 2002-03-25 18:41:48
|
The release is partially broken as well. That is why I ran the debugger in the first place. In the release build, Audacity crashes when I close it. --- Shane Mueller <smu...@um...> wrote: > As mentioned earlier, the toolbar code I checked in will compile on > windows and linux, and will execute fine unless you are using the > wxwindows libraries built with the debug checking. In that case an > assertion fails when the first AudacityProject class is initiated, > and > the program crashes. > > I couldn't see any obvious bugs, so it may be something subtle that > will > take me a while to root out, or perhaps even wxwindows bug that may > require a substantial workaround. The most obvious difference > between > the two versions of this class is that the new version contained a > wxwindows array (created with the WX_DEFINE_ARRAY() macro). I won't > have much time to fix this until later this week, so I tagged the > toolbar snapshot as "ToolBar_Debug_Build_Broken" and re-committed > older > versions of the files that changed. CVS head should now work for > debug > builds--just without the new toolbar code. > > > > _______________________________________________ > Audacity-devel mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ |
From: Dominic M. <do...@mi...> - 2002-03-27 07:59:13
|
I believe I found the problem. Since ControlToolBar and EditToolBar are dynamic classes, the parent class ToolBar needs to be a dynamic class as well. When I added DECLARE_DYNAMIC_CLASS(ToolBar) to ToolBar.h and IMPLEMENT_DYNAMIC_CLASS(ToolBar, wxWindow) to ToolBar.cpp, it seemed to work. Please try this and see if it works for you too. If so, I think you can go ahead and add the new ToolBar code back. - Dominic Shane Mueller wrote: > As mentioned earlier, the toolbar code I checked in will compile on > windows and linux, and will execute fine unless you are using the > wxwindows libraries built with the debug checking. In that case an > assertion fails when the first AudacityProject class is initiated, and > the program crashes. > > I couldn't see any obvious bugs, so it may be something subtle that will > take me a while to root out, or perhaps even wxwindows bug that may > require a substantial workaround. The most obvious difference between > the two versions of this class is that the new version contained a > wxwindows array (created with the WX_DEFINE_ARRAY() macro). I won't > have much time to fix this until later this week, so I tagged the > toolbar snapshot as "ToolBar_Debug_Build_Broken" and re-committed older > versions of the files that changed. CVS head should now work for debug > builds--just without the new toolbar code. > > > > _______________________________________________ > Audacity-devel mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Brian G. <bm...@ya...> - 2002-03-27 19:13:51
|
It works for me. After you get that fixed, I think I have found another bug. To duplicate, run in debugger, load both toolbars, leave the normal toolbar docked, and the edit toolbar undocked. Make sure the edit toolbar is over where the tracks would be displayed. Then click the X on Audacity's main window. Brian G. --- Dominic Mazzoni <do...@mi...> wrote: > I believe I found the problem. > > Since ControlToolBar and EditToolBar are dynamic classes, > the parent class ToolBar needs to be a dynamic class as well. > When I added DECLARE_DYNAMIC_CLASS(ToolBar) to ToolBar.h > and IMPLEMENT_DYNAMIC_CLASS(ToolBar, wxWindow) to ToolBar.cpp, > it seemed to work. > > Please try this and see if it works for you too. If so, > I think you can go ahead and add the new ToolBar code back. > > - Dominic > > Shane Mueller wrote: > > As mentioned earlier, the toolbar code I checked in will compile on > > windows and linux, and will execute fine unless you are using the > > wxwindows libraries built with the debug checking. In that case an > > assertion fails when the first AudacityProject class is initiated, > and > > the program crashes. > > > > I couldn't see any obvious bugs, so it may be something subtle that > will > > take me a while to root out, or perhaps even wxwindows bug that may > > require a substantial workaround. The most obvious difference > between > > the two versions of this class is that the new version contained a > > wxwindows array (created with the WX_DEFINE_ARRAY() macro). I > won't > > have much time to fix this until later this week, so I tagged the > > toolbar snapshot as "ToolBar_Debug_Build_Broken" and re-committed > older > > versions of the files that changed. CVS head should now work for > debug > > builds--just without the new toolbar code. > > > > > > > > _______________________________________________ > > Audacity-devel mailing list > > Aud...@li... > > https://lists.sourceforge.net/lists/listinfo/audacity-devel > > > > > > _______________________________________________ > Audacity-devel mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ |
From: Shane M. <smu...@um...> - 2002-03-27 22:04:24
|
I've (re)committed the toolbar code, thanks to Dominic's perceptive bug-finding. I've compiled in under both windows and linux with both the debug and non-debug wxwindows library, and it works *fairly well*. The funny part is that when I originally defined toolbar, I had it as a dynamic class, but took it out because it didn't appear to do anything. I have seen a several bugs, which I will enumerate here. I'll be tackling them in the next few weeks. Please let me know if you see anything else, or have ideas about these: 1. There may be something wrong in the dynamic array code that handles adding and deleting toolbars. The bug that Brian noted (crash on exit) may be a consequence of this, but I've also seen some assert failures I have seen in the windows debug build at other times. 2. The Edit toolbar works by executing functions associated with current menu items. I think this is a good policy in general, especially because some users will undoubtedly have accessibility problems and will not be able to use a mouse. But, some of zoom menu items that I hook on to don't work perfectly. (zoom in should stay centered on the center of the window, and zoom-fit is misaligned.) 3. I added a "Trim" function to the menu (and the edit toolbar). This could also be called "crop", as it is identical to graphical "crop"--it removes all of the file outside of the selection. I did this quickly, and have a suspicion that it leaks all of the memory it "trims", because it doesn't give the memory to the clipboard. Fit and Finish: 4. Under windows, when I drag a toolbar off the app, the bitmap that is produced "bleeds through" the previous bitmap--I see a ghost of the last toolbar dragged. This may depend on the color scheme and/or color depth rather than the platform, and may be present but undetectable in the "Palette" version as well. 5. The Windows (and presumably the mac) builds have several alignment issues where buttons are a pixel too high or too low, or a line is a little off. 6. Some of the button images are a little corny and unclear--these are probably the one's I created. The nice ones were obtained from Abe Milde, who is creating a more consistent and attractive set, so stay tuned. > _______________________________________________ > Audacity-devel mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel -- ==================================================== Shane Mueller East Hall 4424 (734) 647-3698 Cognition and Perception smu...@um... The University of Michigan http://www-personal.umich.edu/~smueller ==================================================== |
From: Dominic M. <do...@mi...> - 2002-03-27 22:27:50
|
Shane, Glad to hear it's fixed! If you didn't already, make the edit toolbar enabled by default. That will encourage me to debug it while I work on other things. > 3. I added a "Trim" function to the menu (and the edit toolbar). This > could also be called "crop", as it is identical to graphical > "crop"--it removes all of the file outside of the selection. I did > this quickly, and have a suspicion that it leaks all of the memory > it "trims", because it doesn't give the memory to the clipboard. If you use Track::Delete and call PushState at the end, then you're not leaking any memory. PushState makes it undo-able, and WaveTrack automatically reference-counts data so that it uses as little memory as possible, and doesn't leak. - Dominic |