Aha. Yes that's exactly what happens. Thanks!
In the test in ReplaceBlockFiles we tested for
if( hash[blocks[i]->f] )
Which added the NULL item. I've changed over to
if( hash.count( blocks[i]->f) >0 )
(although count only returns 0 or 1), and that prevents the redundant
items being added in the first place. Will check this into CVS in due
course, probably by Tuesday.
--James.
Dominic Mazzoni wrote:
> Sorry about your lost work, that's my fault.
>
> Is it possible that calling !blockFileHash[f] when f is not in the
> hash table, actually inserts f into the hash table with a value of
> NULL? If so, that's the cause of the problem and your fix is
> correct. Could you verify this?
>
> - Dominic
> On Aug 25, 2006, at 4:54 PM, James Crook wrote:
>> Having just lost 2 hours of editing work with a recent Audacity CVS
>> head, I've now got a short repeatable scenario and possible
>> explanation
>> for the problem.
>> Steps:
>> Import about a minute of wav audio.
>> Create a new audio track.
>> Select the first ten seconds and use edit->Split. Drag on to the
>> second
>> track.
>> Now do file->CheckDependencies and choose
>> Copy-Selected-Audio to Project.
>> In Dependencies.cpp, towards the end of function RemoveDependencies,
>> there is a call to dirManager->Deref(f). f can become a NULL pointer
>> and this causes an exception in Deref.
>> I think the non NULL f's correspond to pcmaliasblockfiles, whilst the
>> NULL ones correspond to simpleblockfiles - this is a guess based on
>> the
>> count of each kind. The problem 'goes away' if I just add a test for
>> NULL f before calling Deref. However, I don't actually understand why
>> there should be NULL entries in the hash at all. I'd have expected
>> there to be no reason for them to be put in in the first place.
>> So, anyone know this code well enough to propose the correct fix?
>> ---
>>
>> Rider: With the original crash, when I next ran Audacity it told me:
>> "Fortunately the following projects can be automatically recovered"
>> Well, there was a full and complete autosave file in the Audacity
>> AutoSave directory, but when I continued with recovery, audacity then
>> showed a dialog 'Error Opening Project'. "Couldn't find the project
>> data folder: 'wombat_data'" (wombat being the name I was saving the
>> project as). In the original scenario it was save project calling
>> CheckDependencies that caused the problem....
>> --James.
|
