Discussion:
[Audacity-devel] Branch bug1567-tidy
Paul Licameli
2017-01-22 02:38:41 UTC
Permalink
https://github.com/Paul-Licameli/audacity/commit/efc9d349e4a30fec2316fd3e7ca5aec77e0000a9

I intend this branch in my fork to be the one ultimately merged into
master, but not yet.

"Fetch" again (don't "pull") in case I update it again.

I squashed all into one commit and added a run time check that the
operating system is Sierra or later; else, don't fork and crash. (But
still do the execve in main() that Leland put there for other reasons.)

There is also a one second sleep in Project.cpp when closing a file, but
the usefulness of that is not yet proven, and that part may be removed
later.

It applies the fix in release builds only. If you want to do that in a
debug build, find this in AudacityApp.h, and remove the #if and #endif
lines:

#if ! defined(__WXDEBUG__)

#define FIX_BUG1567

#endif


Please verify that this is still as good a fix as any so far.

PRL
Gale Andrews
2017-01-23 00:27:54 UTC
Permalink
Hi Paul,

The bug1567-tidy release configuration starts up well with splash screen
and comes on top - just the weird double bounce in the Dock to be noted
as before.

The 1000 ms sleep after destroying the block files doesn't seem to do
much for stopping bug 1567 recurring - I got it every three or four closes
without saving. With 10000 ms sleep it still happens about one time in
10 (which is too long a sleep I figure).

Recording in another window while closing without saving still prevents
the bug occurring.

The bug1567-tidy modified to run as debug triggers 1567 on close without
save about one time in five with 1000 ms sleep. It has not triggered yet in
20 tries with 5000 ms sleep.

Weird2 rebuilt unmodified in debug so with the fork and crash fix turned off
does today sometimes launch with 1567 present, and close without save
does sometimes bring 1567 back. Not sure why I got so much better results
yesterday - I had not messed up the defines - but it looks like debug is not
a sufficient or reliable panacea.

Leland's Debug HEAD and my Debug HEAD behave similarly - 1567 happens
most of the time.

I tried moving the Audacity temp dir to
/Users/gale/Library/Audacity/SessionData/
(seemed not an unreasonable place) but the bug occurred again after a few
closes without saving. Of course I could not move the entire configuration
directory.

But this just might be something. Bug 1521
http://bugzilla.audacityteam.org/show_bug.cgi?id=1521
leaves old, emptied project folders behind in the temp folder. If I manually
delete the last project* folder left behind after the File > Close, 1567 doesn't
seem to trigger, even if I remove the sleep after destroying the block files.
I did 18 tries so far without the bug coming back.


Gale
Post by Paul Licameli
https://github.com/Paul-Licameli/audacity/commit/efc9d349e4a30fec2316fd3e7ca5aec77e0000a9
I intend this branch in my fork to be the one ultimately merged into master,
but not yet.
"Fetch" again (don't "pull") in case I update it again.
I squashed all into one commit and added a run time check that the operating
system is Sierra or later; else, don't fork and crash. (But still do the
execve in main() that Leland put there for other reasons.)
There is also a one second sleep in Project.cpp when closing a file, but the
usefulness of that is not yet proven, and that part may be removed later.
It applies the fix in release builds only. If you want to do that in a
debug build, find this in AudacityApp.h, and remove the #if and #endif
#if ! defined(__WXDEBUG__)
#define FIX_BUG1567
#endif
Please verify that this is still as good a fix as any so far.
PRL
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2017-01-23 01:25:53 UTC
Permalink
Post by Gale Andrews
Hi Paul,
The bug1567-tidy release configuration starts up well with splash screen
and comes on top - just the weird double bounce in the Dock to be noted
as before.
On my Mac, running El Capitan, I see the icon jump once only at startup,
whether running a 2.1.2 download or my release build of bug1567-tidy.
Post by Gale Andrews
The 1000 ms sleep after destroying the block files doesn't seem to do
much for stopping bug 1567 recurring - I got it every three or four closes
without saving. With 10000 ms sleep it still happens about one time in
10 (which is too long a sleep I figure).
Recording in another window while closing without saving still prevents
the bug occurring.
Somehow I missed the earlier reports of this observation. This is a
strange datum. Somehow more traffic in the temp directory stops the bug?
Post by Gale Andrews
The bug1567-tidy modified to run as debug triggers 1567 on close without
save about one time in five with 1000 ms sleep. It has not triggered yet in
20 tries with 5000 ms sleep.
Weird2 rebuilt unmodified in debug so with the fork and crash fix turned off
does today sometimes launch with 1567 present, and close without save
does sometimes bring 1567 back. Not sure why I got so much better results
yesterday - I had not messed up the defines - but it looks like debug is not
a sufficient or reliable panacea.
Leland's Debug HEAD and my Debug HEAD behave similarly - 1567 happens
most of the time.
I tried moving the Audacity temp dir to
/Users/gale/Library/Audacity/SessionData/
(seemed not an unreasonable place) but the bug occurred again after a few
closes without saving. Of course I could not move the entire configuration
directory.
If I remove audacity.cfg, then the default in directory preferences is:
/Users/paullicameli/Library/Application Support/audacity/SessionData

Was that (substituting your user name) not your temporary directory to
begin with? If not then what?

I was speculating that there is something about the ~/Library directory
that is special, and that you should try changing your temp directory to
something not under it, like simply /tmp
Post by Gale Andrews
But this just might be something. Bug 1521
http://bugzilla.audacityteam.org/show_bug.cgi?id=1521
leaves old, emptied project folders behind in the temp folder. If I manually
delete the last project* folder left behind after the File > Close, 1567 doesn't
seem to trigger, even if I remove the sleep after destroying the block files.
I did 18 tries so far without the bug coming back.
That entry in the bug database is puzzling. There is no fix of it yet, and
no comments on it besides yours. You say there is a difference of
behavior, in removal of temporary sub-folders, depending on operating
system, but not on Audacity version?

I observe that the sub-folders are removed on my El Capitan.

PRL
Post by Gale Andrews
Gale
Post by Paul Licameli
https://github.com/Paul-Licameli/audacity/commit/
efc9d349e4a30fec2316fd3e7ca5aec77e0000a9
Post by Paul Licameli
I intend this branch in my fork to be the one ultimately merged into
master,
Post by Paul Licameli
but not yet.
"Fetch" again (don't "pull") in case I update it again.
I squashed all into one commit and added a run time check that the
operating
Post by Paul Licameli
system is Sierra or later; else, don't fork and crash. (But still do the
execve in main() that Leland put there for other reasons.)
There is also a one second sleep in Project.cpp when closing a file, but
the
Post by Paul Licameli
usefulness of that is not yet proven, and that part may be removed later.
It applies the fix in release builds only. If you want to do that in a
debug build, find this in AudacityApp.h, and remove the #if and #endif
#if ! defined(__WXDEBUG__)
#define FIX_BUG1567
#endif
Please verify that this is still as good a fix as any so far.
PRL
------------------------------------------------------------
------------------
Post by Paul Licameli
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2017-01-23 01:45:55 UTC
Permalink
Post by Paul Licameli
Post by Gale Andrews
Hi Paul,
The bug1567-tidy release configuration starts up well with splash screen
and comes on top - just the weird double bounce in the Dock to be noted
as before.
On my Mac, running El Capitan, I see the icon jump once only at startup,
whether running a 2.1.2 download or my release build of bug1567-tidy.
Post by Gale Andrews
The 1000 ms sleep after destroying the block files doesn't seem to do
much for stopping bug 1567 recurring - I got it every three or four closes
without saving. With 10000 ms sleep it still happens about one time in
10 (which is too long a sleep I figure).
Recording in another window while closing without saving still prevents
the bug occurring.
Somehow I missed the earlier reports of this observation. This is a
strange datum. Somehow more traffic in the temp directory stops the bug?
Post by Gale Andrews
The bug1567-tidy modified to run as debug triggers 1567 on close without
save about one time in five with 1000 ms sleep. It has not triggered yet in
20 tries with 5000 ms sleep.
Weird2 rebuilt unmodified in debug so with the fork and crash fix turned off
does today sometimes launch with 1567 present, and close without save
does sometimes bring 1567 back. Not sure why I got so much better results
yesterday - I had not messed up the defines - but it looks like debug is not
a sufficient or reliable panacea.
Leland's Debug HEAD and my Debug HEAD behave similarly - 1567 happens
most of the time.
I tried moving the Audacity temp dir to
/Users/gale/Library/Audacity/SessionData/
(seemed not an unreasonable place) but the bug occurred again after a few
closes without saving. Of course I could not move the entire configuration
directory.
/Users/paullicameli/Library/Application Support/audacity/SessionData
Was that (substituting your user name) not your temporary directory to
begin with? If not then what?
I was speculating that there is something about the ~/Library directory
that is special, and that you should try changing your temp directory to
something not under it, like simply /tmp
Post by Gale Andrews
But this just might be something. Bug 1521
http://bugzilla.audacityteam.org/show_bug.cgi?id=1521
leaves old, emptied project folders behind in the temp folder. If I manually
delete the last project* folder left behind after the File > Close, 1567 doesn't
seem to trigger, even if I remove the sleep after destroying the block files.
I did 18 tries so far without the bug coming back.
That entry in the bug database is puzzling. There is no fix of it yet,
and no comments on it besides yours. You say there is a difference of
behavior, in removal of temporary sub-folders, depending on operating
system, but not on Audacity version?
I observe that the sub-folders are removed on my El Capitan.
PRL
More about this clue:

I observe that ~DirManager calls DirectoryManager::CleanTempDir which calls
RecursivelyRemove() which cleans up by first attempting to delete each file
or directory AS A FILE, and then again AS A DIRECTORY, but ignoring error
codes.

On my El Capitan, when closing a project without saving, this routinely
makes errors in the log file, in either a debug or a release build, that
the subdirectories could not be remove (as files), though the eventual
attempt to delete them as folders works.

Your computer has some timing-dependent difference of behavior, who knows
why.

This suggests to me that a rewrite that carefully removes files as files
(only) and directories as directories (only) might fix this problem.

Presumably, this would still be an independent problem; both this fix and
the fork and crash fix would be necessary.

PRL
Post by Paul Licameli
Post by Gale Andrews
Gale
Post by Paul Licameli
https://github.com/Paul-Licameli/audacity/commit/efc9d349e4a
30fec2316fd3e7ca5aec77e0000a9
Post by Paul Licameli
I intend this branch in my fork to be the one ultimately merged into
master,
Post by Paul Licameli
but not yet.
"Fetch" again (don't "pull") in case I update it again.
I squashed all into one commit and added a run time check that the
operating
Post by Paul Licameli
system is Sierra or later; else, don't fork and crash. (But still do
the
Post by Paul Licameli
execve in main() that Leland put there for other reasons.)
There is also a one second sleep in Project.cpp when closing a file,
but the
Post by Paul Licameli
usefulness of that is not yet proven, and that part may be removed
later.
Post by Paul Licameli
It applies the fix in release builds only. If you want to do that in a
debug build, find this in AudacityApp.h, and remove the #if and #endif
#if ! defined(__WXDEBUG__)
#define FIX_BUG1567
#endif
Please verify that this is still as good a fix as any so far.
PRL
------------------------------------------------------------
------------------
Post by Paul Licameli
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2017-01-23 02:14:19 UTC
Permalink
Gale, try it again with this commit, which may incidentally fix bug 1521,
and prevent the spurious messages in the log files:

https://github.com/Paul-Licameli/audacity/commit/d998c959b93738639cecdbe34a7dea9b1d75d332

Do I understand correctly that the problem with closing without save occurs
only when closing the last remaining project window? (But not necessarily
quitting the application). It does not happen when you close one of two
projects? If so, that is consistent with the problem I am fixing.

PRL
Post by Paul Licameli
Post by Paul Licameli
Post by Gale Andrews
Hi Paul,
The bug1567-tidy release configuration starts up well with splash screen
and comes on top - just the weird double bounce in the Dock to be noted
as before.
On my Mac, running El Capitan, I see the icon jump once only at startup,
whether running a 2.1.2 download or my release build of bug1567-tidy.
Post by Gale Andrews
The 1000 ms sleep after destroying the block files doesn't seem to do
much for stopping bug 1567 recurring - I got it every three or four closes
without saving. With 10000 ms sleep it still happens about one time in
10 (which is too long a sleep I figure).
Recording in another window while closing without saving still prevents
the bug occurring.
Somehow I missed the earlier reports of this observation. This is a
strange datum. Somehow more traffic in the temp directory stops the bug?
Post by Gale Andrews
The bug1567-tidy modified to run as debug triggers 1567 on close without
save about one time in five with 1000 ms sleep. It has not triggered yet in
20 tries with 5000 ms sleep.
Weird2 rebuilt unmodified in debug so with the fork and crash fix turned off
does today sometimes launch with 1567 present, and close without save
does sometimes bring 1567 back. Not sure why I got so much better results
yesterday - I had not messed up the defines - but it looks like debug is not
a sufficient or reliable panacea.
Leland's Debug HEAD and my Debug HEAD behave similarly - 1567 happens
most of the time.
I tried moving the Audacity temp dir to
/Users/gale/Library/Audacity/SessionData/
(seemed not an unreasonable place) but the bug occurred again after a few
closes without saving. Of course I could not move the entire
configuration
directory.
/Users/paullicameli/Library/Application Support/audacity/SessionData
Was that (substituting your user name) not your temporary directory to
begin with? If not then what?
I was speculating that there is something about the ~/Library directory
that is special, and that you should try changing your temp directory to
something not under it, like simply /tmp
Post by Gale Andrews
But this just might be something. Bug 1521
http://bugzilla.audacityteam.org/show_bug.cgi?id=1521
leaves old, emptied project folders behind in the temp folder. If I manually
delete the last project* folder left behind after the File > Close, 1567 doesn't
seem to trigger, even if I remove the sleep after destroying the block files.
I did 18 tries so far without the bug coming back.
That entry in the bug database is puzzling. There is no fix of it yet,
and no comments on it besides yours. You say there is a difference of
behavior, in removal of temporary sub-folders, depending on operating
system, but not on Audacity version?
I observe that the sub-folders are removed on my El Capitan.
PRL
I observe that ~DirManager calls DirectoryManager::CleanTempDir which
calls RecursivelyRemove() which cleans up by first attempting to delete
each file or directory AS A FILE, and then again AS A DIRECTORY, but
ignoring error codes.
On my El Capitan, when closing a project without saving, this routinely
makes errors in the log file, in either a debug or a release build, that
the subdirectories could not be remove (as files), though the eventual
attempt to delete them as folders works.
Your computer has some timing-dependent difference of behavior, who knows
why.
This suggests to me that a rewrite that carefully removes files as files
(only) and directories as directories (only) might fix this problem.
Presumably, this would still be an independent problem; both this fix and
the fork and crash fix would be necessary.
PRL
Post by Paul Licameli
Post by Gale Andrews
Gale
Post by Paul Licameli
https://github.com/Paul-Licameli/audacity/commit/efc9d349e4a
30fec2316fd3e7ca5aec77e0000a9
Post by Paul Licameli
I intend this branch in my fork to be the one ultimately merged into
master,
Post by Paul Licameli
but not yet.
"Fetch" again (don't "pull") in case I update it again.
I squashed all into one commit and added a run time check that the
operating
Post by Paul Licameli
system is Sierra or later; else, don't fork and crash. (But still do
the
Post by Paul Licameli
execve in main() that Leland put there for other reasons.)
There is also a one second sleep in Project.cpp when closing a file,
but the
Post by Paul Licameli
usefulness of that is not yet proven, and that part may be removed
later.
Post by Paul Licameli
It applies the fix in release builds only. If you want to do that in a
debug build, find this in AudacityApp.h, and remove the #if and #endif
#if ! defined(__WXDEBUG__)
#define FIX_BUG1567
#endif
Please verify that this is still as good a fix as any so far.
PRL
------------------------------------------------------------
------------------
Post by Paul Licameli
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Gale Andrews
2017-01-23 03:05:03 UTC
Permalink
Post by Paul Licameli
Gale, try it again with this commit, which may incidentally fix bug 1521,
https://github.com/Paul-Licameli/audacity/commit/d998c959b93738639cecdbe34a7dea9b1d75d332
Thanks a lot, can't do it tonight but for the record my log messages
alternate between these two types:

02:46:28: Error: File
'/Users/gale/Library/Audacity/SessionData//project437381067/e00'
couldn't be removed (error 1: Operation not permitted)
02:46:28: Error: Directory
'/Users/gale/Library/Audacity/SessionData//project437381067/e00'
couldn't be deleted (error 66: Directory not empty)

There is a repeat of those two lines then it moves on to another project.
Post by Paul Licameli
Do I understand correctly that the problem with closing without save occurs
only when closing the last remaining project window? (But not necessarily
quitting the application). It does not happen when you close one of two
projects? If so, that is consistent with the problem I am fixing.
It can happen even if I am not closing the final window, but not so often
as when closing the final window.


Gale
Post by Paul Licameli
PRL
Post by Paul Licameli
Post by Paul Licameli
Post by Gale Andrews
Hi Paul,
The bug1567-tidy release configuration starts up well with splash screen
and comes on top - just the weird double bounce in the Dock to be noted
as before.
On my Mac, running El Capitan, I see the icon jump once only at startup,
whether running a 2.1.2 download or my release build of bug1567-tidy.
Post by Gale Andrews
The 1000 ms sleep after destroying the block files doesn't seem to do
much for stopping bug 1567 recurring - I got it every three or four closes
without saving. With 10000 ms sleep it still happens about one time in
10 (which is too long a sleep I figure).
Recording in another window while closing without saving still prevents
the bug occurring.
Somehow I missed the earlier reports of this observation. This is a
strange datum. Somehow more traffic in the temp directory stops the bug?
Post by Gale Andrews
The bug1567-tidy modified to run as debug triggers 1567 on close without
save about one time in five with 1000 ms sleep. It has not triggered yet in
20 tries with 5000 ms sleep.
Weird2 rebuilt unmodified in debug so with the fork and crash fix turned off
does today sometimes launch with 1567 present, and close without save
does sometimes bring 1567 back. Not sure why I got so much better results
yesterday - I had not messed up the defines - but it looks like debug is not
a sufficient or reliable panacea.
Leland's Debug HEAD and my Debug HEAD behave similarly - 1567 happens
most of the time.
I tried moving the Audacity temp dir to
/Users/gale/Library/Audacity/SessionData/
(seemed not an unreasonable place) but the bug occurred again after a few
closes without saving. Of course I could not move the entire configuration
directory.
/Users/paullicameli/Library/Application Support/audacity/SessionData
Was that (substituting your user name) not your temporary directory to
begin with? If not then what?
I was speculating that there is something about the ~/Library directory
that is special, and that you should try changing your temp directory to
something not under it, like simply /tmp
Post by Gale Andrews
But this just might be something. Bug 1521
http://bugzilla.audacityteam.org/show_bug.cgi?id=1521
leaves old, emptied project folders behind in the temp folder. If I manually
delete the last project* folder left behind after the File > Close, 1567 doesn't
seem to trigger, even if I remove the sleep after destroying the block files.
I did 18 tries so far without the bug coming back.
That entry in the bug database is puzzling. There is no fix of it yet,
and no comments on it besides yours. You say there is a difference of
behavior, in removal of temporary sub-folders, depending on operating
system, but not on Audacity version?
I observe that the sub-folders are removed on my El Capitan.
PRL
I observe that ~DirManager calls DirectoryManager::CleanTempDir which
calls RecursivelyRemove() which cleans up by first attempting to delete each
file or directory AS A FILE, and then again AS A DIRECTORY, but ignoring
error codes.
On my El Capitan, when closing a project without saving, this routinely
makes errors in the log file, in either a debug or a release build, that the
subdirectories could not be remove (as files), though the eventual attempt
to delete them as folders works.
Your computer has some timing-dependent difference of behavior, who knows
why.
This suggests to me that a rewrite that carefully removes files as files
(only) and directories as directories (only) might fix this problem.
Presumably, this would still be an independent problem; both this fix and
the fork and crash fix would be necessary.
PRL
Post by Paul Licameli
Post by Gale Andrews
Gale
Post by Paul Licameli
https://github.com/Paul-Licameli/audacity/commit/efc9d349e4a30fec2316fd3e7ca5aec77e0000a9
I intend this branch in my fork to be the one ultimately merged into master,
but not yet.
"Fetch" again (don't "pull") in case I update it again.
I squashed all into one commit and added a run time check that the operating
system is Sierra or later; else, don't fork and crash. (But still do the
execve in main() that Leland put there for other reasons.)
There is also a one second sleep in Project.cpp when closing a file, but the
usefulness of that is not yet proven, and that part may be removed later.
It applies the fix in release builds only. If you want to do that in a
debug build, find this in AudacityApp.h, and remove the #if and #endif
#if ! defined(__WXDEBUG__)
#define FIX_BUG1567
#endif
Please verify that this is still as good a fix as any so far.
PRL
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2017-01-23 03:47:02 UTC
Permalink
Post by Paul Licameli
Post by Paul Licameli
Gale, try it again with this commit, which may incidentally fix bug 1521,
https://github.com/Paul-Licameli/audacity/commit/
d998c959b93738639cecdbe34a7dea9b1d75d332
Thanks a lot, can't do it tonight but for the record my log messages
02:46:28: Error: File
'/Users/gale/Library/Audacity/SessionData//project437381067/e00'
couldn't be removed (error 1: Operation not permitted)
02:46:28: Error: Directory
'/Users/gale/Library/Audacity/SessionData//project437381067/e00'
couldn't be deleted (error 66: Directory not empty)
Now that is very interesting! On my computer I consistently get the first
log message but not the second. The code is supposed to be destroying the
temporary file tree bottom-up, the leaf .au files first and then the
folders above. Your log messages suggest to me that the call to
::wxRemoveFile may complete and return to the program, but there is some
delayed asynchronous action in the file system that we might need to wait
for, before attempting to remove the folder above it.

