#  MJS: There appear to be no recent reports of this bug, and no repeatable evidence. I suggest this is demoted to a 'watching issue'.
# GA: Initialise blockStatus in Sequence.cpp (8Nov09) and possibly fix for spurious clips at the track end after Change Speed (4Nov09) may have helped some cases, but still reports from one user 5 and 11 Nov09 of clicking to right of a zoomed in selection near the end of a project causing a crash. NB the act of zooming itself does not usually cause a problem. Further changes by AWD 19Nov09 to WaveTrack::ClearAndPaste() to help eliminate zero-length clip creation in ChangeSpeed and similar also noted.
# MJS 23 Nov 09: the thread at http://n2.nabble.com/Various-P2s-and-P3s-a-repeatable-case-td4040974.html gives some insight. This appears to be fixed although Gale has not confirmed that the test cases replicates the original problem. Since it is a 'moon phase' bug he can't really do that, but I have provided a good case, and Al has addressed the issues, so I think this is fixed.

This one is a pain to get to grips with, but I do get a sense most of it can now be summarised as "clicking around fast or repeatedly", not just when zoomed in, not just at the end of a track, not just when running effects. Basically 27 people reporting since 1 April 2010 (including me) on all flavours of Windows. Noise Removal (clicking OK to grab Noise Profile - 4 people) and Amplify (5 people) is mentioned as crashing, possibly if you click clumsily/fast as in a double click. Seven people mention just clicking in a track with Selection Tool. This is pretty much what I experience - a kind of "tightness" like the cursor isn't being placed fast enough, then the program crashes out. 

Also like a lot of these people, I just can't make 1.2.6 do it however fast/aggressive I become.   

Also tagging on here for now 7 reports since 1 April 2010 in OS X 10.4.x (Intel and PPC) and 10.6.x. Clicking in the waveform to select track (5 users) or in file export window directory tree (2 users) causes crashes from time to time. Plus one further OS X crash which I told Michael about:

User:
> >> First, I selected 12 .wav files in the finder, and opened them with
> >> Command-O (into Audacity). After they loaded, I began listening to
> >> them and repairing pops and clicks. After completing the sixth file
> >> with no problems, I closed it, and after the file closed, Audacity
> >> vanished instantly.

Michael:
> I think this may be related to threading - On a different project
> Ilearned that pthreads have strange behavior when dealing with
> pthreads until you initialize the first NSThread in cocoa.  I'll try
> to find out more.  Paul, have you seen any of this behavior on 10.6?

Created attachment 25 [details]
call stack from occurrence of this bug

Call stack from occurrence of this bug. Unfortunately, the text in the dialog cannot be copied.

Did some testing on this and was able to make it happen after lots of fast clicking around, by double-clicking Preview in Amplify dialog. 

The key seems to be the call to wxYield. That function is obsolete, but looking at the documentation for its successor, wxApp::Yield(): 

"Caution should be exercised, however, since yielding may allow the user to perform actions which are not compatible with the current task. Disabling menu items or whole menus during processing can avoid unwanted reentrance of code: see ::wxSafeYield for a better function."

That sounds like exactly the situations where this has occurred. And the documentation for ::wxSafeYieldsays: 

"This function is similar to wxYield, except that it disables the user input to all program windows before calling wxYield and re-enables it again afterwards."

Sounds like what we need. So I went through the code and for all the wxYield and wxGetApp()::Yield occurrences where Audacity is doing some drawing or already in the process of responding to a GUI event, I replaced them with ::wxSafeYield. Replaced all the remaining wxYield calls with calls to wxGetApp()::Yield().

Haven't been able to replicate the bug since these changes. Please test.

(In reply to comment #4)
Seems to have made a big improvement for me and other Windows users who crashed so frequently with this. Clicking "feels" much more robust and responsive now when you click around, rather than as if it's going to crash any time when you click too fast or impatiently.  

I ran at about 5 times smaller blocksize than normal and edited an hour long On-Demand WAV  doing many of the things over about 20 minutes that would have crashed sooner or later:

* triple clicking buttons in effects
* clicking or dragging in the waveform, seeing no cursor/region appear at once and clicking again
* clicking too soon while waiting for the window redraw after applying an effect (this wait is really infuriating when you apply effects continually but at least it doesn't seem to crash now)

Repeated with non-aliased data - still OK. 

Repeated the above tests in 1.3.12 Unicode Release and it crashed less than a minute after starting editing and playing.

Have only been able to get a response from a couple of the Mac people who crashed clicking in file windows or the track, but both have gone longer now in terms of hours without a crash then they usually do. 

So calling this fixed and retiring the Mac crash closing a track as a one-off (not frequent enough to explicitly list just now). I don't think it's the subject problem.