Re: [Audacity-quality] Whitebox testing/analysis

[Peter S. <pet...@gm...>]

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
>