Re: [Audacity-quality] Whitebox testing/analysis
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
|
From: Peter S. <pet...@gm...> - 2021-01-19 10:31:28
|
Hi James, Is there any progress (or results) to report on the "Whitebox testing/analysis" ? *Oh - and thanks to Paul for his useful insights here.* Peter. On Thu, Jan 14, 2021 at 5:25 PM Paul Licameli <pau...@gm...> wrote: > But there are also sometimes good reasons to stop propagation of > exceptions to that handler, with GuardedCall or otherwise with catch > blocks. So those are places deserving some white-box attention. > > PRL > > > On Thu, Jan 14, 2021 at 12:18 PM Paul Licameli <pau...@gm...> > wrote: > >> The function AudacityApp::OnExceptionInMainLoop() has long (since 2.2.0) >> been responsible for restoring the consistency of the project in-memory, >> after catching exceptions thrown for whatever reason. >> >> More specifically it is the call to ProjectHistory::RollbackState that >> accomplishes most of that. So it now depends on the last pushed Undo state >> being consistent with the last committed state of the database. >> >> PRL >> >> >> On Thu, Jan 14, 2021 at 11:34 AM James Crook <jam...@gm...> >> wrote: >> >>> aup3 format is a major rewrite of a core part of Audacity. >>> >>> When SQLite throws an error, the files on disk should always be in a >>> consistent state. That much is the integrity guarantee we expect for >>> SQLite. At worst we will have lost 'one transaction'. >>> >>> There is a problem though. After an error Audacity's view of the data >>> may no longer match what is on disk. At that point it is dangerous to >>> continue working with the project. >>> >>> The problems that could arise cannot be adequately tested by just trial >>> and error. We need to do a formal analysis of the source code, a >>> 'whitebox' test. >>> >>> I am proposing that we do this analysis in a systematic way. We add >>> (paired) comments into the code for every SQL transaction to show how/why >>> 'Audacity's view' of the data is either still in sync, or else further >>> editing has been disabled. >>> >>> I don't know exactly how to do this analysis until we've got some way >>> into it, and I don't know exactly how long it will take. We have no >>> current P1s, so now is the right time to do it. It's gating for going into >>> string freeze, because we may need new error strings to handle 'editing >>> disallowed'. >>> >>> Hopefully once it's done, we can review P2s, and go into string freeze. >>> I'm hoping string freeze by this time next week, but am not updating the >>> official schedule until we've a better sense of how long the whitebox >>> testing/analysis and consequential fixes is going to take to do. >>> >>> --James. >>> _______________________________________________ >>> Audacity-quality mailing list >>> Aud...@li... >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >>> >> _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality > |