Bugzilla – Bug 1510
Crash cancelling Save As... character replacement dialogue when exporting multiple on stereo tracks
Last modified: 2018-08-20 11:45:44 UTC
Created attachment 706 [details] stack trace on Mac Occurs on Windows, Mac and Linux.
I'm following the steps on Windows 10 using a track name of bad/. No crash for me. What could I be missing? Could you give the stack trace on Windows?
(In reply to James Crook from comment #1) I can't reproduce it now on HEAD on any platform, nor in r43b4d3c-2.1.3-alpha-08-sep-16.zip on Windows where I could reproduce it easily yesterday. I had a fresh audacity.cfg and just ? as the bad track name on Windows, but that does not help me reproduce it now. It happened seven times out of seven yesterday on the various platforms. It was the same stack trace every time on Mac. It isn't anything to do with saving it as a project or not. I demoted it to P3 and marked it Moonphase and requiring more investigation.
Created attachment 707 [details] autosave file and temp project to attempt reproduction of crash I've attached a recovered project which was created by recording a couple of seconds, Stop, name the track as ? , record a couple of seconds, Stop, name the track as ?. It always crashes on Windows 10 if I Export Multiple, Cancel or ESC the first Save As dialogue, then Cancel or ESC the second Save As dialogue. Running a debug build of Audacity HEAD inside VS 2013 I got the below using "Local Windows Debugger". I can't guarantee I'm doing it right so feel free to send me baby steps off list if you wish. Unhandled exception at 0x0115935B in audacity.exe: 0xC000041D: An unhandled exception was encountered during a user callback. C:\wxWidgets-3.0.2\include\wx/dynarray.h(838): assert "uiIndex < m_nCount" failed in wxBaseArrayPtrVoid::Item(). Call Stack: [00] wxFileType::SetCommand [01] wxFileType::SetCommand [02] ExportKitArray::operator[] c:\git master\audacity\src\export\exportmultiple.h:210 [03] ExportMultiple::ExportMultipleByTrack c:\git master\audacity\src\export\exportmultiple.cpp:890 [04] ExportMultiple::OnExport c:\git master\audacity\src\export\exportmultiple.cpp:569 [05] wxFileType::SetCommand [06] wxFileType::SetCommand [07] wxFileType::SetCommand [08] wxFileType::SetCommand [09] wxFileType::SetCommand [10] wxFileType::SetCommand [11] wxFileType::SetCommand [12] wxFileType::SetCommand [13] wxArrayPages::wxArrayPages [14] wxFileType::SetCommand [15] wxFileType::SetCommand [16] wxArrayPages::wxArrayPages [17] wxArrayPages::wxArrayPages [18] wxArrayPages::wxArrayPages [19] wxArrayPages::wxArrayPages [20] wxArrayPages::wxArrayPages
DEVEL - FIXMADE https://github.com/audacity/audacity/commit/796b98de8b84255592d0d165ebd10ae86d919b3c The key point was RECORDING rather than generate DTMF. That led to stereo tracks which in turn made this bug repeatable. This bug was caused by the 'fix' for 1440. Bug 1440 will need retest with mix of mono, stereo and label tracks because of this commit, with some tracks not at time zero to check that the time setting for export is being applied to the right track(s).
(In reply to James Crook from comment #4) > The key point was RECORDING rather than generate DTMF Although on the day I got the crashes I was mostly recording stereo snippets for test, I deliberately changed to tones for some tests on Linux and still got the crashes. So I did not think mono or stereo was relevant. Might I have created some instability and needed to restart Audacity to verify properly if mono would not crash? If not, there must still be some moonphase issue in there as well as the repeatable issue.
The bug I fixed would (I believe) only affect stereo. With a release build Audacity might survive the issue and cause instability (for that run). With a debug build it would have crashed at the time trying to access out of range in an array. I suggest you mark this back as moonphase again, if you can get it to crash even once again. I prefer crashes on Windows as they are easier to diagnose - so it is relevant to me what platforms the moonphase bug has been seen on. The repeatable bug was of course all platforms.
(In reply to James Crook from comment #6) I have changed this bug back to a repeatable bug for the stereo tracks case so if/when I crash on Linux with mono tracks I will open a new bug for it. Audacity release build did crash every time on stereo tracks. What I meant by asking if I should have restarted Audacity was that after restart and recovery, I deleted the stereo tracks, generated mono tracks, named them with an illegal character then export multiple, cancelled Save As..., then crash.
A bad recovery could put Audacity in a bad state, but that would be yet another bug. Audacity should say "can't recover" if there is a problem in recovery. Possibly creating and removing stereo tracks and then saving mono tracks was something that would have caused a repeatable issue. I wouldn't expect that, as I would expected deleted tracks to genuinely be gone from the list of tracks, not just hiding as ghost tracks ready to come back with an undo. Undo should be recreating them as tracks. Suggest trying adding 2 stereo tracks and removing them, and then trying with mono badly named (before my fix) if you want to see if that was the possible cause.
(In reply to James Crook from comment #8) I had already tested in your fixed code the obvious case of creating illegally-named stereo tracks, doing export multiple, then removing the stereo tracks, generating mono tracks and illegal-naming those. Sometime I will try the same but with the source of the stereo tracks being the attached autosave file and temp folder.