I am starting to feel hopeful that we have at last pinpointed something
that we are doing to the file system that is unusual and may account for
the problem on close.

But the commit d998c95 might not be the final fix, if in fact some delay
after the deletion of the leaf files is really what we need.

Would this fix, or my next iteration of it, if it completes the fix for
1557, be sufficient by itself to fix 1521 and 1567? Maybe not, maybe fork
and crash is still needed too. But then, we could test whether that is
so. You can check out master, and cherry-pick d998c95 (or whatever future
commit), and see if that is complete for 1567.

PRL
Post by Paul Licameli
There is a repeat of those two lines then it moves on to another project.
Post by Paul Licameli
Do I understand correctly that the problem with closing without save
occurs
Post by Paul Licameli
only when closing the last remaining project window? (But not
necessarily
Post by Paul Licameli
quitting the application). It does not happen when you close one of two
projects? If so, that is consistent with the problem I am fixing.
It can happen even if I am not closing the final window, but not so often
as when closing the final window.
Gale
Post by Paul Licameli
PRL
Post by Paul Licameli
Post by Paul Licameli
Post by Gale Andrews
Hi Paul,
The bug1567-tidy release configuration starts up well with splash
screen
Post by Paul Licameli
Post by Paul Licameli
Post by Paul Licameli
Post by Gale Andrews
and comes on top - just the weird double bounce in the Dock to be
noted
Post by Paul Licameli
Post by Paul Licameli
Post by Paul Licameli
Post by Gale Andrews
as before.
On my Mac, running El Capitan, I see the icon jump once only at
startup,
Post by Paul Licameli
Post by Paul Licameli
Post by Paul Licameli
whether running a 2.1.2 download or my release build of bug1567-tidy.
Post by Gale Andrews
The 1000 ms sleep after destroying the block files doesn't seem to do
much for stopping bug 1567 recurring - I got it every three or four closes
without saving. With 10000 ms sleep it still happens about one time
in
Post by Paul Licameli
Post by Paul Licameli
Post by Paul Licameli
Post by Gale Andrews
10 (which is too long a sleep I figure).
Recording in another window while closing without saving still
prevents
Post by Paul Licameli
Post by Paul Licameli
Post by Paul Licameli
Post by Gale Andrews
the bug occurring.
Somehow I missed the earlier reports of this observation. This is a
strange datum. Somehow more traffic in the temp directory stops the
bug?
Post by Paul Licameli
Post by Paul Licameli
Post by Paul Licameli
Post by Gale Andrews
The bug1567-tidy modified to run as debug triggers 1567 on close
without
Post by Paul Licameli
Post by Paul Licameli
Post by Paul Licameli
Post by Gale Andrews
save about one time in five with 1000 ms sleep. It has not triggered
yet
Post by Paul Licameli
Post by Paul Licameli
Post by Paul Licameli
Post by Gale Andrews
in
20 tries with 5000 ms sleep.
Weird2 rebuilt unmodified in debug so with the fork and crash fix
turned
Post by Paul Licameli
Post by Paul Licameli
Post by Paul Licameli
Post by Gale Andrews
off
does today sometimes launch with 1567 present, and close without save
does sometimes bring 1567 back. Not sure why I got so much better results
yesterday - I had not messed up the defines - but it looks like debug is not
a sufficient or reliable panacea.
Leland's Debug HEAD and my Debug HEAD behave similarly - 1567 happens
most of the time.
I tried moving the Audacity temp dir to
/Users/gale/Library/Audacity/SessionData/
(seemed not an unreasonable place) but the bug occurred again after a few
closes without saving. Of course I could not move the entire configuration
directory.
/Users/paullicameli/Library/Application Support/audacity/SessionData
Was that (substituting your user name) not your temporary directory to
begin with? If not then what?
I was speculating that there is something about the ~/Library directory
that is special, and that you should try changing your temp directory
to
Post by Paul Licameli
Post by Paul Licameli
Post by Paul Licameli
something not under it, like simply /tmp
Post by Gale Andrews
But this just might be something. Bug 1521
http://bugzilla.audacityteam.org/show_bug.cgi?id=1521
leaves old, emptied project folders behind in the temp folder. If I manually
delete the last project* folder left behind after the File > Close,
1567
Post by Paul Licameli
Post by Paul Licameli
Post by Paul Licameli
Post by Gale Andrews
doesn't
seem to trigger, even if I remove the sleep after destroying the block files.
I did 18 tries so far without the bug coming back.
That entry in the bug database is puzzling. There is no fix of it yet,
and no comments on it besides yours. You say there is a difference of
behavior, in removal of temporary sub-folders, depending on operating
system, but not on Audacity version?
I observe that the sub-folders are removed on my El Capitan.
PRL
I observe that ~DirManager calls DirectoryManager::CleanTempDir which
calls RecursivelyRemove() which cleans up by first attempting to delete
each
Post by Paul Licameli
Post by Paul Licameli
file or directory AS A FILE, and then again AS A DIRECTORY, but ignoring
error codes.
On my El Capitan, when closing a project without saving, this routinely
makes errors in the log file, in either a debug or a release build,
that the
Post by Paul Licameli
Post by Paul Licameli
subdirectories could not be remove (as files), though the eventual
attempt
Post by Paul Licameli
Post by Paul Licameli
to delete them as folders works.
Your computer has some timing-dependent difference of behavior, who
knows
Post by Paul Licameli
Post by Paul Licameli
why.
This suggests to me that a rewrite that carefully removes files as files
(only) and directories as directories (only) might fix this problem.
Presumably, this would still be an independent problem; both this fix
and
Post by Paul Licameli
Post by Paul Licameli
the fork and crash fix would be necessary.
PRL
Post by Paul Licameli
Post by Gale Andrews
Gale
Post by Paul Licameli
https://github.com/Paul-Licameli/audacity/commit/
efc9d349e4a30fec2316fd3e7ca5aec77e0000a9
Post by Paul Licameli
Post by Paul Licameli
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
I intend this branch in my fork to be the one ultimately merged into master,
but not yet.
"Fetch" again (don't "pull") in case I update it again.
I squashed all into one commit and added a run time check that the operating
system is Sierra or later; else, don't fork and crash. (But still
do
Post by Paul Licameli
Post by Paul Licameli
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
the
execve in main() that Leland put there for other reasons.)
There is also a one second sleep in Project.cpp when closing a file, but the
usefulness of that is not yet proven, and that part may be removed later.
It applies the fix in release builds only. If you want to do that
in
Post by Paul Licameli
Post by Paul Licameli
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
a
debug build, find this in AudacityApp.h, and remove the #if and
#endif
Post by Paul Licameli
Post by Paul Licameli
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
#if ! defined(__WXDEBUG__)
#define FIX_BUG1567
#endif
Please verify that this is still as good a fix as any so far.
PRL
------------------------------------------------------------
------------------
Post by Paul Licameli
Post by Paul Licameli
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Paul Licameli
Post by Paul Licameli
Post by Paul Licameli
Post by Gale Andrews
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Paul Licameli
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Gale Andrews
2017-01-23 02:38:19 UTC
Permalink
Post by Paul Licameli
Post by Gale Andrews
Hi Paul,
The bug1567-tidy release configuration starts up well with splash screen
and comes on top - just the weird double bounce in the Dock to be noted
as before.
On my Mac, running El Capitan, I see the icon jump once only at startup,
whether running a 2.1.2 download or my release build of bug1567-tidy.
Presumably because it is El Capitan, the crash fix on launch is not being
applied?
Post by Paul Licameli
Post by Gale Andrews
The 1000 ms sleep after destroying the block files doesn't seem to do
much for stopping bug 1567 recurring - I got it every three or four closes
without saving. With 10000 ms sleep it still happens about one time in
10 (which is too long a sleep I figure).
Recording in another window while closing without saving still prevents
the bug occurring.
Somehow I missed the earlier reports of this observation. This is a strange
datum. Somehow more traffic in the temp directory stops the bug?
Post by Gale Andrews
The bug1567-tidy modified to run as debug triggers 1567 on close without
save about one time in five with 1000 ms sleep. It has not triggered yet in
20 tries with 5000 ms sleep.
Weird2 rebuilt unmodified in debug so with the fork and crash fix turned off
does today sometimes launch with 1567 present, and close without save
does sometimes bring 1567 back. Not sure why I got so much better results
yesterday - I had not messed up the defines - but it looks like debug is not
a sufficient or reliable panacea.
Leland's Debug HEAD and my Debug HEAD behave similarly - 1567 happens
most of the time.
I tried moving the Audacity temp dir to
/Users/gale/Library/Audacity/SessionData/
(seemed not an unreasonable place) but the bug occurred again after a few
closes without saving. Of course I could not move the entire configuration
directory.
/Users/paullicameli/Library/Application Support/audacity/SessionData
Was that (substituting your user name) not your temporary directory to begin
with? If not then what?
/Users/gale/Library/Application Support/audacity/SessionData is my default
if I delete audacity.cfg, yes. I just did a blind experiment with
/Users/gale/Library/Audacity/SessionData/ .
Post by Paul Licameli
I was speculating that there is something about the ~/Library directory that
is special, and that you should try changing your temp directory to
something not under it, like simply /tmp
I didn't recall that is what you wrote. And we must be sure the files
survive reboot if Audacity crashes.

