Crash on 'Fit to Height' - repeatable

Audacity Help Forum Windows
1

I am using Audacity 2.4.2 on Windows 10.

I was working on a project, and had spent 10 mins or so just doing splits, split cuts and time shifts of clips, to time-align two of the tracks.

In case it’s relevant, I had the two tracks I had been working on set to dB scale rather than Linear.

Then I did a ‘Fit to Width’, which worked fine, followed by a ‘Fit to Height’, which caused it to crash.

There are 34 audio tracks and one label track in this project. The project length is 6mins 35s.

Upon restarting Audacity, I got the message saying that the project was recoverable, but on clicking ‘Recover’ it failed to do so and crashed again before I had done anything else - it didn’t get as far as seeing the tracks appear.

This crash (and the failure to recover) is now completely repeatable on this project. It happens regardless of whether I use the menu bar command or Ctrl-Shift-F. On a non-recovered (i.e. earlier) version of the same project, I only need to open the project and do a ‘Fit to Height’ and the crash is immediate, every time. I have tried doing several things prior to ‘Fit to Height’ (e.g. playback) and they all work fine. But as soon as I then do a ‘Fit to Height’, it crashes.

The only exception is that if ‘Fit to Height’ is immediately preceded by doing ‘Collapse All Tracks’, then the crash doesn’t occur (maybe because there is then nothing for ‘Fit to Height’ to do?)

Since nothing further can be done after a ‘Fit to Height’, I don’t know how to how to create and capture a diagnostic report of the crash details, since this seems to need a menu operation in Help->Diagnostics. But maybe I don’t understand or there is another way?

I have worked on about 25 Audacity projects previously over the last year (with 2.4.2 and other recent previous versions) and never had this happen before. I have used ‘Fit to Height’ before OK on those projects - but not used it very often.

I haven’t been doing anything unusual in the project that shows this problem - but it is my first project that has had as many as 35 tracks. Maybe the biggest previous one was around 20-25 tracks.

I have tried creating a test project with the same number of tracks (each containing just a tone) but I can’t make that project crash when using ‘Fit to Height’.

I’m very happy to try more tests to assist with fixing this, or to capture diagnostics if I’m told how to do that.

Many thanks.

2

When it crashes, does it show a crash dialog window, or does it just disappear?

