(In reply to comment #0)
Confirmed on Linux (Ununtu 10.10)

Thanks, Bill and Steve. Yes confirmed on Win 7 too. The only other condition I found is that the you must drag within the group that includes the label track. If you have: 

Audio Track 1
Audio Track 2
Label Track 1
Audio Track 3
Audio Track 4 
Label Track 2
Audio Track 5
Audio Track 6 

you can drag from track 6 to any track, or from track 2 to any track except 1, and from track 1 to any track except 2 (but only if you drag really rapidly). 

It's a regression on 1.3.8 and 1.3.9 (the last two Betas where we had "linking" on) so does seem a P2. But not hard to work round.

Believed fixed in r11110.

I noticed some other track oddities when dragging around stereo tracks with sync on.  This may be noted in another bug, as these are not regressions.  Tried to fix them but initial attempts failed, and I thought it is better to focus on other P2s for now.

(In reply to comment #3)
R11113 on Ubuntu 10.10

The issue is considerably improved, but unfortunately not fully fixed.

Create 4 empty mono tracks
Put audio clips into the bottom two tracks, so that the audio clips overlap.
Enable Sync-lock
Drag the clip in track number 3 up to track number 1.
Audacity crashes.

Ok, I fixed this case an a couple more in r11114.
Thanks for the good testing.
For testing this time please focus also on sync-lock off with mixes of stereo and mono.

Reviewing the code has led me to think the shift tool code really needs a rewrite for sync locked tracks (TrackPanel::MoveClipToTrack/DoSlide/StartSlide), which currently only handles up to two tracks, which is not at all the case with sync-lock, causing funny behavior.  I don't see a bug for this, and I don't know if this is P2 or not.  Please let me know if I missed it.

(In reply to comment #4)
With 1.3.14-alpha April 18 Mac nightly, which should include r11114. With initialized cfg.
Tried Steve's setup. Sync-lock on.
1) If I drag the clip from track 3, I cannot drag it into track 2, only track 1. The clip from track 4 comes with it (that is, moves onto track 2).
2) If I try to drag the clip from track 4 onto another track, it can't be done.

Now add one more empty mono audio track below the others.
- Now I can drag the clip from track 4 onto track 1 but nowhere else. The clip from track 3 does not come with it.
I can still drag the clip from track 3 only onto track 1, and the clip from track 4 still comes with it.

Add another empty mono audio track below the others.
- Now I can drag the clip from track 4 onto tracks 1 and 5 but nowhere else.
- And I can drag the clip from track 3 onto tracks 1 and 5, and the clip from track 4 still comes with it.

No crashes so far.

Reset to Steve's setup and add a label track at the bottom.
- Now I can drag the clip from track 3 onto tracks 2 or 1, and the clip on track 4 does not come with it.
- I can also drag the clip from track 4 onto tracks 2 or 1.

Now for a mix of stereo and mono tracks:
- New Project
- Mono track with clip (1)
- Stereo track with clip (2)
- Mono track without clip (3)
- Stereo track without clip (4)
- Sync-lock off

Dragging the mono clip from track 1 to track 3 there is no apparent problem.

When attempting to drag the stereo clip from track 2 into track 4 it "splits itself" between tracks 3 and 4 - the left-channel half the original stereo clip goes into mono track 3 and the right-channel half goes into the left channel of stereo track 4. You cannot drag it fully into stereo track 4.
In the original drag from track 2, if you grab the stereo clip on the left channel, before you let go you can drag it back onto track 2 after it splits between tracks 3 and 4.
If you begin the drag of the stereo clip by grabbing the right channel, before you let go you can not drag it back onto track 2 after it splits between tracks 3 and 4. But you can Undo.

Letting go and dragging that clip again, it is now two separate clips.
- the "new" mono clip on track 3 can be dragged onto track 1 and nowhere else.
- the "new" left-channel-only clip on track 4 (which originated on the right channel of track 2!) can be dragged onto the left channel of track 2 and nowhere else.

Close project, open new project and set up the mix of mono and stereo tracks as above. Turn Sync-lock on.

Dragging the mono clip from track 1 to track 3 there is no apparent problem.

When attempting to drag the stereo clip from track 2 into track 4:
1) If you drag in the right channel, it can't be done
2) If you drag in the left channel, the left channel only moves onto track 4 - the right channel remains on track 2.
3) You can drag that new left-channel-only clip from track 4 back onto track 2 and "marry it up" with it's old right channel!
4) Instead, turn sync-lock off and drag the new left-channel-only clip from track 4 back into the left channel of track 2 but offset it from it's original location - let go. Drag the new (offset) clip in track 2 - it drags as a stereo clip.

Undo any drags between tracks and add a label track at the bottom.
- The behaviour does not change.

That's enough for now. Let me know if there are any other permutations you like me to try.

Hi Bill.  What I meant by my comment is that there are many broken things about sync-lock.
My fix simply stops the bleeding by fixing the bug as titled here (crashing issues) and not addressing the functional issues.  The functional issues will take much more time to fix and basically requires a rewrite of the code.

If QA determines this is P2 I will work on it, but note that there was some -quality discussion a while ago that we shouldn't work on this over other bugs.  If this is the case please open a new bug so it can have it's own priority.

(In reply to comment #7)
Testing with R11115 on Ubuntu 10.10

There are certainly some very "wrong" behaviours occurring when dragging clips vertically, both with and without Sync-lock enabled, but Audacity is no longer crashing as a result so unless there's crashing observed on other platforms I think this bug can be closed.

(I'll raise a new bug report for the other issues).

Great.  Also I made these comments on the premise that the fixes don't regress on previous 'good behavior'.  From my testing I think this to be the case but please note if otherwise in the new bug.

(In reply to comment #9)
I'd like to test a bit more than I've had time to in order to determine there really are no crashes as per the bug title, but I haven't found any yet (with Sync-Lock on or off).  

I too (only tested on Windows so far) have found lots of disfunctional vertical dragging with multiple tracks (mostly with Sync-Lock on). Thanks Steve for creating bug 373 for it. I'll comment there about its rating and other related issues.

I've tried various other scenarios on Windows and Linux with Sync-Lock on or off including moving label tracks up and down, joining clips and dragging those, cutting and pasting instead, and all seems OK so RESOLVED - FIXED for crashes. Thanks, Michael.

REOPENED, because reproducible as per steps to reproduce in 2.0.2rc3. 

1.3.14 release does not have the issue, but 2.0.0 release does.

Steps: 

* Initialized .cfg is irrelevant.
* Bulletized points for readability. 


Committed failsafe against crash in r11929. Should lower this bug's priority.

(In reply to comment #13)

>Committed failsafe against crash in r11929. Should lower this bug's priority.

Actually, turns out that NULL clips are intentionally added to TrackPanel::mCapturedClipArray, so any time they're to be dereferenced, that has to be checked. The former code just neglected that. 

So rather than lower the priority, the code in r11929 was the solution, so DEVEL - FIX MADE. ;-)

(In reply to comment #14)
Tested with 2.0.2rc4 on Mac 10.7.4 and crashes do not occur.

RESOLVED - FIXED. Tested on Windows and Linux (and a little bit on Mac as well as Bill). Can't make it crash with any combination of mono or stereo clips, dragging with/without sync-lock, with/without other track types, in or not in selections etc.