Anyway, on a quick try with /tmp/audacity-gale/SessionData, I can
still get 1567 on File > Close with no save.
Post by Paul Licameli
Post by Gale Andrews
But this just might be something. Bug 1521
http://bugzilla.audacityteam.org/show_bug.cgi?id=1521
leaves old, emptied project folders behind in the temp folder. If I manually
delete the last project* folder left behind after the File > Close, 1567 doesn't
seem to trigger, even if I remove the sleep after destroying the block files.
I did 18 tries so far without the bug coming back.
That entry in the bug database is puzzling. There is no fix of it yet, and
no comments on it besides yours. You say there is a difference of behavior,
in removal of temporary sub-folders, depending on operating system, but not
on Audacity version?
Yes, on my machine. I am very confident of that.
Post by Paul Licameli
I observe that the sub-folders are removed on my El Capitan.
Then I am kind of guessing that will be so with Peter and Cliff on
Sierra, and this is another "machine too slow" issue. This is mine
- 2.3 GHz HDD and 4 GB RAM:
http://www.everymac.com/systems/apple/mac_mini/specs/mac-mini-core-i5-2.3-mid-2011-specs.html
.

It is puzzling why leaving old folders behind is OK when another
project is doing something, but not otherwise.



Gale
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
https://github.com/Paul-Licameli/audacity/commit/efc9d349e4a30fec2316fd3e7ca5aec77e0000a9
I intend this branch in my fork to be the one ultimately merged into master,
but not yet.
"Fetch" again (don't "pull") in case I update it again.
I squashed all into one commit and added a run time check that the operating
system is Sierra or later; else, don't fork and crash. (But still do the
execve in main() that Leland put there for other reasons.)
There is also a one second sleep in Project.cpp when closing a file, but the
usefulness of that is not yet proven, and that part may be removed later.
It applies the fix in release builds only. If you want to do that in a
debug build, find this in AudacityApp.h, and remove the #if and #endif
#if ! defined(__WXDEBUG__)
#define FIX_BUG1567
#endif
Please verify that this is still as good a fix as any so far.
PRL
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2017-01-23 03:38:04 UTC
Permalink
Post by Gale Andrews
Post by Paul Licameli
Post by Gale Andrews
Hi Paul,
The bug1567-tidy release configuration starts up well with splash screen
and comes on top - just the weird double bounce in the Dock to be noted
as before.
On my Mac, running El Capitan, I see the icon jump once only at startup,
whether running a 2.1.2 download or my release build of bug1567-tidy.
Presumably because it is El Capitan, the crash fix on launch is not being
applied?
I must make a small change in the code so that fork and crash happens on El
Capitan, but even so, no I still see nothing unusual about the icon when
the program starts.

