This is more complicated than I first thought. Sometimes I can time shift multiple tracks and sometimes not. There must be a pattern but I can't see it yet. It seems to depend on which track is selected and which track I click in to do the shifting.

Testing on W10 with audacity-2.3.3-alpha-301-87a4a21becf1f7c1b8e82951f094bc18e0439c0f
Testing with 9 mono and one stereo track

I don't get a crash.

Sometimes I can move the tracks and sometimes I can't.

Sometimes I get the od behavior of the tracks moving but leaving the clocks patter behind - curable by maing a fresh selection

And Like Bill I can't detects a patter to reproduce this

I can reliably reproduce this crash in 2.3.2 and 2.3.1 for Mac, but not in 2.3.0, following these steps.

Generate noise.
Command+D three times.
Command+Shift+A to deselect all.
Command+Shift+F to fit all vertically.
Choose time shift tool.
Click and drag the bottom track.

I think the emptiness of the selection matters, but some other steps may be inessential.  No crash if I don't deselect all.

But now I find that I can't reproduce with these steps in either a debug or Release development build, even if I checkout at Audacity-2.3.2.

That's not good.  I need a stack trace before I can do any more.

My steps do not reproduce the crash on the 2.3.2 release for Windows

Created attachment 841 [details]
Portion of Mac crash report for time shift crash

This is a portion of the Mac crash report after following Paul's steps in comment #3.

Testing on W10 with audacity-2.3.3-alpha-303-960fe4741288884e19a2f6e114b78ae533454d3f

No crash on W10 when I follow Paul's steps in Comment 3 (addin a Step 0 of turning on Sync-Lock)

Fix for the bug as defined in the steps to reproduce:
https://github.com/audacity/audacity/commit/ee46155d828e71aa02cbe7f689619288cb78b9a8

I've marked it as devel-fix made, although it's possible that it doesn't fix all the variants of this bug given in the comments.

David,

I am not confident that this commit is good.  It may reintroduce other crashes.

Did you reproduce the crash reliably, and if so on which operating system?

You can see that you deleted this comment:
           // Beware relocation of array contents!  Bind trackClip again.

I wrote this code comment at commit b5a7b67cb713462250557e0d189a7e910853e1e3 which has this commit comment:

    Fix some crashes in time-shift

But you are effectively reverting this change of mine.

Do you not understand the danger of a dangling reference because of relation of std::vector contents after the vector is grown?  That is what I was intending to fix.

On the other hand I don't understand at all what was the detailed cause of a crash that
was introduced by my change, that you might have fixed by this reversion.

(In reply to David Bailes from comment #8)

(In reply to Paul L from comment #9)

Ah, I wrote hastily.  The difference is that you make a copy, not a reference, so you are not reintroducing the bugs I fixed long ago.

Still, I do not understand how this fixes a crash.  Please explain.

(In reply to Paul L from comment #10)

... could this perhaps be a compiler bug that only happens in the Mac build with certain levels of optimization?  Could it be that the repeated binding of a reference was wrongly hoisted by the compiler, negating the intention of my commit b5a7b67cb713462250557e0d189a7e910853e1e3 ?

(In reply to Paul L from comment #10)
> (In reply to Paul L from comment #9)
> 
> Ah, I wrote hastily.  The difference is that you make a copy, not a
> reference, so you are not reintroducing the bugs I fixed long ago.
> 
> Still, I do not understand how this fixes a crash.  Please explain.

In the loop:
for (auto t : TrackList::SyncLockGroup( trackClip.track ))
                  AddClipsToCaptured(state, t,
                        trackClip.clip->GetStartTime(),
                        trackClip.clip->GetEndTime() );

trackClip was becoming a dangling reference, because the vector was being grown in the call to AddClipsToCapured(). So the call trackClip.clip->GetStartTime() didn't end at all well.

On Windows 10 the bug was consistently reproducible.

Created attachment 843 [details]
Residula stranded clocks an Timeline selection

Testing on W10 with audacity-2.3.3-alpha-307-0bd1beae9a92c9753b04c160c0dd649ddd13939d

The multiple tracks move properly in sync moving a track (any track top/bottom/middle)

a) with all tracks selected

b) with no tracks selected

c) with one track selected - provided you time-shift the selected track

So bug, as stated, works on Windows - there is no crash


But there is a residual.

1) get multiple tracks
2) select just one of them
3) use the time shift tool over a non-selected track
4) Observe:  the clock icons and the Timeline "selection" remain where they previously.

This residual would be at most P3 - but I cannot reduce the riority until the main bug is tested on Mac & Linux

Easy workaround - just make another selection - bit id does look odd and iffy

(In reply to Peter Sampson from comment #13)
> Created attachment 843 [details]
> Residula stranded clocks an Timeline selection
> 
> Testing on W10 with
> audacity-2.3.3-alpha-307-0bd1beae9a92c9753b04c160c0dd649ddd13939d
> 
> The multiple tracks move properly in sync moving a track (any track
> top/bottom/middle)
> 
> a) with all tracks selected
> 
> b) with no tracks selected
> 
> c) with one track selected - provided you time-shift the selected track
> 
> So bug, as stated, works on Windows - there is no crash
> 
> 
> But there is a residual.
> 
> 1) get multiple tracks
> 2) select just one of them
> 3) use the time shift tool over a non-selected track
> 4) Observe:  the clock icons and the Timeline "selection" remain where they
> previously.

Isn't this is a separate bug, rather than a residual?

> 
> This residual would be at most P3 - but I cannot reduce the riority until
> the main bug is tested on Mac & Linux
> 
> Easy workaround - just make another selection - bit id does look odd and iffy

I have logged the residual reported in my Comment #13 (as David suggested) as new Bug #2181.

Accordingly I have marked this bug as tests OK on Windows

(In reply to David Bailes from comment #12)

It's obvious now.  I feel foolish.  Thank you for fixing my blunder.

Testing on macOS 10.14.5 Mojave with 2.3.3 Mac alpha jc005 of 01Aug19

No crash on Mac either 

But the residual Bug #2181 remains - but this bug as stated is fixed for Mac

No crash on Linux.