If you attach the project’s “.aup” file to your reply, I’ll take a look to see if I can see anything wrong in there.
(see here for how to attach a file to a forum post: https://forum.audacityteam.org/t/how-to-attach-files-to-forum-posts/24026/1)

3

I have just tried similar on my W10 PC with 2.4.2 - and I can’t make it crash either.

Peter.

4

Thanks for the replies so far.

When it crashes it just dies - no crash dialogue window. The first obvious symptom is that the ‘Fit to Height’ action doesn’t happen - nothing at all appears to change.

Then I notice that, as I move the mouse pointer around, it doesn’t change between the different types of ‘pointer’ as it should.

Then, if I try to do anything, I get a ‘(Not Responding)’ in the Windows title bar, and the mouse pointer is now the standard small blue rotating circle showing ‘Windows busy’ (or something like that). Also the content of the program window is ‘dimmed’ (reduced contrast).

Then, if I try to close the program using the X at top right of the title bar, it says do I want to close the program immediately or wait for it to finish. As I’ve already waited at long while with no change, I ‘close it immediately’.

A .aup file is attached as requested.

I hope this info helps.
Lovely Day_3a.aup (297 KB)

5

In case it’s relevant, I should also have mentioned that though most of the tracks are mono, about 6 or so of them are stereo. It was mono tracks that I had been working on. No time-related editing had been done on the stereo tracks - they were just mixes of the other tracks.

6

So Audacity “freezes” rather than “crashes”?


The only odd thing that I notice about the project is that the file name is “Lovely Day_3a.aup”, but the data folder is “Lovely Day_3_data”. I would have expected the file name to be “Lovely Day_3.aup”.

7

Very sorry, I don’t understand the exact technical difference between a ‘crash’ and a ‘freeze’. It simply stops working at that point, and nothing further can be done. So yes, it is ‘frozen’ - but apparently permanently so, at that point.

The reason that for the ‘a’ on the end of the .aup name is because of the the re-naming that I have been doing as part of the many tests done after the initial freeze, because of the failure to be able to successfully recover. In fact I now have several different copies, with different appended letters. Of course, whenever I have renamed the .aup file, I have also renamed the corresponding data folder in the exact same way - and both renames were done only without Audacity running at the time. So, initially, before the very first freeze, both the .aup file and the data folder were indeed without any suffix letter.

8

If you manually rename a “.aup” file, it will still look for its audio data in the original “_data” folder.

This is the first part of your “Lovely Day_3a.aup” file
(I’ve highlighted the relevant part)

<?xml version="1.0" standalone="no" ?> http://audacity.sourceforge.net/xml/audacityproject-1.3.0.dtd> " >

projname=“Lovely Day_3_data” > version=“1.3.0” audacityversion=“2.4.2” sel0=“194.0024954266” sel1=“194.3629716171” vpos=“3424” h=“190.9896222273” zoom=“205.1368003303” rate=“44100.0” snapto=“off” selectionformat=“hh:mm:ss + milliseconds” frequencyformat=“kHz” bandwidthformat=“semitones + cents”>

Notice that it is getting the audio data from “Lovely Day_3_data”.

To rename a project so that both the “.aup” file and the “_data” folder have the new name:
“File menu > Save Project > Save Project As…”

9

Many thanks for that. Just to clarify, I’m not trying to open the renamed project copies. I have renamed the .aup and the folder just to park them out of the way, but still keep them associated by name. However, I appreciate that this isn’t good practice - it’s not something I have routinely been doing with projects, but only part of investigating this freeze. I do understand the usual and proper way to save a renamed copy of a project, but thanks for the reminder.

But as a check of what you said, I tried opening the ‘a’-suffixed one (by double-clicking on it), and it opens fine, even though there is no longer a data folder present with the un-suffixed name indicated by ‘projname’.

Furthermore, I then, with Audacity not running, temporarily changed the name of the ‘a’-suffixed data folder to something completely different, and then double-clicked the suffixed .aup file again. This time it failed to open, with a message saying ‘Error Opening Project. Couldn’t find the project data folder: “Lovely Day_3a_data”’. This appears to show that, for me, it’s usually finding and using OK the data file indicated by the .aup filename, not the one identified by ‘projname’.

So maybe the default (and usually intended behaviour) is what you said, i.e. it uses ‘projname’ in the normal case, but in the absence of a data file identified by ‘projname’ it maybe then looks for one with the same name as the .aup and opens that instead? (But, in that case, I would have expected a warning message about that.) I haven’t done any further tests to investigate.

Anyway, this is very interesting and useful info to know about, so thank you for that, but unfortunately it doesn’t relate at all to the freeze problem I’m having with this project.

10

One possibility is that there may be corruption in one of the tracks.
You could test this hypothesis by deleting one track (click the [X] in the upper left corner of the track), then see if it crashes. Repeat for each track.

11

OK, thanks.

I tried that and eventually I got to a point where the freeze no longer happened, but on further investigation I found that it wasn’t the specific last track deleted that made the difference. Deleting any one of several of them would fix it. So it didn’t seem to be audio corruption. Furthermore, I found that whether or not I got the freeze depended on the height of the Audacity window.

I have now replicated the problem in my test project, which removes a lot of possible factors:

  • there is no audio (all tracks are empty)
  • there are now only 12 tracks
  • there are no label tracks
  • there are no stereo tracks

To get the problem, you have to have the track sizes set in a very specific way. All are in collapsed state except the 3rd and 4th, and those two are opened up just a little. Then the window has to be insufficiently high for them all to fit in, after (a successful) ‘Fit to Height’.

I have attached screenshots of two cases of window height. If I load the project and set the window to the larger height (Capture_1), then ‘Fit to Height’ works fine. But if I load load the project and set the window to the smaller height (Capture_2), then ‘Fit to Height’ causes the freeze.

I have also attached the .aup file for this test.

Hopefully this information will enable you to reproduce the problem. Please note that to be sure of getting the freeze, all the tracks must each be set and sized exactly as shown as in the Capture_1 screenshot, and the window height must be set as shown as in Capture_2 (or less high).

Many thanks.
test_5.aup (4.38 KB)
Capture_2.JPG
Capture_1.JPG

12

Thanks for the detailed steps.

I’ve tested on my usual computer (Linux) and the problem does not occur.
I’ll test on Win 10 later (when I get access to a Win 10 PC).

13

Just a thought - could you check to see if the position of the mouse pointer is relevant. Try clicking on different parts of the interface prior to resizing.

14

Thanks for what you have done so far, and for the suggestion.

I have just tried doing the Ctrl-Shift-F with the mouse pointer in various positions (after having clicked there, as you requested) and this seems to make no difference. Whatever form the mouse pointer takes at that location, it then freezes in that form until the program is closed. Also, if the click caused a drop-down selection list to appear, that then stays in place even after moving the moving the mouse pointer elsewhere. Also, if the mouse position caused a pop-up ‘help’ box to appear (e.g. ‘Stop’ over the Stop button) then that help box remains until the program is closed, even after moving the mouse pointer elsewhere.

I wondered if it might be configuration file dependent? So I have now attached my .cfg file.
audacity.cfg (9.22 KB)

15

Useful information. I think that rules out one possibility.


If you delete (or move) the audacity.cfg file and then launch Audacity, a new audacity.cfg file will be created with default settings.

There’s also two other configuration files (in the same location as audacity.cfg) - “pluginregistry.cfg” and “pluginsettings.cfg”. You could try temporarily removing those too. With all three .cfg files moved out of the way (move them when Audacity is closed), Audacity will launch with pristine factory settings.

16

I can reproduce the freeze on Windows 10!

This is definitely a bug.

17

I have an idea of what may be causing it, and it may already have been fixed in the current development version.
(Testing may take a while)

18

OK, that’s good - very glad to hear of your progress. So I guess I don’t need to do any more tests just now?

Many thanks for your help.

19

It’s not what I thought, but it does appear to have been fixed quite a while ago during the current release cycle. I can reproduce the problem 100% with Audacity 2.4.2, but I’ve gone back through multiple alpha versions and I can’t reproduce the problem in any of them.

As far as I can tell, the problem is fixed in the current development version, so it shouldn’t be a problem in the next release version.

Thank you for your investigations and detailed steps. Having a reliable way to reproduce the issue gives me a lot more confidence that it actually is fixed.