PRL
Post by Gale Andrews
Post by Paul Licameli
Post by Gale Andrews
The 1000 ms sleep after destroying the block files doesn't seem to do
much for stopping bug 1567 recurring - I got it every three or four
closes
Post by Paul Licameli
Post by Gale Andrews
without saving. With 10000 ms sleep it still happens about one time in
10 (which is too long a sleep I figure).
Recording in another window while closing without saving still prevents
the bug occurring.
Somehow I missed the earlier reports of this observation. This is a
strange
Post by Paul Licameli
datum. Somehow more traffic in the temp directory stops the bug?
Post by Gale Andrews
The bug1567-tidy modified to run as debug triggers 1567 on close without
save about one time in five with 1000 ms sleep. It has not triggered yet in
20 tries with 5000 ms sleep.
Weird2 rebuilt unmodified in debug so with the fork and crash fix turned off
does today sometimes launch with 1567 present, and close without save
does sometimes bring 1567 back. Not sure why I got so much better
results
Post by Paul Licameli
Post by Gale Andrews
yesterday - I had not messed up the defines - but it looks like debug
is
Post by Paul Licameli
Post by Gale Andrews
not
a sufficient or reliable panacea.
Leland's Debug HEAD and my Debug HEAD behave similarly - 1567 happens
most of the time.
I tried moving the Audacity temp dir to
/Users/gale/Library/Audacity/SessionData/
(seemed not an unreasonable place) but the bug occurred again after a
few
Post by Paul Licameli
Post by Gale Andrews
closes without saving. Of course I could not move the entire
configuration
Post by Paul Licameli
Post by Gale Andrews
directory.
/Users/paullicameli/Library/Application Support/audacity/SessionData
Was that (substituting your user name) not your temporary directory to
begin
Post by Paul Licameli
with? If not then what?
/Users/gale/Library/Application Support/audacity/SessionData is my default
if I delete audacity.cfg, yes. I just did a blind experiment with
/Users/gale/Library/Audacity/SessionData/ .
Post by Paul Licameli
I was speculating that there is something about the ~/Library directory
that
Post by Paul Licameli
is special, and that you should try changing your temp directory to
something not under it, like simply /tmp
I didn't recall that is what you wrote. And we must be sure the files
survive reboot if Audacity crashes.
Anyway, on a quick try with /tmp/audacity-gale/SessionData, I can
still get 1567 on File > Close with no save.
Post by Paul Licameli
Post by Gale Andrews
But this just might be something. Bug 1521
http://bugzilla.audacityteam.org/show_bug.cgi?id=1521
leaves old, emptied project folders behind in the temp folder. If I manually
delete the last project* folder left behind after the File > Close, 1567 doesn't
seem to trigger, even if I remove the sleep after destroying the block files.
I did 18 tries so far without the bug coming back.
That entry in the bug database is puzzling. There is no fix of it yet,
and
Post by Paul Licameli
no comments on it besides yours. You say there is a difference of
behavior,
Post by Paul Licameli
in removal of temporary sub-folders, depending on operating system, but
not
Post by Paul Licameli
on Audacity version?
Yes, on my machine. I am very confident of that.
Post by Paul Licameli
I observe that the sub-folders are removed on my El Capitan.
Then I am kind of guessing that will be so with Peter and Cliff on
Sierra, and this is another "machine too slow" issue. This is mine
http://www.everymac.com/systems/apple/mac_mini/specs/
mac-mini-core-i5-2.3-mid-2011-specs.html
.
It is puzzling why leaving old folders behind is OK when another
project is doing something, but not otherwise.
Gale
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
https://github.com/Paul-Licameli/audacity/commit/
efc9d349e4a30fec2316fd3e7ca5aec77e0000a9
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
I intend this branch in my fork to be the one ultimately merged into master,
but not yet.
"Fetch" again (don't "pull") in case I update it again.
I squashed all into one commit and added a run time check that the operating
system is Sierra or later; else, don't fork and crash. (But still do the
execve in main() that Leland put there for other reasons.)
There is also a one second sleep in Project.cpp when closing a file,
but
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
the
usefulness of that is not yet proven, and that part may be removed later.
It applies the fix in release builds only. If you want to do that in
a
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
debug build, find this in AudacityApp.h, and remove the #if and #endif
#if ! defined(__WXDEBUG__)
#define FIX_BUG1567
#endif
Please verify that this is still as good a fix as any so far.
PRL
------------------------------------------------------------
------------------
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Paul Licameli
Post by Gale Andrews
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Paul Licameli
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Loading...