Re: [Audacity-quality] Repeatable crash set format to 16-bit on read directly 32-bit float WAV

[Vaughan J. <va...@au...>]

On 2/28/2012 4:37 PM, Martyn Shaw wrote:
> 
> 
> On 28/02/2012 23:33, Vaughan Johnson wrote:
>> On 2/28/2012 1:46 PM, ga...@au... wrote:
>>>
>>> Using audacity-win-2.0rc4 on Win 7 x64 but occurs in 1.3.14 too.
>>>
>>> 1. Import a 32-bit float, 22050 Hz mono WAV choosing "Read Directly".
>>> 2. From Track Drop-Down menu, choose "Set Sample Format">
>>>      16-bit PCM.
>>> 3 Crash.
>>>
>>> To create the WAV I generated 11 seconds of white noise but
>>> probably anything would do.
>>>
>>> No crash if you copy in the WAV.
>>>
>>> Seen one other report of similar but could not get details from
>>> user.
>>>
>>> P1?
>>
>> That's the law. Glad you found it. Infrequent as it might be, it's
>> definitely a bug in Audacity code.
> 
> ****, ******, **** ******, **** ****** ****** (expletives deleted).

For sure.


> 
>> I'm looking at the bug. Thanks, Bill, for confirming it and for your
>> stack info. Happens at the same place on Windows. The first block in
>> that loop has a null file pointer, that gets dereferenced, ergo crash.
>> It's easy enough to trap that and prevent the crash, and I'll do that,
>> because Sequence::ConsistencyCheck() should not crash, it should report
>> the problem. I think the real problem is in
>> Sequence::ConvertToSampleFormat(), before it calls
> 
> I see that you have a number of comments in there already.  

Indeed. Some of that code is from 2002-2005!   :-)


>I'm afraid
> that I can't help with that today.

...but you have!


> 
>> Sequence::ConsistencyCheck(). It's unfortunate this code has been so
>> problematic. It's in the same area as bug 451. I think we *could* apply
>> the same reasoning as there when I've trapped the crash(es), i.e., it
>> could at least be demoted from P1. But I'll let you know what happens to
>> the audio when I've made it crash-safe.

Following from my other message on this thread, I think I've fixed the
main bug in Sequence::ConvertToSampleFormat() (which was not checking
whether the blockfile is aliased), and committed the fix.

It's past the mac nightly build time, but it's a cross-platform bug, so
please go ahead and test win and *nix.


>>
>>
>> Unnerving that a P1 comes up a day before planned release. We now need
>> another round of RC's, so we are definitely postponing release, even if
>> I can get the bug fixed before nightly build for Mac.
> 
> OK with me.
> 
>> Plus, I'm behind on preparing the website changes. Sorry I messed up the
>> Download page. Gale, if you want to revert that and push it to the site,
>> that's fine.
> 
> We are in a unique situation here - a 2.0 release.  Things were almost
> bound to take more time.

Thanks. Focusing on the app!


> 
>> As RM, I say we go on the 48-hour cycle, as in
>> http://wiki.audacityteam.org/wiki/Release_Process#Process step 7, until
>> we have a 48-hour cycle with no P1 or P2. We don't want to have daily
>> RC's -- too much overhead.
> 
> OK.
> 
>>[...]
>> I'm certain I can get the crashes trapped and that code committed in
>> time for the Mac nightly. Then we can test like crazy (continuing that
>> today, too!), discuss, and if okay, set the next RC's for 21:00 GMT Feb
>> 29, to start the 48-hour cycle.
> 
> But not at the expense of your (or anybody else's) health!

Definitely!

- V