Quantcast

Bug 1567 startup sleeps

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug 1567 startup sleeps

Gale
Administrator
On 7 January 2017 at 00:46, Paul Licameli <[hidden email]> wrote:

>> On Fri, Jan 6, 2017 at 5:23 PM, Gale Andrews <[hidden email]> wrote:
>> On very brief testing, Paul's sleeps on exit and init as coded make some
>> impact on bug 1567 on my machine, without entirely preventing it. I still
>> see about 1 in 8 failures if Audacity is launched outside /Applications,
>> but
>> I can go up to 25 to 40 launches from /Applications before the bug
>> triggers.
>>
>> So I would like to suggest we tweak sleeps further (do we need retry?)
>> and that we won't need the fix of Audacity as single-user with a forced
>> Portable Settings folder, or User-Settings as amelioration of that. If so,
>> does that automatically remove the "damaged" and excessive verification
>> time problems encountered above?
>
>
> It is very good to hear at last that the sleeps appear to have an effect on
> the probability of the bug.
>
> I inserted one sleep near startup, in AudacityApp::InitTempDir, and another
> at shut-down, in AudacityApp::OnExit.  In each, I made the duration 1000
> msec.
>
> Not yet known:  is the reduced frequency of the problem due to one sleep or
> the other, or is the combination necessary?
>
> You can easily edit those two occurrences of the number 1000 to experiment
> with longer intervals.
>
> If the sleep at exit is the important one, and if you must lengthen that
> from one to several seconds, even so this might be acceptable.  The slightly
> odd-looking consequence might be that the Audacity icon is slow to disappear
> from the dock, but because the single-instance checker has been destroyed,
> that should mean you are not barred from starting up another instance of
> Audacity before the first disappears.
>
> Surely a longer sleep at exit would be more tolerable than at startup.

It's the startup sleep that mainly helps on my machine, assuming I relaunch
Audacity immediately, rather than wait a while before relaunch, which
ameliorates the bug.

Increasing the exit sleep to 2000 with no startup sleep makes no practical
difference to the bug that I can see. Increasing exit sleep to 3000 or 10000
with no startup sleep gets me to about 1 in 20 failures launching Audacity
from /Applications and 1 in 5 failures launching from elsewhere (no
sleeps is about 1 in 15 and 1 in 3 respectively).

If I remove the exit sleep and just have the startup sleep before the single
instance checker, in one set of launches I got the bug at:

1000 ms = try 29 and 5 respectively
2000 ms = try 27 and 8 respectively
5000 ms = try 38 and 9 respectively
10000 ms = not failed yet in 50 and try 9 respectively

With exit sleep at 3000 and startup sleep at 2000 I failed at 36 and 10
respectively. I did not try other sleep lengths with both sleeps.

Perhaps we could try more sleeps of shorter durations at start up in case
we don't have the best place yet. How about a sleep before creating the
.audacity.sock file? Other places?

It looks like we may not fully solve Audacity launched from outside
/Applications unless we act on configuration files inside the bundle. But I
would like you to suggest more and shorter exit sleeps first, or other
suggestions if you have any.

The fix of force quitting Audacity immediately on launch then letting launch
complete still works, providing I get no lock file created.


Gale

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 1567 startup sleeps

Paul Licameli


On Sat, Jan 7, 2017 at 1:50 PM, Gale Andrews <[hidden email]> wrote:
On 7 January 2017 at 00:46, Paul Licameli <[hidden email]> wrote:
>> On Fri, Jan 6, 2017 at 5:23 PM, Gale Andrews <[hidden email]> wrote:
>> On very brief testing, Paul's sleeps on exit and init as coded make some
>> impact on bug 1567 on my machine, without entirely preventing it. I still
>> see about 1 in 8 failures if Audacity is launched outside /Applications,
>> but
>> I can go up to 25 to 40 launches from /Applications before the bug
>> triggers.
>>
>> So I would like to suggest we tweak sleeps further (do we need retry?)
>> and that we won't need the fix of Audacity as single-user with a forced
>> Portable Settings folder, or User-Settings as amelioration of that. If so,
>> does that automatically remove the "damaged" and excessive verification
>> time problems encountered above?
>
>
> It is very good to hear at last that the sleeps appear to have an effect on
> the probability of the bug.
>
> I inserted one sleep near startup, in AudacityApp::InitTempDir, and another
> at shut-down, in AudacityApp::OnExit.  In each, I made the duration 1000
> msec.
>
> Not yet known:  is the reduced frequency of the problem due to one sleep or
> the other, or is the combination necessary?
>
> You can easily edit those two occurrences of the number 1000 to experiment
> with longer intervals.
>
> If the sleep at exit is the important one, and if you must lengthen that
> from one to several seconds, even so this might be acceptable.  The slightly
> odd-looking consequence might be that the Audacity icon is slow to disappear
> from the dock, but because the single-instance checker has been destroyed,
> that should mean you are not barred from starting up another instance of
> Audacity before the first disappears.
>
> Surely a longer sleep at exit would be more tolerable than at startup.

It's the startup sleep that mainly helps on my machine, assuming I relaunch
Audacity immediately, rather than wait a while before relaunch, which
ameliorates the bug.

Increasing the exit sleep to 2000 with no startup sleep makes no practical
difference to the bug that I can see. Increasing exit sleep to 3000 or 10000
with no startup sleep gets me to about 1 in 20 failures launching Audacity
from /Applications and 1 in 5 failures launching from elsewhere (no
sleeps is about 1 in 15 and 1 in 3 respectively).

If I remove the exit sleep and just have the startup sleep before the single
instance checker, in one set of launches I got the bug at:

1000 ms = try 29 and 5 respectively
2000 ms = try 27 and 8 respectively
5000 ms = try 38 and 9 respectively
10000 ms = not failed yet in 50 and try 9 respectively

With exit sleep at 3000 and startup sleep at 2000 I failed at 36 and 10
respectively. I did not try other sleep lengths with both sleeps.

Perhaps we could try more sleeps of shorter durations at start up in case
we don't have the best place yet. How about a sleep before creating the
.audacity.sock file? Other places?

It looks like we may not fully solve Audacity launched from outside
/Applications unless we act on configuration files inside the bundle. But I
would like you to suggest more and shorter exit sleeps first, or other
suggestions if you have any.

The fix of force quitting Audacity immediately on launch then letting launch
complete still works, providing I get no lock file created.


Gale

Not yet the decisive victory I had been hoping for.

Let me understand:

  • Even unmodified, the program is less likely to suffer the bug if you simply pause long enough between relaunches.  So really it's only a sequence of rapid relaunches that is the problem.
  • When it strikes once, it will invariably strike again until either the operating system is rebooted, or you use a quick enough force-quit.
  • When you force-quit and try again, this is comparably fast, to a normal program exit followed by another try: in other words the timing of your restart in this case, is not an uncontrolled variable.
I had a bizarre idea to try next -- perhaps bizarre ideas are needed.  I could simulate the force quit.  (By raising SIGTERM.)  I could make each start of Audacity launch a process, which would commit suicide, but start a second process.  If there is something just about the starting and early stopping that makes the operating system straighten itself out, who knows, this might work.

Here is an implementation.  It does not include any of the previous attempted fixes.  It does contain a wxMilliSleep of just 1 msec in the non-crashing process.  You might adjust that number.


PRL



 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 1567 startup sleeps

Paul Licameli
Do we have any more data about this possible fix?

PRL


On Sat, Jan 7, 2017 at 5:43 PM, Paul Licameli <[hidden email]> wrote:


On Sat, Jan 7, 2017 at 1:50 PM, Gale Andrews <[hidden email]> wrote:
On 7 January 2017 at 00:46, Paul Licameli <[hidden email]> wrote:
>> On Fri, Jan 6, 2017 at 5:23 PM, Gale Andrews <[hidden email]> wrote:
>> On very brief testing, Paul's sleeps on exit and init as coded make some
>> impact on bug 1567 on my machine, without entirely preventing it. I still
>> see about 1 in 8 failures if Audacity is launched outside /Applications,
>> but
>> I can go up to 25 to 40 launches from /Applications before the bug
>> triggers.
>>
>> So I would like to suggest we tweak sleeps further (do we need retry?)
>> and that we won't need the fix of Audacity as single-user with a forced
>> Portable Settings folder, or User-Settings as amelioration of that. If so,
>> does that automatically remove the "damaged" and excessive verification
>> time problems encountered above?
>
>
> It is very good to hear at last that the sleeps appear to have an effect on
> the probability of the bug.
>
> I inserted one sleep near startup, in AudacityApp::InitTempDir, and another
> at shut-down, in AudacityApp::OnExit.  In each, I made the duration 1000
> msec.
>
> Not yet known:  is the reduced frequency of the problem due to one sleep or
> the other, or is the combination necessary?
>
> You can easily edit those two occurrences of the number 1000 to experiment
> with longer intervals.
>
> If the sleep at exit is the important one, and if you must lengthen that
> from one to several seconds, even so this might be acceptable.  The slightly
> odd-looking consequence might be that the Audacity icon is slow to disappear
> from the dock, but because the single-instance checker has been destroyed,
> that should mean you are not barred from starting up another instance of
> Audacity before the first disappears.
>
> Surely a longer sleep at exit would be more tolerable than at startup.

It's the startup sleep that mainly helps on my machine, assuming I relaunch
Audacity immediately, rather than wait a while before relaunch, which
ameliorates the bug.

Increasing the exit sleep to 2000 with no startup sleep makes no practical
difference to the bug that I can see. Increasing exit sleep to 3000 or 10000
with no startup sleep gets me to about 1 in 20 failures launching Audacity
from /Applications and 1 in 5 failures launching from elsewhere (no
sleeps is about 1 in 15 and 1 in 3 respectively).

If I remove the exit sleep and just have the startup sleep before the single
instance checker, in one set of launches I got the bug at:

1000 ms = try 29 and 5 respectively
2000 ms = try 27 and 8 respectively
5000 ms = try 38 and 9 respectively
10000 ms = not failed yet in 50 and try 9 respectively

With exit sleep at 3000 and startup sleep at 2000 I failed at 36 and 10
respectively. I did not try other sleep lengths with both sleeps.

Perhaps we could try more sleeps of shorter durations at start up in case
we don't have the best place yet. How about a sleep before creating the
.audacity.sock file? Other places?

It looks like we may not fully solve Audacity launched from outside
/Applications unless we act on configuration files inside the bundle. But I
would like you to suggest more and shorter exit sleeps first, or other
suggestions if you have any.

The fix of force quitting Audacity immediately on launch then letting launch
complete still works, providing I get no lock file created.


Gale

Not yet the decisive victory I had been hoping for.

Let me understand:

  • Even unmodified, the program is less likely to suffer the bug if you simply pause long enough between relaunches.  So really it's only a sequence of rapid relaunches that is the problem.
  • When it strikes once, it will invariably strike again until either the operating system is rebooted, or you use a quick enough force-quit.
  • When you force-quit and try again, this is comparably fast, to a normal program exit followed by another try: in other words the timing of your restart in this case, is not an uncontrolled variable.
I had a bizarre idea to try next -- perhaps bizarre ideas are needed.  I could simulate the force quit.  (By raising SIGTERM.)  I could make each start of Audacity launch a process, which would commit suicide, but start a second process.  If there is something just about the starting and early stopping that makes the operating system straighten itself out, who knows, this might work.

Here is an implementation.  It does not include any of the previous attempted fixes.  It does contain a wxMilliSleep of just 1 msec in the non-crashing process.  You might adjust that number.


PRL



 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality



------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 1567 startup sleeps

Peter Sampson-2
Paul wrote:
>Do we have any more data about this possible fix?

My Macbook is not a good testbed for this bug, as no matter how
hard I try I cannot reproduce these symptoms, not with the nightlies
and not with the jcX builds.

And I recall that Cliff was not getting this happening on his Mac either.

Cheers,
Peter.

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 1567 startup sleeps

Cliff Scott
Correct. As soon as Gale has a workable solution then there will be lots of testing to do.

Cliff

> On Jan 10, 2017, at 11:07 AM, Peter Sampson <[hidden email]> wrote:
>
> Paul wrote:
> >Do we have any more data about this possible fix?
>
> My Macbook is not a good testbed for this bug, as no matter how
> hard I try I cannot reproduce these symptoms, not with the nightlies
> and not with the jcX builds.
>
> And I recall that Cliff was not getting this happening on his Mac either.
>
> Cheers,
> Peter.
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi_______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 1567 startup sleeps

Gale
Administrator
In reply to this post by Paul Licameli
Sorry, Paul. I've been staring at Gmail for several days wondering why there was
no reply, but now I looked on Nabble. There is no trace of the replies in Gmail
Bin or Spam and no trace of the new posts on -quality since the 7th, hence I
have not read those yet.

I am still subscribed to -quality and my delivery enabled according to the control
panel. I am not receiving -devel either. So at the moment I am pointing the finger
at Gmail and will try a desktop client.  


Paul Licameli wrote
On Sat, Jan 7, 2017 at 1:50 PM, Gale Andrews <[hidden email]> wrote:

> On 7 January 2017 at 00:46, Paul Licameli <[hidden email]> wrote:
> >> On Fri, Jan 6, 2017 at 5:23 PM, Gale Andrews <[hidden email]>
> wrote:
> >> On very brief testing, Paul's sleeps on exit and init as coded make some
> >> impact on bug 1567 on my machine, without entirely preventing it. I
> still
> >> see about 1 in 8 failures if Audacity is launched outside /Applications,
> >> but
> >> I can go up to 25 to 40 launches from /Applications before the bug
> >> triggers.
> >>
> >> So I would like to suggest we tweak sleeps further (do we need retry?)
> >> and that we won't need the fix of Audacity as single-user with a forced
> >> Portable Settings folder, or User-Settings as amelioration of that. If
> so,
> >> does that automatically remove the "damaged" and excessive verification
> >> time problems encountered above?
> >
> >
> > It is very good to hear at last that the sleeps appear to have an effect
> on
> > the probability of the bug.
> >
> > I inserted one sleep near startup, in AudacityApp::InitTempDir, and
> another
> > at shut-down, in AudacityApp::OnExit.  In each, I made the duration 1000
> > msec.
> >
> > Not yet known:  is the reduced frequency of the problem due to one sleep
> or
> > the other, or is the combination necessary?
> >
> > You can easily edit those two occurrences of the number 1000 to
> experiment
> > with longer intervals.
> >
> > If the sleep at exit is the important one, and if you must lengthen that
> > from one to several seconds, even so this might be acceptable.  The
> slightly
> > odd-looking consequence might be that the Audacity icon is slow to
> disappear
> > from the dock, but because the single-instance checker has been
> destroyed,
> > that should mean you are not barred from starting up another instance of
> > Audacity before the first disappears.
> >
> > Surely a longer sleep at exit would be more tolerable than at startup.
>
> It's the startup sleep that mainly helps on my machine, assuming I relaunch
> Audacity immediately, rather than wait a while before relaunch, which
> ameliorates the bug.
>
> Increasing the exit sleep to 2000 with no startup sleep makes no practical
> difference to the bug that I can see. Increasing exit sleep to 3000 or
> 10000
> with no startup sleep gets me to about 1 in 20 failures launching Audacity
> from /Applications and 1 in 5 failures launching from elsewhere (no
> sleeps is about 1 in 15 and 1 in 3 respectively).
>
> If I remove the exit sleep and just have the startup sleep before the
> single
> instance checker, in one set of launches I got the bug at:
>
> 1000 ms = try 29 and 5 respectively
> 2000 ms = try 27 and 8 respectively
> 5000 ms = try 38 and 9 respectively
> 10000 ms = not failed yet in 50 and try 9 respectively
>
> With exit sleep at 3000 and startup sleep at 2000 I failed at 36 and 10
> respectively. I did not try other sleep lengths with both sleeps.
>
> Perhaps we could try more sleeps of shorter durations at start up in case
> we don't have the best place yet. How about a sleep before creating the
> .audacity.sock file? Other places?
>
> It looks like we may not fully solve Audacity launched from outside
> /Applications unless we act on configuration files inside the bundle. But I
> would like you to suggest more and shorter exit sleeps first, or other
> suggestions if you have any.
>
> The fix of force quitting Audacity immediately on launch then letting
> launch
> complete still works, providing I get no lock file created.
>
>
> Gale
>

Not yet the decisive victory I had been hoping for.

Let me understand:


   - Even unmodified, the program is less likely to suffer the bug if you
   simply pause long enough between relaunches.  So really it's only a
   sequence of rapid relaunches that is the problem.
If unmodified 2.1.2 or HEAD, the bug occurs on first launch wherever
Audacity is launched from.

But if using an unmodified jcx codesigned build, then I see the variability
that launching from outside /Applications is more prone to the bug, and
that exiting and launching again with no pause is more prone to the bug
than waiting between launches.

Pausing isn't a total cure, even launching Audacity from /Applications.  

That made me think of testing File > Close in the build I tested that
has exit and starting sleeps. I don't have any issue if I launch Audacity
then do COMMAND + W repeatedly without pause. But if I record
something then COMMAND + W and don't save changes, this triggered
the bug on a couple of occasions. I lost plugins from the menus and lost
LAME and FFmpeg.  It did not happen if I said yes to Save Changes,
though I only tested twice.

As yet, I don't have an issue with that in jc10, running and installed as
Admin with its Portable Settings folder present, but I only tested three
closes without save and three closes with save. I'd have to test more  
to say jc10 is immune.

Yikes. So I guess clearing out the AutoSave folder is also a potential
problem, but saving a project also clears out AutoSave. So does that
also point to another timing issue?

If someone saves a Chain, is that going to risk triggering the bug,
given we write to a Chains folder in the configuration folder?  

Paul Licameli wrote
   - When it strikes once, it will invariably strike again until either the
   operating system is rebooted, or you use a quick enough force-quit.
Yes.

Paul Licameli wrote
   - When you force-quit and try again, this is comparably fast, to a
   normal program exit followed by another try: in other words the timing of
   your restart in this case, is not an uncontrolled variable.
Interesting. I can force quit then start normally as fast as I am physically
able, and that always gets rid of the bug.

But I just now waited several minutes after force quit, then launched
Audacity and the bug is still there. Force-quit, launch at once, and the
bug has gone.  

Paul Licameli wrote
I had a bizarre idea to try next -- perhaps bizarre ideas are needed.  I
could simulate the force quit.  (By raising SIGTERM.)  I could make each
start of Audacity launch a process, which would commit suicide, but start a
second process.  If there is something just about the starting and early
stopping that makes the operating system straighten itself out, who knows,
this might work.

Here is an implementation.  It does not include any of the previous
attempted fixes.  It does contain a wxMilliSleep of just 1 msec in the
non-crashing process.  You might adjust that number.

https://github.com/Paul-Licameli/audacity/commit/f0135d99c0f232982fe7fb4b10b68aa0385d9b6a
OK Paul I will try it ASAP now I've seen this. I'd have said that sounds
hopeful, but there is still the new Close Project issue I would like your
opinion on.      


Gale



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 1567 startup sleeps

Paul Licameli
Did you not see my message the first time?  I thought I replied to all.  Well please try this commit.

PRL


On Tue, Jan 10, 2017 at 5:14 PM, Gale <[hidden email]> wrote:
Sorry, Paul. I've been staring at Gmail for several days wondering why there
was
no reply, but now I looked on Nabble. There is no trace of the replies in
Gmail
Bin or Spam and no trace of the new posts on -quality since the 7th, hence I
have not read those yet.

I am still subscribed to -quality and my delivery enabled according to the
control
panel. I am not receiving -devel either. So at the moment I am pointing the
finger
at Gmail and will try a desktop client.



Paul Licameli wrote
> On Sat, Jan 7, 2017 at 1:50 PM, Gale Andrews &lt;

> gale@

> &gt; wrote:
>
>> On 7 January 2017 at 00:46, Paul Licameli &lt;

> paul.licameli@

> &gt; wrote:
>> >> On Fri, Jan 6, 2017 at 5:23 PM, Gale Andrews &lt;

> gale@

> &gt;
>> wrote:
>> >> On very brief testing, Paul's sleeps on exit and init as coded make
>> some
>> >> impact on bug 1567 on my machine, without entirely preventing it. I
>> still
>> >> see about 1 in 8 failures if Audacity is launched outside
>> /Applications,
>> >> but
>> >> I can go up to 25 to 40 launches from /Applications before the bug
>> >> triggers.
>> >>
>> >> So I would like to suggest we tweak sleeps further (do we need retry?)
>> >> and that we won't need the fix of Audacity as single-user with a
>> forced
>> >> Portable Settings folder, or User-Settings as amelioration of that. If
>> so,
>> >> does that automatically remove the "damaged" and excessive
>> verification
>> >> time problems encountered above?
>> >
>> >
>> > It is very good to hear at last that the sleeps appear to have an
>> effect
>> on
>> > the probability of the bug.
>> >
>> > I inserted one sleep near startup, in AudacityApp::InitTempDir, and
>> another
>> > at shut-down, in AudacityApp::OnExit.  In each, I made the duration
>> 1000
>> > msec.
>> >
>> > Not yet known:  is the reduced frequency of the problem due to one
>> sleep
>> or
>> > the other, or is the combination necessary?
>> >
>> > You can easily edit those two occurrences of the number 1000 to
>> experiment
>> > with longer intervals.
>> >
>> > If the sleep at exit is the important one, and if you must lengthen
>> that
>> > from one to several seconds, even so this might be acceptable.  The
>> slightly
>> > odd-looking consequence might be that the Audacity icon is slow to
>> disappear
>> > from the dock, but because the single-instance checker has been
>> destroyed,
>> > that should mean you are not barred from starting up another instance
>> of
>> > Audacity before the first disappears.
>> >
>> > Surely a longer sleep at exit would be more tolerable than at startup.
>>
>> It's the startup sleep that mainly helps on my machine, assuming I
>> relaunch
>> Audacity immediately, rather than wait a while before relaunch, which
>> ameliorates the bug.
>>
>> Increasing the exit sleep to 2000 with no startup sleep makes no
>> practical
>> difference to the bug that I can see. Increasing exit sleep to 3000 or
>> 10000
>> with no startup sleep gets me to about 1 in 20 failures launching
>> Audacity
>> from /Applications and 1 in 5 failures launching from elsewhere (no
>> sleeps is about 1 in 15 and 1 in 3 respectively).
>>
>> If I remove the exit sleep and just have the startup sleep before the
>> single
>> instance checker, in one set of launches I got the bug at:
>>
>> 1000 ms = try 29 and 5 respectively
>> 2000 ms = try 27 and 8 respectively
>> 5000 ms = try 38 and 9 respectively
>> 10000 ms = not failed yet in 50 and try 9 respectively
>>
>> With exit sleep at 3000 and startup sleep at 2000 I failed at 36 and 10
>> respectively. I did not try other sleep lengths with both sleeps.
>>
>> Perhaps we could try more sleeps of shorter durations at start up in case
>> we don't have the best place yet. How about a sleep before creating the
>> .audacity.sock file? Other places?
>>
>> It looks like we may not fully solve Audacity launched from outside
>> /Applications unless we act on configuration files inside the bundle. But
>> I
>> would like you to suggest more and shorter exit sleeps first, or other
>> suggestions if you have any.
>>
>> The fix of force quitting Audacity immediately on launch then letting
>> launch
>> complete still works, providing I get no lock file created.
>>
>>
>> Gale
>>
>
> Not yet the decisive victory I had been hoping for.
>
> Let me understand:
>
>
>    - Even unmodified, the program is less likely to suffer the bug if you
>    simply pause long enough between relaunches.  So really it's only a
>    sequence of rapid relaunches that is the problem.

If unmodified 2.1.2 or HEAD, the bug occurs on first launch wherever
Audacity is launched from.

But if using an unmodified jcx codesigned build, then I see the variability
that launching from outside /Applications is more prone to the bug, and
that exiting and launching again with no pause is more prone to the bug
than waiting between launches.

Pausing isn't a total cure, even launching Audacity from /Applications.

That made me think of testing File > Close in the build I tested that
has exit and starting sleeps. I don't have any issue if I launch Audacity
then do COMMAND + W repeatedly without pause. But if I record
something then COMMAND + W and don't save changes, this triggered
the bug on a couple of occasions. I lost plugins from the menus and lost
LAME and FFmpeg.  It did not happen if I said yes to Save Changes,
though I only tested twice.

As yet, I don't have an issue with that in jc10, running and installed as
Admin with its Portable Settings folder present, but I only tested three
closes without save and three closes with save. I'd have to test more
to say jc10 is immune.

Yikes. So I guess clearing out the AutoSave folder is also a potential
problem, but saving a project also clears out AutoSave. So does that
also point to another timing issue?

If someone saves a Chain, is that going to risk triggering the bug,
given we write to a Chains folder in the configuration folder?


Paul Licameli wrote
>    - When it strikes once, it will invariably strike again until either
> the
>    operating system is rebooted, or you use a quick enough force-quit.

Yes.


Paul Licameli wrote
>    - When you force-quit and try again, this is comparably fast, to a
>    normal program exit followed by another try: in other words the timing
> of
>    your restart in this case, is not an uncontrolled variable.

Interesting. I can force quit then start normally as fast as I am physically
able, and that always gets rid of the bug.

But I just now waited several minutes after force quit, then launched
Audacity and the bug is still there. Force-quit, launch at once, and the
bug has gone.


Paul Licameli wrote
> I had a bizarre idea to try next -- perhaps bizarre ideas are needed.  I
> could simulate the force quit.  (By raising SIGTERM.)  I could make each
> start of Audacity launch a process, which would commit suicide, but start
> a
> second process.  If there is something just about the starting and early
> stopping that makes the operating system straighten itself out, who knows,
> this might work.
>
> Here is an implementation.  It does not include any of the previous
> attempted fixes.  It does contain a wxMilliSleep of just 1 msec in the
> non-crashing process.  You might adjust that number.
>
> https://github.com/Paul-Licameli/audacity/commit/f0135d99c0f232982fe7fb4b10b68aa0385d9b6a

OK Paul I will try it ASAP now I've seen this. I'd have said that sounds
hopeful, but there is still the new Close Project issue I would like your
opinion on.


Gale







--
View this message in context: http://audacity.238276.n2.nabble.com/Bug-1567-startup-sleeps-tp7577731p7577747.html
Sent from the audacity-quality mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 1567 startup sleeps

Gale
Administrator
Paul Licameli wrote
Did you not see my message the first time?  I thought I replied to all.
Well please try this commit.

PRL
No, I see nothing in Gmail from the lists after the 7th, though I did get this
message of yours which you Cc'd to me.

I built your "weird" fix and at least on my machine, we are getting somewhere
at last.

I've so far done 40 launches of Audacity from /Applications, and (really good
news) 20 from other locations in my user space, without the bug appearing on
launch. This is with me downloading and running as admin, relaunching at
once or waiting 30 seconds. I can't get to force quit Audacity's Dock icon now -
the option disappears too fast.
       
I do still sometimes (50%?) get the bug if I File > Close with some data in the
AutoSave folder then don't save the project. Setting the single sleep you added
to 5000 ms does not stop the File > Close issue.

Quitting and relaunching Audacity removes the bug if File > Close has triggered
it, but does not stop it happening again.

Three points that may be problematic.

* Audacity never comes on top when launched. I have to task switch to it or
   touch its Dock icon to see it.

* When I launch Audacity, I do see the start of an Audacity menu bar by the
   current menu bar which is then replaced by the menu bar of the app that was
   on top when I launched Audacity.

* There is no splash screen when launching Audacity. I don't know if that is an
   issue if e.g. the disk space warning appears that used to clash with the
   splash screen.        


Gale


On Tue, Jan 10, 2017 at 5:14 PM, Gale <[hidden email]> wrote:

> Sorry, Paul. I've been staring at Gmail for several days wondering why
> there
> was
> no reply, but now I looked on Nabble. There is no trace of the replies in
> Gmail
> Bin or Spam and no trace of the new posts on -quality since the 7th, hence
> I
> have not read those yet.
>
> I am still subscribed to -quality and my delivery enabled according to the
> control
> panel. I am not receiving -devel either. So at the moment I am pointing the
> finger
> at Gmail and will try a desktop client.
>
>
>
> Paul Licameli wrote
> > On Sat, Jan 7, 2017 at 1:50 PM, Gale Andrews <
>
> > gale@
>
> > > wrote:
> >
> >> On 7 January 2017 at 00:46, Paul Licameli <
>
> > paul.licameli@
>
> > > wrote:
> >> >> On Fri, Jan 6, 2017 at 5:23 PM, Gale Andrews <
>
> > gale@
>
> > >
> >> wrote:
> >> >> On very brief testing, Paul's sleeps on exit and init as coded make
> >> some
> >> >> impact on bug 1567 on my machine, without entirely preventing it. I
> >> still
> >> >> see about 1 in 8 failures if Audacity is launched outside
> >> /Applications,
> >> >> but
> >> >> I can go up to 25 to 40 launches from /Applications before the bug
> >> >> triggers.
> >> >>
> >> >> So I would like to suggest we tweak sleeps further (do we need
> retry?)
> >> >> and that we won't need the fix of Audacity as single-user with a
> >> forced
> >> >> Portable Settings folder, or User-Settings as amelioration of that.
> If
> >> so,
> >> >> does that automatically remove the "damaged" and excessive
> >> verification
> >> >> time problems encountered above?
> >> >
> >> >
> >> > It is very good to hear at last that the sleeps appear to have an
> >> effect
> >> on
> >> > the probability of the bug.
> >> >
> >> > I inserted one sleep near startup, in AudacityApp::InitTempDir, and
> >> another
> >> > at shut-down, in AudacityApp::OnExit.  In each, I made the duration
> >> 1000
> >> > msec.
> >> >
> >> > Not yet known:  is the reduced frequency of the problem due to one
> >> sleep
> >> or
> >> > the other, or is the combination necessary?
> >> >
> >> > You can easily edit those two occurrences of the number 1000 to
> >> experiment
> >> > with longer intervals.
> >> >
> >> > If the sleep at exit is the important one, and if you must lengthen
> >> that
> >> > from one to several seconds, even so this might be acceptable.  The
> >> slightly
> >> > odd-looking consequence might be that the Audacity icon is slow to
> >> disappear
> >> > from the dock, but because the single-instance checker has been
> >> destroyed,
> >> > that should mean you are not barred from starting up another instance
> >> of
> >> > Audacity before the first disappears.
> >> >
> >> > Surely a longer sleep at exit would be more tolerable than at startup.
> >>
> >> It's the startup sleep that mainly helps on my machine, assuming I
> >> relaunch
> >> Audacity immediately, rather than wait a while before relaunch, which
> >> ameliorates the bug.
> >>
> >> Increasing the exit sleep to 2000 with no startup sleep makes no
> >> practical
> >> difference to the bug that I can see. Increasing exit sleep to 3000 or
> >> 10000
> >> with no startup sleep gets me to about 1 in 20 failures launching
> >> Audacity
> >> from /Applications and 1 in 5 failures launching from elsewhere (no
> >> sleeps is about 1 in 15 and 1 in 3 respectively).
> >>
> >> If I remove the exit sleep and just have the startup sleep before the
> >> single
> >> instance checker, in one set of launches I got the bug at:
> >>
> >> 1000 ms = try 29 and 5 respectively
> >> 2000 ms = try 27 and 8 respectively
> >> 5000 ms = try 38 and 9 respectively
> >> 10000 ms = not failed yet in 50 and try 9 respectively
> >>
> >> With exit sleep at 3000 and startup sleep at 2000 I failed at 36 and 10
> >> respectively. I did not try other sleep lengths with both sleeps.
> >>
> >> Perhaps we could try more sleeps of shorter durations at start up in
> case
> >> we don't have the best place yet. How about a sleep before creating the
> >> .audacity.sock file? Other places?
> >>
> >> It looks like we may not fully solve Audacity launched from outside
> >> /Applications unless we act on configuration files inside the bundle.
> But
> >> I
> >> would like you to suggest more and shorter exit sleeps first, or other
> >> suggestions if you have any.
> >>
> >> The fix of force quitting Audacity immediately on launch then letting
> >> launch
> >> complete still works, providing I get no lock file created.
> >>
> >>
> >> Gale
> >>
> >
> > Not yet the decisive victory I had been hoping for.
> >
> > Let me understand:
> >
> >
> >    - Even unmodified, the program is less likely to suffer the bug if you
> >    simply pause long enough between relaunches.  So really it's only a
> >    sequence of rapid relaunches that is the problem.
>
> If unmodified 2.1.2 or HEAD, the bug occurs on first launch wherever
> Audacity is launched from.
>
> But if using an unmodified jcx codesigned build, then I see the variability
> that launching from outside /Applications is more prone to the bug, and
> that exiting and launching again with no pause is more prone to the bug
> than waiting between launches.
>
> Pausing isn't a total cure, even launching Audacity from /Applications.
>
> That made me think of testing File > Close in the build I tested that
> has exit and starting sleeps. I don't have any issue if I launch Audacity
> then do COMMAND + W repeatedly without pause. But if I record
> something then COMMAND + W and don't save changes, this triggered
> the bug on a couple of occasions. I lost plugins from the menus and lost
> LAME and FFmpeg.  It did not happen if I said yes to Save Changes,
> though I only tested twice.
>
> As yet, I don't have an issue with that in jc10, running and installed as
> Admin with its Portable Settings folder present, but I only tested three
> closes without save and three closes with save. I'd have to test more
> to say jc10 is immune.
>
> Yikes. So I guess clearing out the AutoSave folder is also a potential
> problem, but saving a project also clears out AutoSave. So does that
> also point to another timing issue?
>
> If someone saves a Chain, is that going to risk triggering the bug,
> given we write to a Chains folder in the configuration folder?
>
>
> Paul Licameli wrote
> >    - When it strikes once, it will invariably strike again until either
> > the
> >    operating system is rebooted, or you use a quick enough force-quit.
>
> Yes.
>
>
> Paul Licameli wrote
> >    - When you force-quit and try again, this is comparably fast, to a
> >    normal program exit followed by another try: in other words the timing
> > of
> >    your restart in this case, is not an uncontrolled variable.
>
> Interesting. I can force quit then start normally as fast as I am
> physically
> able, and that always gets rid of the bug.
>
> But I just now waited several minutes after force quit, then launched
> Audacity and the bug is still there. Force-quit, launch at once, and the
> bug has gone.
>
>
> Paul Licameli wrote
> > I had a bizarre idea to try next -- perhaps bizarre ideas are needed.  I
> > could simulate the force quit.  (By raising SIGTERM.)  I could make each
> > start of Audacity launch a process, which would commit suicide, but start
> > a
> > second process.  If there is something just about the starting and early
> > stopping that makes the operating system straighten itself out, who
> knows,
> > this might work.
> >
> > Here is an implementation.  It does not include any of the previous
> > attempted fixes.  It does contain a wxMilliSleep of just 1 msec in the
> > non-crashing process.  You might adjust that number.
> >
> > https://github.com/Paul-Licameli/audacity/commit/
> f0135d99c0f232982fe7fb4b10b68aa0385d9b6a
>
> OK Paul I will try it ASAP now I've seen this. I'd have said that sounds
> hopeful, but there is still the new Close Project issue I would like your
> opinion on.
>
>
> Gale
>
> --
> View this message in context: http://audacity.238276.n2.
> nabble.com/Bug-1567-startup-sleeps-tp7577731p7577747.html
> Sent from the audacity-quality mailing list archive at N

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 1567 startup sleeps

Paul Licameli
Good news then!

I was aware that Audacity sometimes is not on top after launch.  For you, that happens always?

Another weird looking thing is that if I watch the tool dock closely, I see one fleeting Audacity icon grow and shrink, and then a persistent one.

I might fix at least the first of these things.

PRL


On Wed, Jan 11, 2017 at 1:12 AM, Gale <[hidden email]> wrote:
Paul Licameli wrote
> Did you not see my message the first time?  I thought I replied to all.
> Well please try this commit.
>
> PRL

No, I see nothing in Gmail from the lists after the 7th, though I did get
this
message of yours which you Cc'd to me.

I built your "weird" fix and at least on my machine, we are getting
somewhere
at last.

I've so far done 40 launches of Audacity from /Applications, and (really
good
news) 20 from other locations in my user space, without the bug appearing on
launch. This is with me downloading and running as admin, relaunching at
once or waiting 30 seconds. I can't get to force quit Audacity's Dock icon
now -
the option disappears too fast.

I do still sometimes (50%?) get the bug if I File > Close with some data in
the
AutoSave folder then don't save the project. Setting the single sleep you
added
to 5000 ms does not stop the File > Close issue.

Quitting and relaunching Audacity removes the bug if File > Close has
triggered
it, but does not stop it happening again.

Three points that may be problematic.

* Audacity never comes on top when launched. I have to task switch to it or
   touch its Dock icon to see it.

* When I launch Audacity, I do see the start of an Audacity menu bar by the
   current menu bar which is then replaced by the menu bar of the app that
was
   on top when I launched Audacity.

* There is no splash screen when launching Audacity. I don't know if that is
an
   issue if e.g. the disk space warning appears that used to clash with the
   splash screen.


Gale


On Tue, Jan 10, 2017 at 5:14 PM, Gale &lt;gale@&gt; wrote:

> Sorry, Paul. I've been staring at Gmail for several days wondering why
> there
> was
> no reply, but now I looked on Nabble. There is no trace of the replies in
> Gmail
> Bin or Spam and no trace of the new posts on -quality since the 7th, hence
> I
> have not read those yet.
>
> I am still subscribed to -quality and my delivery enabled according to the
> control
> panel. I am not receiving -devel either. So at the moment I am pointing
> the
> finger
> at Gmail and will try a desktop client.
>
>
>
> Paul Licameli wrote
> > On Sat, Jan 7, 2017 at 1:50 PM, Gale Andrews &lt;
>
> > gale@
>
> > &gt; wrote:
> >
> >> On 7 January 2017 at 00:46, Paul Licameli &lt;
>
> > paul.licameli@
>
> > &gt; wrote:
> >> >> On Fri, Jan 6, 2017 at 5:23 PM, Gale Andrews &lt;
>
> > gale@
>
> > &gt;
> >> wrote:
> >> >> On very brief testing, Paul's sleeps on exit and init as coded make
> >> some
> >> >> impact on bug 1567 on my machine, without entirely preventing it. I
> >> still
> >> >> see about 1 in 8 failures if Audacity is launched outside
> >> /Applications,
> >> >> but
> >> >> I can go up to 25 to 40 launches from /Applications before the bug
> >> >> triggers.
> >> >>
> >> >> So I would like to suggest we tweak sleeps further (do we need
> retry?)
> >> >> and that we won't need the fix of Audacity as single-user with a
> >> forced
> >> >> Portable Settings folder, or User-Settings as amelioration of that.
> If
> >> so,
> >> >> does that automatically remove the "damaged" and excessive
> >> verification
> >> >> time problems encountered above?
> >> >
> >> >
> >> > It is very good to hear at last that the sleeps appear to have an
> >> effect
> >> on
> >> > the probability of the bug.
> >> >
> >> > I inserted one sleep near startup, in AudacityApp::InitTempDir, and
> >> another
> >> > at shut-down, in AudacityApp::OnExit.  In each, I made the duration
> >> 1000
> >> > msec.
> >> >
> >> > Not yet known:  is the reduced frequency of the problem due to one
> >> sleep
> >> or
> >> > the other, or is the combination necessary?
> >> >
> >> > You can easily edit those two occurrences of the number 1000 to
> >> experiment
> >> > with longer intervals.
> >> >
> >> > If the sleep at exit is the important one, and if you must lengthen
> >> that
> >> > from one to several seconds, even so this might be acceptable.  The
> >> slightly
> >> > odd-looking consequence might be that the Audacity icon is slow to
> >> disappear
> >> > from the dock, but because the single-instance checker has been
> >> destroyed,
> >> > that should mean you are not barred from starting up another instance
> >> of
> >> > Audacity before the first disappears.
> >> >
> >> > Surely a longer sleep at exit would be more tolerable than at
> startup.
> >>
> >> It's the startup sleep that mainly helps on my machine, assuming I
> >> relaunch
> >> Audacity immediately, rather than wait a while before relaunch, which
> >> ameliorates the bug.
> >>
> >> Increasing the exit sleep to 2000 with no startup sleep makes no
> >> practical
> >> difference to the bug that I can see. Increasing exit sleep to 3000 or
> >> 10000
> >> with no startup sleep gets me to about 1 in 20 failures launching
> >> Audacity
> >> from /Applications and 1 in 5 failures launching from elsewhere (no
> >> sleeps is about 1 in 15 and 1 in 3 respectively).
> >>
> >> If I remove the exit sleep and just have the startup sleep before the
> >> single
> >> instance checker, in one set of launches I got the bug at:
> >>
> >> 1000 ms = try 29 and 5 respectively
> >> 2000 ms = try 27 and 8 respectively
> >> 5000 ms = try 38 and 9 respectively
> >> 10000 ms = not failed yet in 50 and try 9 respectively
> >>
> >> With exit sleep at 3000 and startup sleep at 2000 I failed at 36 and 10
> >> respectively. I did not try other sleep lengths with both sleeps.
> >>
> >> Perhaps we could try more sleeps of shorter durations at start up in
> case
> >> we don't have the best place yet. How about a sleep before creating the
> >> .audacity.sock file? Other places?
> >>
> >> It looks like we may not fully solve Audacity launched from outside
> >> /Applications unless we act on configuration files inside the bundle.
> But
> >> I
> >> would like you to suggest more and shorter exit sleeps first, or other
> >> suggestions if you have any.
> >>
> >> The fix of force quitting Audacity immediately on launch then letting
> >> launch
> >> complete still works, providing I get no lock file created.
> >>
> >>
> >> Gale
> >>
> >
> > Not yet the decisive victory I had been hoping for.
> >
> > Let me understand:
> >
> >
> >    - Even unmodified, the program is less likely to suffer the bug if
> you
> >    simply pause long enough between relaunches.  So really it's only a
> >    sequence of rapid relaunches that is the problem.
>
> If unmodified 2.1.2 or HEAD, the bug occurs on first launch wherever
> Audacity is launched from.
>
> But if using an unmodified jcx codesigned build, then I see the
> variability
> that launching from outside /Applications is more prone to the bug, and
> that exiting and launching again with no pause is more prone to the bug
> than waiting between launches.
>
> Pausing isn't a total cure, even launching Audacity from /Applications.
>
> That made me think of testing File > Close in the build I tested that
> has exit and starting sleeps. I don't have any issue if I launch Audacity
> then do COMMAND + W repeatedly without pause. But if I record
> something then COMMAND + W and don't save changes, this triggered
> the bug on a couple of occasions. I lost plugins from the menus and lost
> LAME and FFmpeg.  It did not happen if I said yes to Save Changes,
> though I only tested twice.
>
> As yet, I don't have an issue with that in jc10, running and installed as
> Admin with its Portable Settings folder present, but I only tested three
> closes without save and three closes with save. I'd have to test more
> to say jc10 is immune.
>
> Yikes. So I guess clearing out the AutoSave folder is also a potential
> problem, but saving a project also clears out AutoSave. So does that
> also point to another timing issue?
>
> If someone saves a Chain, is that going to risk triggering the bug,
> given we write to a Chains folder in the configuration folder?
>
>
> Paul Licameli wrote
> >    - When it strikes once, it will invariably strike again until either
> > the
> >    operating system is rebooted, or you use a quick enough force-quit.
>
> Yes.
>
>
> Paul Licameli wrote
> >    - When you force-quit and try again, this is comparably fast, to a
> >    normal program exit followed by another try: in other words the
> timing
> > of
> >    your restart in this case, is not an uncontrolled variable.
>
> Interesting. I can force quit then start normally as fast as I am
> physically
> able, and that always gets rid of the bug.
>
> But I just now waited several minutes after force quit, then launched
> Audacity and the bug is still there. Force-quit, launch at once, and the
> bug has gone.
>
>
> Paul Licameli wrote
> > I had a bizarre idea to try next -- perhaps bizarre ideas are needed.  I
> > could simulate the force quit.  (By raising SIGTERM.)  I could make each
> > start of Audacity launch a process, which would commit suicide, but
> start
> > a
> > second process.  If there is something just about the starting and early
> > stopping that makes the operating system straighten itself out, who
> knows,
> > this might work.
> >
> > Here is an implementation.  It does not include any of the previous
> > attempted fixes.  It does contain a wxMilliSleep of just 1 msec in the
> > non-crashing process.  You might adjust that number.
> >
> > https://github.com/Paul-Licameli/audacity/commit/
> f0135d99c0f232982fe7fb4b10b68aa0385d9b6a
>
> OK Paul I will try it ASAP now I've seen this. I'd have said that sounds
> hopeful, but there is still the new Close Project issue I would like your
> opinion on.
>
>
> Gale
>
> --
> View this message in context: http://audacity.238276.n2.
> nabble.com/Bug-1567-startup-sleeps-tp7577731p7577747.html
> Sent from the audacity-quality mailing list archive at N





--
View this message in context: http://audacity.238276.n2.nabble.com/Bug-1567-startup-sleeps-tp7577731p7577751.html
Sent from the audacity-quality mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 1567 startup sleeps

Gale
Administrator
Paul Licameli wrote
Good news then!

I was aware that Audacity sometimes is not on top after launch.  For you,
that happens always?

Another weird looking thing is that if I watch the tool dock closely, I see
one fleeting Audacity icon grow and shrink, and then a persistent one.
Yes,  never on top for me. Yes, if I look at the dock I can see that too.

I think the File > Close behaviour is a problem. But saving a Chain does
not trigger the bug as far as I can tell. If I find some other way to trigger
the bug while Audacity is running I'll let you know.

I modified your previous fix to insert another 1000 ms sleep before the sock file
(if I did it right). That helped a lot (no failures yet from /Applications, got to
about 20 tries before failing from outside /Applications). Just in case we
still go another route, but it seems you think the simulated force quit is safe.


Gale

Paul Licameli wrote
 
I might fix at least the first of these things.

PRL


On Wed, Jan 11, 2017 at 1:12 AM, Gale <[hidden email]> wrote:

> Paul Licameli wrote
> > Did you not see my message the first time?  I thought I replied to all.
> > Well please try this commit.
> >
> > PRL
>
> No, I see nothing in Gmail from the lists after the 7th, though I did get
> this
> message of yours which you Cc'd to me.
>
> I built your "weird" fix and at least on my machine, we are getting
> somewhere
> at last.
>
> I've so far done 40 launches of Audacity from /Applications, and (really
> good
> news) 20 from other locations in my user space, without the bug appearing
> on
> launch. This is with me downloading and running as admin, relaunching at
> once or waiting 30 seconds. I can't get to force quit Audacity's Dock icon
> now -
> the option disappears too fast.
>
> I do still sometimes (50%?) get the bug if I File > Close with some data in
> the
> AutoSave folder then don't save the project. Setting the single sleep you
> added
> to 5000 ms does not stop the File > Close issue.
>
> Quitting and relaunching Audacity removes the bug if File > Close has
> triggered
> it, but does not stop it happening again.
>
> Three points that may be problematic.
>
> * Audacity never comes on top when launched. I have to task switch to it or
>    touch its Dock icon to see it.
>
> * When I launch Audacity, I do see the start of an Audacity menu bar by the
>    current menu bar which is then replaced by the menu bar of the app that
> was
>    on top when I launched Audacity.
>
> * There is no splash screen when launching Audacity. I don't know if that
> is
> an
>    issue if e.g. the disk space warning appears that used to clash with the
>    splash screen.
>
>
> Gale
>
>
> On Tue, Jan 10, 2017 at 5:14 PM, Gale <gale@> wrote:
>
> > Sorry, Paul. I've been staring at Gmail for several days wondering why
> > there
> > was
> > no reply, but now I looked on Nabble. There is no trace of the replies in
> > Gmail
> > Bin or Spam and no trace of the new posts on -quality since the 7th,
> hence
> > I
> > have not read those yet.
> >
> > I am still subscribed to -quality and my delivery enabled according to
> the
> > control
> > panel. I am not receiving -devel either. So at the moment I am pointing
> > the
> > finger
> > at Gmail and will try a desktop client.
> >
> >
> >
> > Paul Licameli wrote
> > > On Sat, Jan 7, 2017 at 1:50 PM, Gale Andrews <
> >
> > > gale@
> >
> > > > wrote:
> > >
> > >> On 7 January 2017 at 00:46, Paul Licameli <
> >
> > > paul.licameli@
> >
> > > > wrote:
> > >> >> On Fri, Jan 6, 2017 at 5:23 PM, Gale Andrews <
> >
> > > gale@
> >
> > > >
> > >> wrote:
> > >> >> On very brief testing, Paul's sleeps on exit and init as coded make
> > >> some
> > >> >> impact on bug 1567 on my machine, without entirely preventing it. I
> > >> still
> > >> >> see about 1 in 8 failures if Audacity is launched outside
> > >> /Applications,
> > >> >> but
> > >> >> I can go up to 25 to 40 launches from /Applications before the bug
> > >> >> triggers.
> > >> >>
> > >> >> So I would like to suggest we tweak sleeps further (do we need
> > retry?)
> > >> >> and that we won't need the fix of Audacity as single-user with a
> > >> forced
> > >> >> Portable Settings folder, or User-Settings as amelioration of that.
> > If
> > >> so,
> > >> >> does that automatically remove the "damaged" and excessive
> > >> verification
> > >> >> time problems encountered above?
> > >> >
> > >> >
> > >> > It is very good to hear at last that the sleeps appear to have an
> > >> effect
> > >> on
> > >> > the probability of the bug.
> > >> >
> > >> > I inserted one sleep near startup, in AudacityApp::InitTempDir, and
> > >> another
> > >> > at shut-down, in AudacityApp::OnExit.  In each, I made the duration
> > >> 1000
> > >> > msec.
> > >> >
> > >> > Not yet known:  is the reduced frequency of the problem due to one
> > >> sleep
> > >> or
> > >> > the other, or is the combination necessary?
> > >> >
> > >> > You can easily edit those two occurrences of the number 1000 to
> > >> experiment
> > >> > with longer intervals.
> > >> >
> > >> > If the sleep at exit is the important one, and if you must lengthen
> > >> that
> > >> > from one to several seconds, even so this might be acceptable.  The
> > >> slightly
> > >> > odd-looking consequence might be that the Audacity icon is slow to
> > >> disappear
> > >> > from the dock, but because the single-instance checker has been
> > >> destroyed,
> > >> > that should mean you are not barred from starting up another
> instance
> > >> of
> > >> > Audacity before the first disappears.
> > >> >
> > >> > Surely a longer sleep at exit would be more tolerable than at
> > startup.
> > >>
> > >> It's the startup sleep that mainly helps on my machine, assuming I
> > >> relaunch
> > >> Audacity immediately, rather than wait a while before relaunch, which
> > >> ameliorates the bug.
> > >>
> > >> Increasing the exit sleep to 2000 with no startup sleep makes no
> > >> practical
> > >> difference to the bug that I can see. Increasing exit sleep to 3000 or
> > >> 10000
> > >> with no startup sleep gets me to about 1 in 20 failures launching
> > >> Audacity
> > >> from /Applications and 1 in 5 failures launching from elsewhere (no
> > >> sleeps is about 1 in 15 and 1 in 3 respectively).
> > >>
> > >> If I remove the exit sleep and just have the startup sleep before the
> > >> single
> > >> instance checker, in one set of launches I got the bug at:
> > >>
> > >> 1000 ms = try 29 and 5 respectively
> > >> 2000 ms = try 27 and 8 respectively
> > >> 5000 ms = try 38 and 9 respectively
> > >> 10000 ms = not failed yet in 50 and try 9 respectively
> > >>
> > >> With exit sleep at 3000 and startup sleep at 2000 I failed at 36 and
> 10
> > >> respectively. I did not try other sleep lengths with both sleeps.
> > >>
> > >> Perhaps we could try more sleeps of shorter durations at start up in
> > case
> > >> we don't have the best place yet. How about a sleep before creating
> the
> > >> .audacity.sock file? Other places?
> > >>
> > >> It looks like we may not fully solve Audacity launched from outside
> > >> /Applications unless we act on configuration files inside the bundle.
> > But
> > >> I
> > >> would like you to suggest more and shorter exit sleeps first, or other
> > >> suggestions if you have any.
> > >>
> > >> The fix of force quitting Audacity immediately on launch then letting
> > >> launch
> > >> complete still works, providing I get no lock file created.
> > >>
> > >>
> > >> Gale
> > >>
> > >
> > > Not yet the decisive victory I had been hoping for.
> > >
> > > Let me understand:
> > >
> > >
> > >    - Even unmodified, the program is less likely to suffer the bug if
> > you
> > >    simply pause long enough between relaunches.  So really it's only a
> > >    sequence of rapid relaunches that is the problem.
> >
> > If unmodified 2.1.2 or HEAD, the bug occurs on first launch wherever
> > Audacity is launched from.
> >
> > But if using an unmodified jcx codesigned build, then I see the
> > variability
> > that launching from outside /Applications is more prone to the bug, and
> > that exiting and launching again with no pause is more prone to the bug
> > than waiting between launches.
> >
> > Pausing isn't a total cure, even launching Audacity from /Applications.
> >
> > That made me think of testing File > Close in the build I tested that
> > has exit and starting sleeps. I don't have any issue if I launch Audacity
> > then do COMMAND + W repeatedly without pause. But if I record
> > something then COMMAND + W and don't save changes, this triggered
> > the bug on a couple of occasions. I lost plugins from the menus and lost
> > LAME and FFmpeg.  It did not happen if I said yes to Save Changes,
> > though I only tested twice.
> >
> > As yet, I don't have an issue with that in jc10, running and installed as
> > Admin with its Portable Settings folder present, but I only tested three
> > closes without save and three closes with save. I'd have to test more
> > to say jc10 is immune.
> >
> > Yikes. So I guess clearing out the AutoSave folder is also a potential
> > problem, but saving a project also clears out AutoSave. So does that
> > also point to another timing issue?
> >
> > If someone saves a Chain, is that going to risk triggering the bug,
> > given we write to a Chains folder in the configuration folder?
> >
> >
> > Paul Licameli wrote
> > >    - When it strikes once, it will invariably strike again until either
> > > the
> > >    operating system is rebooted, or you use a quick enough force-quit.
> >
> > Yes.
> >
> >
> > Paul Licameli wrote
> > >    - When you force-quit and try again, this is comparably fast, to a
> > >    normal program exit followed by another try: in other words the
> > timing
> > > of
> > >    your restart in this case, is not an uncontrolled variable.
> >
> > Interesting. I can force quit then start normally as fast as I am
> > physically
> > able, and that always gets rid of the bug.
> >
> > But I just now waited several minutes after force quit, then launched
> > Audacity and the bug is still there. Force-quit, launch at once, and the
> > bug has gone.
> >
> >
> > Paul Licameli wrote
> > > I had a bizarre idea to try next -- perhaps bizarre ideas are needed.
> I
> > > could simulate the force quit.  (By raising SIGTERM.)  I could make
> each
> > > start of Audacity launch a process, which would commit suicide, but
> > start
> > > a
> > > second process.  If there is something just about the starting and
> early
> > > stopping that makes the operating system straighten itself out, who
> > knows,
> > > this might work.
> > >
> > > Here is an implementation.  It does not include any of the previous
> > > attempted fixes.  It does contain a wxMilliSleep of just 1 msec in the
> > > non-crashing process.  You might adjust that number.
> > >
> > > https://github.com/Paul-Licameli/audacity/commit/
> > f0135d99c0f232982fe7fb4b10b68aa0385d9b6a
> >
> > OK Paul I will try it ASAP now I've seen this. I'd have said that sounds
> > hopeful, but there is still the new Close Project issue I would like your
> > opinion on.
> >
> >
> > Gale
> >
> > --
> > View this message in context: http://audacity.238276.n2.
> > nabble.com/Bug-1567-startup-sleeps-tp7577731p7577747.html
> > Sent from the audacity-quality mailing list archive at Nabble
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 1567 startup sleeps

Paul Licameli
Gale,

Here is a variation of the previous idea, implemented much more simply (I remembered the Unix fork() function was what I needed).  Again it has a sleep interval that you might tune.  It differs in that now the first process continues while it is the child process that crashes at once.  I do not see the fleeting second icon on the dock and I have not yet seen the initial window fail to raise itself.

Does this still fix the bug?

https://github.com/Paul-Licameli/audacity/commit/107ec3281c62d030fde4601b93e529edad58e0a7

PRL


On Wed, Jan 11, 2017 at 10:06 AM, Gale <[hidden email]> wrote:
Paul Licameli wrote
> Good news then!
>
> I was aware that Audacity sometimes is not on top after launch.  For you,
> that happens always?
>
> Another weird looking thing is that if I watch the tool dock closely, I
> see
> one fleeting Audacity icon grow and shrink, and then a persistent one.

Yes,  never on top for me. Yes, if I look at the dock I can see that too.

I think the File > Close behaviour is a problem. But saving a Chain does
not trigger the bug as far as I can tell. If I find some other way to
trigger
the bug while Audacity is running I'll let you know.

I modified your previous fix to insert another 1000 ms sleep before the sock
file
(if I did it right). That helped a lot (no failures yet from /Applications,
got to
about 20 tries before failing from outside /Applications). Just in case we
still go another route, but it seems you think the simulated force quit is
safe.


Gale


Paul Licameli wrote
>
> I might fix at least the first of these things.
>
> PRL
>
>
> On Wed, Jan 11, 2017 at 1:12 AM, Gale &lt;

> gale@

> &gt; wrote:
>
>> Paul Licameli wrote
>> > Did you not see my message the first time?  I thought I replied to all.
>> > Well please try this commit.
>> >
>> > PRL
>>
>> No, I see nothing in Gmail from the lists after the 7th, though I did get
>> this
>> message of yours which you Cc'd to me.
>>
>> I built your "weird" fix and at least on my machine, we are getting
>> somewhere
>> at last.
>>
>> I've so far done 40 launches of Audacity from /Applications, and (really
>> good
>> news) 20 from other locations in my user space, without the bug appearing
>> on
>> launch. This is with me downloading and running as admin, relaunching at
>> once or waiting 30 seconds. I can't get to force quit Audacity's Dock
>> icon
>> now -
>> the option disappears too fast.
>>
>> I do still sometimes (50%?) get the bug if I File > Close with some data
>> in
>> the
>> AutoSave folder then don't save the project. Setting the single sleep you
>> added
>> to 5000 ms does not stop the File > Close issue.
>>
>> Quitting and relaunching Audacity removes the bug if File > Close has
>> triggered
>> it, but does not stop it happening again.
>>
>> Three points that may be problematic.
>>
>> * Audacity never comes on top when launched. I have to task switch to it
>> or
>>    touch its Dock icon to see it.
>>
>> * When I launch Audacity, I do see the start of an Audacity menu bar by
>> the
>>    current menu bar which is then replaced by the menu bar of the app
>> that
>> was
>>    on top when I launched Audacity.
>>
>> * There is no splash screen when launching Audacity. I don't know if that
>> is
>> an
>>    issue if e.g. the disk space warning appears that used to clash with
>> the
>>    splash screen.
>>
>>
>> Gale
>>
>>
>> On Tue, Jan 10, 2017 at 5:14 PM, Gale &lt;gale@&gt; wrote:
>>
>> > Sorry, Paul. I've been staring at Gmail for several days wondering why
>> > there
>> > was
>> > no reply, but now I looked on Nabble. There is no trace of the replies
>> in
>> > Gmail
>> > Bin or Spam and no trace of the new posts on -quality since the 7th,
>> hence
>> > I
>> > have not read those yet.
>> >
>> > I am still subscribed to -quality and my delivery enabled according to
>> the
>> > control
>> > panel. I am not receiving -devel either. So at the moment I am pointing
>> > the
>> > finger
>> > at Gmail and will try a desktop client.
>> >
>> >
>> >
>> > Paul Licameli wrote
>> > > On Sat, Jan 7, 2017 at 1:50 PM, Gale Andrews &lt;
>> >
>> > > gale@
>> >
>> > > &gt; wrote:
>> > >
>> > >> On 7 January 2017 at 00:46, Paul Licameli &lt;
>> >
>> > > paul.licameli@
>> >
>> > > &gt; wrote:
>> > >> >> On Fri, Jan 6, 2017 at 5:23 PM, Gale Andrews &lt;
>> >
>> > > gale@
>> >
>> > > &gt;
>> > >> wrote:
>> > >> >> On very brief testing, Paul's sleeps on exit and init as coded
>> make
>> > >> some
>> > >> >> impact on bug 1567 on my machine, without entirely preventing it.
>> I
>> > >> still
>> > >> >> see about 1 in 8 failures if Audacity is launched outside
>> > >> /Applications,
>> > >> >> but
>> > >> >> I can go up to 25 to 40 launches from /Applications before the
>> bug
>> > >> >> triggers.
>> > >> >>
>> > >> >> So I would like to suggest we tweak sleeps further (do we need
>> > retry?)
>> > >> >> and that we won't need the fix of Audacity as single-user with a
>> > >> forced
>> > >> >> Portable Settings folder, or User-Settings as amelioration of
>> that.
>> > If
>> > >> so,
>> > >> >> does that automatically remove the "damaged" and excessive
>> > >> verification
>> > >> >> time problems encountered above?
>> > >> >
>> > >> >
>> > >> > It is very good to hear at last that the sleeps appear to have an
>> > >> effect
>> > >> on
>> > >> > the probability of the bug.
>> > >> >
>> > >> > I inserted one sleep near startup, in AudacityApp::InitTempDir,
>> and
>> > >> another
>> > >> > at shut-down, in AudacityApp::OnExit.  In each, I made the
>> duration
>> > >> 1000
>> > >> > msec.
>> > >> >
>> > >> > Not yet known:  is the reduced frequency of the problem due to one
>> > >> sleep
>> > >> or
>> > >> > the other, or is the combination necessary?
>> > >> >
>> > >> > You can easily edit those two occurrences of the number 1000 to
>> > >> experiment
>> > >> > with longer intervals.
>> > >> >
>> > >> > If the sleep at exit is the important one, and if you must
>> lengthen
>> > >> that
>> > >> > from one to several seconds, even so this might be acceptable.
>> The
>> > >> slightly
>> > >> > odd-looking consequence might be that the Audacity icon is slow to
>> > >> disappear
>> > >> > from the dock, but because the single-instance checker has been
>> > >> destroyed,
>> > >> > that should mean you are not barred from starting up another
>> instance
>> > >> of
>> > >> > Audacity before the first disappears.
>> > >> >
>> > >> > Surely a longer sleep at exit would be more tolerable than at
>> > startup.
>> > >>
>> > >> It's the startup sleep that mainly helps on my machine, assuming I
>> > >> relaunch
>> > >> Audacity immediately, rather than wait a while before relaunch,
>> which
>> > >> ameliorates the bug.
>> > >>
>> > >> Increasing the exit sleep to 2000 with no startup sleep makes no
>> > >> practical
>> > >> difference to the bug that I can see. Increasing exit sleep to 3000
>> or
>> > >> 10000
>> > >> with no startup sleep gets me to about 1 in 20 failures launching
>> > >> Audacity
>> > >> from /Applications and 1 in 5 failures launching from elsewhere (no
>> > >> sleeps is about 1 in 15 and 1 in 3 respectively).
>> > >>
>> > >> If I remove the exit sleep and just have the startup sleep before
>> the
>> > >> single
>> > >> instance checker, in one set of launches I got the bug at:
>> > >>
>> > >> 1000 ms = try 29 and 5 respectively
>> > >> 2000 ms = try 27 and 8 respectively
>> > >> 5000 ms = try 38 and 9 respectively
>> > >> 10000 ms = not failed yet in 50 and try 9 respectively
>> > >>
>> > >> With exit sleep at 3000 and startup sleep at 2000 I failed at 36 and
>> 10
>> > >> respectively. I did not try other sleep lengths with both sleeps.
>> > >>
>> > >> Perhaps we could try more sleeps of shorter durations at start up in
>> > case
>> > >> we don't have the best place yet. How about a sleep before creating
>> the
>> > >> .audacity.sock file? Other places?
>> > >>
>> > >> It looks like we may not fully solve Audacity launched from outside
>> > >> /Applications unless we act on configuration files inside the
>> bundle.
>> > But
>> > >> I
>> > >> would like you to suggest more and shorter exit sleeps first, or
>> other
>> > >> suggestions if you have any.
>> > >>
>> > >> The fix of force quitting Audacity immediately on launch then
>> letting
>> > >> launch
>> > >> complete still works, providing I get no lock file created.
>> > >>
>> > >>
>> > >> Gale
>> > >>
>> > >
>> > > Not yet the decisive victory I had been hoping for.
>> > >
>> > > Let me understand:
>> > >
>> > >
>> > >    - Even unmodified, the program is less likely to suffer the bug if
>> > you
>> > >    simply pause long enough between relaunches.  So really it's only
>> a
>> > >    sequence of rapid relaunches that is the problem.
>> >
>> > If unmodified 2.1.2 or HEAD, the bug occurs on first launch wherever
>> > Audacity is launched from.
>> >
>> > But if using an unmodified jcx codesigned build, then I see the
>> > variability
>> > that launching from outside /Applications is more prone to the bug, and
>> > that exiting and launching again with no pause is more prone to the bug
>> > than waiting between launches.
>> >
>> > Pausing isn't a total cure, even launching Audacity from /Applications.
>> >
>> > That made me think of testing File > Close in the build I tested that
>> > has exit and starting sleeps. I don't have any issue if I launch
>> Audacity
>> > then do COMMAND + W repeatedly without pause. But if I record
>> > something then COMMAND + W and don't save changes, this triggered
>> > the bug on a couple of occasions. I lost plugins from the menus and
>> lost
>> > LAME and FFmpeg.  It did not happen if I said yes to Save Changes,
>> > though I only tested twice.
>> >
>> > As yet, I don't have an issue with that in jc10, running and installed
>> as
>> > Admin with its Portable Settings folder present, but I only tested
>> three
>> > closes without save and three closes with save. I'd have to test more
>> > to say jc10 is immune.
>> >
>> > Yikes. So I guess clearing out the AutoSave folder is also a potential
>> > problem, but saving a project also clears out AutoSave. So does that
>> > also point to another timing issue?
>> >
>> > If someone saves a Chain, is that going to risk triggering the bug,
>> > given we write to a Chains folder in the configuration folder?
>> >
>> >
>> > Paul Licameli wrote
>> > >    - When it strikes once, it will invariably strike again until
>> either
>> > > the
>> > >    operating system is rebooted, or you use a quick enough
>> force-quit.
>> >
>> > Yes.
>> >
>> >
>> > Paul Licameli wrote
>> > >    - When you force-quit and try again, this is comparably fast, to a
>> > >    normal program exit followed by another try: in other words the
>> > timing
>> > > of
>> > >    your restart in this case, is not an uncontrolled variable.
>> >
>> > Interesting. I can force quit then start normally as fast as I am
>> > physically
>> > able, and that always gets rid of the bug.
>> >
>> > But I just now waited several minutes after force quit, then launched
>> > Audacity and the bug is still there. Force-quit, launch at once, and
>> the
>> > bug has gone.
>> >
>> >
>> > Paul Licameli wrote
>> > > I had a bizarre idea to try next -- perhaps bizarre ideas are needed.
>> I
>> > > could simulate the force quit.  (By raising SIGTERM.)  I could make
>> each
>> > > start of Audacity launch a process, which would commit suicide, but
>> > start
>> > > a
>> > > second process.  If there is something just about the starting and
>> early
>> > > stopping that makes the operating system straighten itself out, who
>> > knows,
>> > > this might work.
>> > >
>> > > Here is an implementation.  It does not include any of the previous
>> > > attempted fixes.  It does contain a wxMilliSleep of just 1 msec in
>> the
>> > > non-crashing process.  You might adjust that number.
>> > >
>> > > https://github.com/Paul-Licameli/audacity/commit/
>> > f0135d99c0f232982fe7fb4b10b68aa0385d9b6a
>> >
>> > OK Paul I will try it ASAP now I've seen this. I'd have said that
>> sounds
>> > hopeful, but there is still the new Close Project issue I would like
>> your
>> > opinion on.
>> >
>> >
>> > Gale
>> >
>> > --
>> > View this message in context: http://audacity.238276.n2.
>> > nabble.com/Bug-1567-startup-sleeps-tp7577731p7577747.html
>> > Sent from the audacity-quality mailing list archive at Nabble
>>
>>





--
View this message in context: http://audacity.238276.n2.nabble.com/Bug-1567-startup-sleeps-tp7577731p7577754.html
Sent from the audacity-quality mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 1567 startup sleeps

Gale
Administrator
Paul Licameli wrote
Gale,

Here is a variation of the previous idea, implemented much more simply (I
remembered the Unix fork() function was what I needed).  Again it has a
sleep interval that you might tune.  It differs in that now the first
process continues while it is the child process that crashes at once.  I do
not see the fleeting second icon on the dock and I have not yet seen the
initial window fail to raise itself.

Does this still fix the bug?

https://github.com/Paul-Licameli/audacity/commit/107ec3281c62d030fde4601b93e529edad58e0a7

PRL
Thanks, Paul.

This one is much better for appearance to the user - comes on top, no "ghosts"
in the menu bar or Dock, and splash screen appears.

It doesn't fully quash the bug as it occurs when Audacity launches. I'm back
to failing in about 20 tries when launching Audacity from /Applications and
in about five tries when launching from elsewhere.  Increasing the sleep where
you have it now in the non-crashing process doesn't seem to help.  

So is it a sleep position problem we don't have right yet or must we really
crash the first process? Can a child process run first with a hidden parent
and crash the child? I may be off beam but I have a recollection that the old
VST Effects dialogue that popped up before the Audacity window was a
"child".  

I checked the case of the low space warning appearing, and there is no crash
with this or the previous "weird" fix.  


Gale

On Wed, Jan 11, 2017 at 10:06 AM, Gale <[hidden email]> wrote:

> Paul Licameli wrote
> > Good news then!
> >
> > I was aware that Audacity sometimes is not on top after launch.  For you,
> > that happens always?
> >
> > Another weird looking thing is that if I watch the tool dock closely, I
> > see
> > one fleeting Audacity icon grow and shrink, and then a persistent one.
>
> Yes,  never on top for me. Yes, if I look at the dock I can see that too.
>
> I think the File > Close behaviour is a problem. But saving a Chain does
> not trigger the bug as far as I can tell. If I find some other way to
> trigger
> the bug while Audacity is running I'll let you know.
>
> I modified your previous fix to insert another 1000 ms sleep before the
> sock
> file
> (if I did it right). That helped a lot (no failures yet from /Applications,
> got to
> about 20 tries before failing from outside /Applications). Just in case we
> still go another route, but it seems you think the simulated force quit is
> safe.
>
>
> Gale
>
>
> Paul Licameli wrote
> >
> > I might fix at least the first of these things.
> >
> > PRL
> >
> >
> > On Wed, Jan 11, 2017 at 1:12 AM, Gale <
>
> > gale@
>
> > > wrote:
> >
> >> Paul Licameli wrote
> >> > Did you not see my message the first time?  I thought I replied to
> all.
> >> > Well please try this commit.
> >> >
> >> > PRL
> >>
> >> No, I see nothing in Gmail from the lists after the 7th, though I did
> get
> >> this
> >> message of yours which you Cc'd to me.
> >>
> >> I built your "weird" fix and at least on my machine, we are getting
> >> somewhere
> >> at last.
> >>
> >> I've so far done 40 launches of Audacity from /Applications, and (really
> >> good
> >> news) 20 from other locations in my user space, without the bug
> appearing
> >> on
> >> launch. This is with me downloading and running as admin, relaunching at
> >> once or waiting 30 seconds. I can't get to force quit Audacity's Dock
> >> icon
> >> now -
> >> the option disappears too fast.
> >>
> >> I do still sometimes (50%?) get the bug if I File > Close with some data
> >> in
> >> the
> >> AutoSave folder then don't save the project. Setting the single sleep
> you
> >> added
> >> to 5000 ms does not stop the File > Close issue.
> >>
> >> Quitting and relaunching Audacity removes the bug if File > Close has
> >> triggered
> >> it, but does not stop it happening again.
> >>
> >> Three points that may be problematic.
> >>
> >> * Audacity never comes on top when launched. I have to task switch to it
> >> or
> >>    touch its Dock icon to see it.
> >>
> >> * When I launch Audacity, I do see the start of an Audacity menu bar by
> >> the
> >>    current menu bar which is then replaced by the menu bar of the app
> >> that
> >> was
> >>    on top when I launched Audacity.
> >>
> >> * There is no splash screen when launching Audacity. I don't know if
> that
> >> is
> >> an
> >>    issue if e.g. the disk space warning appears that used to clash with
> >> the
> >>    splash screen.
> >>
> >>
> >> Gale
> >>
> >>
> >> On Tue, Jan 10, 2017 at 5:14 PM, Gale <gale@> wrote:
> >>
> >> > Sorry, Paul. I've been staring at Gmail for several days wondering why
> >> > there
> >> > was
> >> > no reply, but now I looked on Nabble. There is no trace of the replies
> >> in
> >> > Gmail
> >> > Bin or Spam and no trace of the new posts on -quality since the 7th,
> >> hence
> >> > I
> >> > have not read those yet.
> >> >
> >> > I am still subscribed to -quality and my delivery enabled according to
> >> the
> >> > control
> >> > panel. I am not receiving -devel either. So at the moment I am
> pointing
> >> > the
> >> > finger
> >> > at Gmail and will try a desktop client.
> >> >
> >> >
> >> >
> >> > Paul Licameli wrote
> >> > > On Sat, Jan 7, 2017 at 1:50 PM, Gale Andrews <
> >> >
> >> > > gale@
> >> >
> >> > > > wrote:
> >> > >
> >> > >> On 7 January 2017 at 00:46, Paul Licameli <
> >> >
> >> > > paul.licameli@
> >> >
> >> > > > wrote:
> >> > >> >> On Fri, Jan 6, 2017 at 5:23 PM, Gale Andrews <
> >> >
> >> > > gale@
> >> >
> >> > > >
> >> > >> wrote:
> >> > >> >> On very brief testing, Paul's sleeps on exit and init as coded
> >> make
> >> > >> some
> >> > >> >> impact on bug 1567 on my machine, without entirely preventing
> it.
> >> I
> >> > >> still
> >> > >> >> see about 1 in 8 failures if Audacity is launched outside
> >> > >> /Applications,
> >> > >> >> but
> >> > >> >> I can go up to 25 to 40 launches from /Applications before the
> >> bug
> >> > >> >> triggers.
> >> > >> >>
> >> > >> >> So I would like to suggest we tweak sleeps further (do we need
> >> > retry?)
> >> > >> >> and that we won't need the fix of Audacity as single-user with a
> >> > >> forced
> >> > >> >> Portable Settings folder, or User-Settings as amelioration of
> >> that.
> >> > If
> >> > >> so,
> >> > >> >> does that automatically remove the "damaged" and excessive
> >> > >> verification
> >> > >> >> time problems encountered above?
> >> > >> >
> >> > >> >
> >> > >> > It is very good to hear at last that the sleeps appear to have an
> >> > >> effect
> >> > >> on
> >> > >> > the probability of the bug.
> >> > >> >
> >> > >> > I inserted one sleep near startup, in AudacityApp::InitTempDir,
> >> and
> >> > >> another
> >> > >> > at shut-down, in AudacityApp::OnExit.  In each, I made the
> >> duration
> >> > >> 1000
> >> > >> > msec.
> >> > >> >
> >> > >> > Not yet known:  is the reduced frequency of the problem due to
> one
> >> > >> sleep
> >> > >> or
> >> > >> > the other, or is the combination necessary?
> >> > >> >
> >> > >> > You can easily edit those two occurrences of the number 1000 to
> >> > >> experiment
> >> > >> > with longer intervals.
> >> > >> >
> >> > >> > If the sleep at exit is the important one, and if you must
> >> lengthen
> >> > >> that
> >> > >> > from one to several seconds, even so this might be acceptable.
> >> The
> >> > >> slightly
> >> > >> > odd-looking consequence might be that the Audacity icon is slow
> to
> >> > >> disappear
> >> > >> > from the dock, but because the single-instance checker has been
> >> > >> destroyed,
> >> > >> > that should mean you are not barred from starting up another
> >> instance
> >> > >> of
> >> > >> > Audacity before the first disappears.
> >> > >> >
> >> > >> > Surely a longer sleep at exit would be more tolerable than at
> >> > startup.
> >> > >>
> >> > >> It's the startup sleep that mainly helps on my machine, assuming I
> >> > >> relaunch
> >> > >> Audacity immediately, rather than wait a while before relaunch,
> >> which
> >> > >> ameliorates the bug.
> >> > >>
> >> > >> Increasing the exit sleep to 2000 with no startup sleep makes no
> >> > >> practical
> >> > >> difference to the bug that I can see. Increasing exit sleep to 3000
> >> or
> >> > >> 10000
> >> > >> with no startup sleep gets me to about 1 in 20 failures launching
> >> > >> Audacity
> >> > >> from /Applications and 1 in 5 failures launching from elsewhere (no
> >> > >> sleeps is about 1 in 15 and 1 in 3 respectively).
> >> > >>
> >> > >> If I remove the exit sleep and just have the startup sleep before
> >> the
> >> > >> single
> >> > >> instance checker, in one set of launches I got the bug at:
> >> > >>
> >> > >> 1000 ms = try 29 and 5 respectively
> >> > >> 2000 ms = try 27 and 8 respectively
> >> > >> 5000 ms = try 38 and 9 respectively
> >> > >> 10000 ms = not failed yet in 50 and try 9 respectively
> >> > >>
> >> > >> With exit sleep at 3000 and startup sleep at 2000 I failed at 36
> and
> >> 10
> >> > >> respectively. I did not try other sleep lengths with both sleeps.
> >> > >>
> >> > >> Perhaps we could try more sleeps of shorter durations at start up
> in
> >> > case
> >> > >> we don't have the best place yet. How about a sleep before creating
> >> the
> >> > >> .audacity.sock file? Other places?
> >> > >>
> >> > >> It looks like we may not fully solve Audacity launched from outside
> >> > >> /Applications unless we act on configuration files inside the
> >> bundle.
> >> > But
> >> > >> I
> >> > >> would like you to suggest more and shorter exit sleeps first, or
> >> other
> >> > >> suggestions if you have any.
> >> > >>
> >> > >> The fix of force quitting Audacity immediately on launch then
> >> letting
> >> > >> launch
> >> > >> complete still works, providing I get no lock file created.
> >> > >>
> >> > >>
> >> > >> Gale
> >> > >>
> >> > >
> >> > > Not yet the decisive victory I had been hoping for.
> >> > >
> >> > > Let me understand:
> >> > >
> >> > >
> >> > >    - Even unmodified, the program is less likely to suffer the bug
> if
> >> > you
> >> > >    simply pause long enough between relaunches.  So really it's only
> >> a
> >> > >    sequence of rapid relaunches that is the problem.
> >> >
> >> > If unmodified 2.1.2 or HEAD, the bug occurs on first launch wherever
> >> > Audacity is launched from.
> >> >
> >> > But if using an unmodified jcx codesigned build, then I see the
> >> > variability
> >> > that launching from outside /Applications is more prone to the bug,
> and
> >> > that exiting and launching again with no pause is more prone to the
> bug
> >> > than waiting between launches.
> >> >
> >> > Pausing isn't a total cure, even launching Audacity from
> /Applications.
> >> >
> >> > That made me think of testing File > Close in the build I tested that
> >> > has exit and starting sleeps. I don't have any issue if I launch
> >> Audacity
> >> > then do COMMAND + W repeatedly without pause. But if I record
> >> > something then COMMAND + W and don't save changes, this triggered
> >> > the bug on a couple of occasions. I lost plugins from the menus and
> >> lost
> >> > LAME and FFmpeg.  It did not happen if I said yes to Save Changes,
> >> > though I only tested twice.
> >> >
> >> > As yet, I don't have an issue with that in jc10, running and installed
> >> as
> >> > Admin with its Portable Settings folder present, but I only tested
> >> three
> >> > closes without save and three closes with save. I'd have to test more
> >> > to say jc10 is immune.
> >> >
> >> > Yikes. So I guess clearing out the AutoSave folder is also a potential
> >> > problem, but saving a project also clears out AutoSave. So does that
> >> > also point to another timing issue?
> >> >
> >> > If someone saves a Chain, is that going to risk triggering the bug,
> >> > given we write to a Chains folder in the configuration folder?
> >> >
> >> >
> >> > Paul Licameli wrote
> >> > >    - When it strikes once, it will invariably strike again until
> >> either
> >> > > the
> >> > >    operating system is rebooted, or you use a quick enough
> >> force-quit.
> >> >
> >> > Yes.
> >> >
> >> >
> >> > Paul Licameli wrote
> >> > >    - When you force-quit and try again, this is comparably fast, to
> a
> >> > >    normal program exit followed by another try: in other words the
> >> > timing
> >> > > of
> >> > >    your restart in this case, is not an uncontrolled variable.
> >> >
> >> > Interesting. I can force quit then start normally as fast as I am
> >> > physically
> >> > able, and that always gets rid of the bug.
> >> >
> >> > But I just now waited several minutes after force quit, then launched
> >> > Audacity and the bug is still there. Force-quit, launch at once, and
> >> the
> >> > bug has gone.
> >> >
> >> >
> >> > Paul Licameli wrote
> >> > > I had a bizarre idea to try next -- perhaps bizarre ideas are
> needed.
> >> I
> >> > > could simulate the force quit.  (By raising SIGTERM.)  I could make
> >> each
> >> > > start of Audacity launch a process, which would commit suicide, but
> >> > start
> >> > > a
> >> > > second process.  If there is something just about the starting and
> >> early
> >> > > stopping that makes the operating system straighten itself out, who
> >> > knows,
> >> > > this might work.
> >> > >
> >> > > Here is an implementation.  It does not include any of the previous
> >> > > attempted fixes.  It does contain a wxMilliSleep of just 1 msec in
> >> the
> >> > > non-crashing process.  You might adjust that number.
> >> > >
> >> > > https://github.com/Paul-Licameli/audacity/commit/
> >> > f0135d99c0f232982fe7fb4b10b68aa0385d9b6a
> >> >
> >> > OK Paul I will try it ASAP now I've seen this. I'd have said that
> >> sounds
> >> > hopeful, but there is still the new Close Project issue I would like
> >> your
> >> > opinion on.
> >> >
> >> >
> >> > Gale
> >> >
> >> > --
> >> > View this message in context: http://audacity.238276.n2.
> >> > nabble.com/Bug-1567-startup-sleeps-tp7577731p7577747.html
> >> > Sent from the audacity-quality mailing list archive at Nabble
> >>
> >>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 1567 startup sleeps

Paul Licameli
Gale, here is my next iteration:

https://github.com/Paul-Licameli/audacity/commit/05e38f44b617577deb6840ec5a8247272e3d3c7f

At this commit, you have three more commits since the previous tip of my bug1567-weird2 branch.

The first commit moves the fork() to an earlier point, in main(), but still it is the child process that crashes and the original that continues.  I don't expect this is worth experiments yet:  probably the same results as most recently.

The second commit makes the child continue and the parent crash.  I predict that this would fix bug 1567, just as well as the bug1567-weird branch did, with the same problems with the windows.  But I prefer this implementation over the first attempt.

The third commit, linked above, adds an Objective-C call to guarantee that our windows come out on top.  It worked for me, while without these calls I did have the lowered windows at least sometimes.

I suggest you test the third commit above, and if you are wholly satisfied with it, we don't need to bother testing the previous stages.

Do I understand from your answer that even in bug1567-weird, which seemed best yet but for the window problems -- the bug still appeared sometimes, BUT it is no longer necessary to reboot macOS to clear it?  That restarting Audacity is now enough?

PRL



On Thu, Jan 12, 2017 at 9:09 PM, Gale <[hidden email]> wrote:
Paul Licameli wrote
> Gale,
>
> Here is a variation of the previous idea, implemented much more simply (I
> remembered the Unix fork() function was what I needed).  Again it has a
> sleep interval that you might tune.  It differs in that now the first
> process continues while it is the child process that crashes at once.  I
> do
> not see the fleeting second icon on the dock and I have not yet seen the
> initial window fail to raise itself.
>
> Does this still fix the bug?
>
> https://github.com/Paul-Licameli/audacity/commit/107ec3281c62d030fde4601b93e529edad58e0a7
>
> PRL

Thanks, Paul.

This one is much better for appearance to the user - comes on top, no
"ghosts"
in the menu bar or Dock, and splash screen appears.

It doesn't fully quash the bug as it occurs when Audacity launches. I'm back
to failing in about 20 tries when launching Audacity from /Applications and
in about five tries when launching from elsewhere.  Increasing the sleep
where
you have it now in the non-crashing process doesn't seem to help.

So is it a sleep position problem we don't have right yet or must we really
crash the first process? Can a child process run first with a hidden parent
and crash the child? I may be off beam but I have a recollection that the
old
VST Effects dialogue that popped up before the Audacity window was a
"child".

I checked the case of the low space warning appearing, and there is no crash
with this or the previous "weird" fix.


Gale

On Wed, Jan 11, 2017 at 10:06 AM, Gale &lt;gale@&gt; wrote:

> Paul Licameli wrote
> > Good news then!
> >
> > I was aware that Audacity sometimes is not on top after launch.  For
> you,
> > that happens always?
> >
> > Another weird looking thing is that if I watch the tool dock closely, I
> > see
> > one fleeting Audacity icon grow and shrink, and then a persistent one.
>
> Yes,  never on top for me. Yes, if I look at the dock I can see that too.
>
> I think the File > Close behaviour is a problem. But saving a Chain does
> not trigger the bug as far as I can tell. If I find some other way to
> trigger
> the bug while Audacity is running I'll let you know.
>
> I modified your previous fix to insert another 1000 ms sleep before the
> sock
> file
> (if I did it right). That helped a lot (no failures yet from
> /Applications,
> got to
> about 20 tries before failing from outside /Applications). Just in case we
> still go another route, but it seems you think the simulated force quit is
> safe.
>
>
> Gale
>
>
> Paul Licameli wrote
> >
> > I might fix at least the first of these things.
> >
> > PRL
> >
> >
> > On Wed, Jan 11, 2017 at 1:12 AM, Gale &lt;
>
> > gale@
>
> > &gt; wrote:
> >
> >> Paul Licameli wrote
> >> > Did you not see my message the first time?  I thought I replied to
> all.
> >> > Well please try this commit.
> >> >
> >> > PRL
> >>
> >> No, I see nothing in Gmail from the lists after the 7th, though I did
> get
> >> this
> >> message of yours which you Cc'd to me.
> >>
> >> I built your "weird" fix and at least on my machine, we are getting
> >> somewhere
> >> at last.
> >>
> >> I've so far done 40 launches of Audacity from /Applications, and
> (really
> >> good
> >> news) 20 from other locations in my user space, without the bug
> appearing
> >> on
> >> launch. This is with me downloading and running as admin, relaunching
> at
> >> once or waiting 30 seconds. I can't get to force quit Audacity's Dock
> >> icon
> >> now -
> >> the option disappears too fast.
> >>
> >> I do still sometimes (50%?) get the bug if I File > Close with some
> data
> >> in
> >> the
> >> AutoSave folder then don't save the project. Setting the single sleep
> you
> >> added
> >> to 5000 ms does not stop the File > Close issue.
> >>
> >> Quitting and relaunching Audacity removes the bug if File > Close has
> >> triggered
> >> it, but does not stop it happening again.
> >>
> >> Three points that may be problematic.
> >>
> >> * Audacity never comes on top when launched. I have to task switch to
> it
> >> or
> >>    touch its Dock icon to see it.
> >>
> >> * When I launch Audacity, I do see the start of an Audacity menu bar by
> >> the
> >>    current menu bar which is then replaced by the menu bar of the app
> >> that
> >> was
> >>    on top when I launched Audacity.
> >>
> >> * There is no splash screen when launching Audacity. I don't know if
> that
> >> is
> >> an
> >>    issue if e.g. the disk space warning appears that used to clash with
> >> the
> >>    splash screen.
> >>
> >>
> >> Gale
> >>
> >>
> >> On Tue, Jan 10, 2017 at 5:14 PM, Gale &lt;gale@&gt; wrote:
> >>
> >> > Sorry, Paul. I've been staring at Gmail for several days wondering
> why
> >> > there
> >> > was
> >> > no reply, but now I looked on Nabble. There is no trace of the
> replies
> >> in
> >> > Gmail
> >> > Bin or Spam and no trace of the new posts on -quality since the 7th,
> >> hence
> >> > I
> >> > have not read those yet.
> >> >
> >> > I am still subscribed to -quality and my delivery enabled according
> to
> >> the
> >> > control
> >> > panel. I am not receiving -devel either. So at the moment I am
> pointing
> >> > the
> >> > finger
> >> > at Gmail and will try a desktop client.
> >> >
> >> >
> >> >
> >> > Paul Licameli wrote
> >> > > On Sat, Jan 7, 2017 at 1:50 PM, Gale Andrews &lt;
> >> >
> >> > > gale@
> >> >
> >> > > &gt; wrote:
> >> > >
> >> > >> On 7 January 2017 at 00:46, Paul Licameli &lt;
> >> >
> >> > > paul.licameli@
> >> >
> >> > > &gt; wrote:
> >> > >> >> On Fri, Jan 6, 2017 at 5:23 PM, Gale Andrews &lt;
> >> >
> >> > > gale@
> >> >
> >> > > &gt;
> >> > >> wrote:
> >> > >> >> On very brief testing, Paul's sleeps on exit and init as coded
> >> make
> >> > >> some
> >> > >> >> impact on bug 1567 on my machine, without entirely preventing
> it.
> >> I
> >> > >> still
> >> > >> >> see about 1 in 8 failures if Audacity is launched outside
> >> > >> /Applications,
> >> > >> >> but
> >> > >> >> I can go up to 25 to 40 launches from /Applications before the
> >> bug
> >> > >> >> triggers.
> >> > >> >>
> >> > >> >> So I would like to suggest we tweak sleeps further (do we need
> >> > retry?)
> >> > >> >> and that we won't need the fix of Audacity as single-user with
> a
> >> > >> forced
> >> > >> >> Portable Settings folder, or User-Settings as amelioration of
> >> that.
> >> > If
> >> > >> so,
> >> > >> >> does that automatically remove the "damaged" and excessive
> >> > >> verification
> >> > >> >> time problems encountered above?
> >> > >> >
> >> > >> >
> >> > >> > It is very good to hear at last that the sleeps appear to have
> an
> >> > >> effect
> >> > >> on
> >> > >> > the probability of the bug.
> >> > >> >
> >> > >> > I inserted one sleep near startup, in AudacityApp::InitTempDir,
> >> and
> >> > >> another
> >> > >> > at shut-down, in AudacityApp::OnExit.  In each, I made the
> >> duration
> >> > >> 1000
> >> > >> > msec.
> >> > >> >
> >> > >> > Not yet known:  is the reduced frequency of the problem due to
> one
> >> > >> sleep
> >> > >> or
> >> > >> > the other, or is the combination necessary?
> >> > >> >
> >> > >> > You can easily edit those two occurrences of the number 1000 to
> >> > >> experiment
> >> > >> > with longer intervals.
> >> > >> >
> >> > >> > If the sleep at exit is the important one, and if you must
> >> lengthen
> >> > >> that
> >> > >> > from one to several seconds, even so this might be acceptable.
> >> The
> >> > >> slightly
> >> > >> > odd-looking consequence might be that the Audacity icon is slow
> to
> >> > >> disappear
> >> > >> > from the dock, but because the single-instance checker has been
> >> > >> destroyed,
> >> > >> > that should mean you are not barred from starting up another
> >> instance
> >> > >> of
> >> > >> > Audacity before the first disappears.
> >> > >> >
> >> > >> > Surely a longer sleep at exit would be more tolerable than at
> >> > startup.
> >> > >>
> >> > >> It's the startup sleep that mainly helps on my machine, assuming I
> >> > >> relaunch
> >> > >> Audacity immediately, rather than wait a while before relaunch,
> >> which
> >> > >> ameliorates the bug.
> >> > >>
> >> > >> Increasing the exit sleep to 2000 with no startup sleep makes no
> >> > >> practical
> >> > >> difference to the bug that I can see. Increasing exit sleep to
> 3000
> >> or
> >> > >> 10000
> >> > >> with no startup sleep gets me to about 1 in 20 failures launching
> >> > >> Audacity
> >> > >> from /Applications and 1 in 5 failures launching from elsewhere
> (no
> >> > >> sleeps is about 1 in 15 and 1 in 3 respectively).
> >> > >>
> >> > >> If I remove the exit sleep and just have the startup sleep before
> >> the
> >> > >> single
> >> > >> instance checker, in one set of launches I got the bug at:
> >> > >>
> >> > >> 1000 ms = try 29 and 5 respectively
> >> > >> 2000 ms = try 27 and 8 respectively
> >> > >> 5000 ms = try 38 and 9 respectively
> >> > >> 10000 ms = not failed yet in 50 and try 9 respectively
> >> > >>
> >> > >> With exit sleep at 3000 and startup sleep at 2000 I failed at 36
> and
> >> 10
> >> > >> respectively. I did not try other sleep lengths with both sleeps.
> >> > >>
> >> > >> Perhaps we could try more sleeps of shorter durations at start up
> in
> >> > case
> >> > >> we don't have the best place yet. How about a sleep before
> creating
> >> the
> >> > >> .audacity.sock file? Other places?
> >> > >>
> >> > >> It looks like we may not fully solve Audacity launched from
> outside
> >> > >> /Applications unless we act on configuration files inside the
> >> bundle.
> >> > But
> >> > >> I
> >> > >> would like you to suggest more and shorter exit sleeps first, or
> >> other
> >> > >> suggestions if you have any.
> >> > >>
> >> > >> The fix of force quitting Audacity immediately on launch then
> >> letting
> >> > >> launch
> >> > >> complete still works, providing I get no lock file created.
> >> > >>
> >> > >>
> >> > >> Gale
> >> > >>
> >> > >
> >> > > Not yet the decisive victory I had been hoping for.
> >> > >
> >> > > Let me understand:
> >> > >
> >> > >
> >> > >    - Even unmodified, the program is less likely to suffer the bug
> if
> >> > you
> >> > >    simply pause long enough between relaunches.  So really it's
> only
> >> a
> >> > >    sequence of rapid relaunches that is the problem.
> >> >
> >> > If unmodified 2.1.2 or HEAD, the bug occurs on first launch wherever
> >> > Audacity is launched from.
> >> >
> >> > But if using an unmodified jcx codesigned build, then I see the
> >> > variability
> >> > that launching from outside /Applications is more prone to the bug,
> and
> >> > that exiting and launching again with no pause is more prone to the
> bug
> >> > than waiting between launches.
> >> >
> >> > Pausing isn't a total cure, even launching Audacity from
> /Applications.
> >> >
> >> > That made me think of testing File > Close in the build I tested that
> >> > has exit and starting sleeps. I don't have any issue if I launch
> >> Audacity
> >> > then do COMMAND + W repeatedly without pause. But if I record
> >> > something then COMMAND + W and don't save changes, this triggered
> >> > the bug on a couple of occasions. I lost plugins from the menus and
> >> lost
> >> > LAME and FFmpeg.  It did not happen if I said yes to Save Changes,
> >> > though I only tested twice.
> >> >
> >> > As yet, I don't have an issue with that in jc10, running and
> installed
> >> as
> >> > Admin with its Portable Settings folder present, but I only tested
> >> three
> >> > closes without save and three closes with save. I'd have to test more
> >> > to say jc10 is immune.
> >> >
> >> > Yikes. So I guess clearing out the AutoSave folder is also a
> potential
> >> > problem, but saving a project also clears out AutoSave. So does that
> >> > also point to another timing issue?
> >> >
> >> > If someone saves a Chain, is that going to risk triggering the bug,
> >> > given we write to a Chains folder in the configuration folder?
> >> >
> >> >
> >> > Paul Licameli wrote
> >> > >    - When it strikes once, it will invariably strike again until
> >> either
> >> > > the
> >> > >    operating system is rebooted, or you use a quick enough
> >> force-quit.
> >> >
> >> > Yes.
> >> >
> >> >
> >> > Paul Licameli wrote
> >> > >    - When you force-quit and try again, this is comparably fast, to
> a
> >> > >    normal program exit followed by another try: in other words the
> >> > timing
> >> > > of
> >> > >    your restart in this case, is not an uncontrolled variable.
> >> >
> >> > Interesting. I can force quit then start normally as fast as I am
> >> > physically
> >> > able, and that always gets rid of the bug.
> >> >
> >> > But I just now waited several minutes after force quit, then launched
> >> > Audacity and the bug is still there. Force-quit, launch at once, and
> >> the
> >> > bug has gone.
> >> >
> >> >
> >> > Paul Licameli wrote
> >> > > I had a bizarre idea to try next -- perhaps bizarre ideas are
> needed.
> >> I
> >> > > could simulate the force quit.  (By raising SIGTERM.)  I could make
> >> each
> >> > > start of Audacity launch a process, which would commit suicide, but
> >> > start
> >> > > a
> >> > > second process.  If there is something just about the starting and
> >> early
> >> > > stopping that makes the operating system straighten itself out, who
> >> > knows,
> >> > > this might work.
> >> > >
> >> > > Here is an implementation.  It does not include any of the previous
> >> > > attempted fixes.  It does contain a wxMilliSleep of just 1 msec in
> >> the
> >> > > non-crashing process.  You might adjust that number.
> >> > >
> >> > > https://github.com/Paul-Licameli/audacity/commit/
> >> > f0135d99c0f232982fe7fb4b10b68aa0385d9b6a
> >> >
> >> > OK Paul I will try it ASAP now I've seen this. I'd have said that
> >> sounds
> >> > hopeful, but there is still the new Close Project issue I would like
> >> your
> >> > opinion on.
> >> >
> >> >
> >> > Gale
> >> >
> >> > --
> >> > View this message in context: http://audacity.238276.n2.
> >> > nabble.com/Bug-1567-startup-sleeps-tp7577731p7577747.html
> >> > Sent from the audacity-quality mailing list archive at Nabble
> >>
> >>





--
View this message in context: http://audacity.238276.n2.nabble.com/Bug-1567-startup-sleeps-tp7577731p7577774.html
Sent from the audacity-quality mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 1567 startup sleeps

Paul Licameli
Gale, I had to move the call to execve in main for my latest experiment.

Reseach in code history shows this comes from commit  36361a6b86dac4b0f2b16b7017007b4cc7717c7a


And I don't really understand the reason for this execve call, but comments show this change was also related to the loading of LAME and FFmpeg libraries.

I wonder now what the effect of simply deleting the execve call from master head would be on bug 1567?

PRL



On Fri, Jan 13, 2017 at 11:15 AM, Paul Licameli <[hidden email]> wrote:
Gale, here is my next iteration:

https://github.com/Paul-Licameli/audacity/commit/05e38f44b617577deb6840ec5a8247272e3d3c7f

At this commit, you have three more commits since the previous tip of my bug1567-weird2 branch.

The first commit moves the fork() to an earlier point, in main(), but still it is the child process that crashes and the original that continues.  I don't expect this is worth experiments yet:  probably the same results as most recently.

The second commit makes the child continue and the parent crash.  I predict that this would fix bug 1567, just as well as the bug1567-weird branch did, with the same problems with the windows.  But I prefer this implementation over the first attempt.

The third commit, linked above, adds an Objective-C call to guarantee that our windows come out on top.  It worked for me, while without these calls I did have the lowered windows at least sometimes.

I suggest you test the third commit above, and if you are wholly satisfied with it, we don't need to bother testing the previous stages.

Do I understand from your answer that even in bug1567-weird, which seemed best yet but for the window problems -- the bug still appeared sometimes, BUT it is no longer necessary to reboot macOS to clear it?  That restarting Audacity is now enough?

PRL



On Thu, Jan 12, 2017 at 9:09 PM, Gale <[hidden email]> wrote:
Paul Licameli wrote
> Gale,
>
> Here is a variation of the previous idea, implemented much more simply (I
> remembered the Unix fork() function was what I needed).  Again it has a
> sleep interval that you might tune.  It differs in that now the first
> process continues while it is the child process that crashes at once.  I
> do
> not see the fleeting second icon on the dock and I have not yet seen the
> initial window fail to raise itself.
>
> Does this still fix the bug?
>
> https://github.com/Paul-Licameli/audacity/commit/107ec3281c62d030fde4601b93e529edad58e0a7
>
> PRL

Thanks, Paul.

This one is much better for appearance to the user - comes on top, no
"ghosts"
in the menu bar or Dock, and splash screen appears.

It doesn't fully quash the bug as it occurs when Audacity launches. I'm back
to failing in about 20 tries when launching Audacity from /Applications and
in about five tries when launching from elsewhere.  Increasing the sleep
where
you have it now in the non-crashing process doesn't seem to help.

So is it a sleep position problem we don't have right yet or must we really
crash the first process? Can a child process run first with a hidden parent
and crash the child? I may be off beam but I have a recollection that the
old
VST Effects dialogue that popped up before the Audacity window was a
"child".

I checked the case of the low space warning appearing, and there is no crash
with this or the previous "weird" fix.


Gale

On Wed, Jan 11, 2017 at 10:06 AM, Gale &lt;gale@&gt; wrote:

> Paul Licameli wrote
> > Good news then!
> >
> > I was aware that Audacity sometimes is not on top after launch.  For
> you,
> > that happens always?
> >
> > Another weird looking thing is that if I watch the tool dock closely, I
> > see
> > one fleeting Audacity icon grow and shrink, and then a persistent one.
>
> Yes,  never on top for me. Yes, if I look at the dock I can see that too.
>
> I think the File > Close behaviour is a problem. But saving a Chain does
> not trigger the bug as far as I can tell. If I find some other way to
> trigger
> the bug while Audacity is running I'll let you know.
>
> I modified your previous fix to insert another 1000 ms sleep before the
> sock
> file
> (if I did it right). That helped a lot (no failures yet from
> /Applications,
> got to
> about 20 tries before failing from outside /Applications). Just in case we
> still go another route, but it seems you think the simulated force quit is
> safe.
>
>
> Gale
>
>
> Paul Licameli wrote
> >
> > I might fix at least the first of these things.
> >
> > PRL
> >
> >
> > On Wed, Jan 11, 2017 at 1:12 AM, Gale &lt;
>
> > gale@
>
> > &gt; wrote:
> >
> >> Paul Licameli wrote
> >> > Did you not see my message the first time?  I thought I replied to
> all.
> >> > Well please try this commit.
> >> >
> >> > PRL
> >>
> >> No, I see nothing in Gmail from the lists after the 7th, though I did
> get
> >> this
> >> message of yours which you Cc'd to me.
> >>
> >> I built your "weird" fix and at least on my machine, we are getting
> >> somewhere
> >> at last.
> >>
> >> I've so far done 40 launches of Audacity from /Applications, and
> (really
> >> good
> >> news) 20 from other locations in my user space, without the bug
> appearing
> >> on
> >> launch. This is with me downloading and running as admin, relaunching
> at
> >> once or waiting 30 seconds. I can't get to force quit Audacity's Dock
> >> icon
> >> now -
> >> the option disappears too fast.
> >>
> >> I do still sometimes (50%?) get the bug if I File > Close with some
> data
> >> in
> >> the
> >> AutoSave folder then don't save the project. Setting the single sleep
> you
> >> added
> >> to 5000 ms does not stop the File > Close issue.
> >>
> >> Quitting and relaunching Audacity removes the bug if File > Close has
> >> triggered
> >> it, but does not stop it happening again.
> >>
> >> Three points that may be problematic.
> >>
> >> * Audacity never comes on top when launched. I have to task switch to
> it
> >> or
> >>    touch its Dock icon to see it.
> >>
> >> * When I launch Audacity, I do see the start of an Audacity menu bar by
> >> the
> >>    current menu bar which is then replaced by the menu bar of the app
> >> that
> >> was
> >>    on top when I launched Audacity.
> >>
> >> * There is no splash screen when launching Audacity. I don't know if
> that
> >> is
> >> an
> >>    issue if e.g. the disk space warning appears that used to clash with
> >> the
> >>    splash screen.
> >>
> >>
> >> Gale
> >>
> >>
> >> On Tue, Jan 10, 2017 at 5:14 PM, Gale &lt;gale@&gt; wrote:
> >>
> >> > Sorry, Paul. I've been staring at Gmail for several days wondering
> why
> >> > there
> >> > was
> >> > no reply, but now I looked on Nabble. There is no trace of the
> replies
> >> in
> >> > Gmail
> >> > Bin or Spam and no trace of the new posts on -quality since the 7th,
> >> hence
> >> > I
> >> > have not read those yet.
> >> >
> >> > I am still subscribed to -quality and my delivery enabled according
> to
> >> the
> >> > control
> >> > panel. I am not receiving -devel either. So at the moment I am
> pointing
> >> > the
> >> > finger
> >> > at Gmail and will try a desktop client.
> >> >
> >> >
> >> >
> >> > Paul Licameli wrote
> >> > > On Sat, Jan 7, 2017 at 1:50 PM, Gale Andrews &lt;
> >> >
> >> > > gale@
> >> >
> >> > > &gt; wrote:
> >> > >
> >> > >> On 7 January 2017 at 00:46, Paul Licameli &lt;
> >> >
> >> > > paul.licameli@
> >> >
> >> > > &gt; wrote:
> >> > >> >> On Fri, Jan 6, 2017 at 5:23 PM, Gale Andrews &lt;
> >> >
> >> > > gale@
> >> >
> >> > > &gt;
> >> > >> wrote:
> >> > >> >> On very brief testing, Paul's sleeps on exit and init as coded
> >> make
> >> > >> some
> >> > >> >> impact on bug 1567 on my machine, without entirely preventing
> it.
> >> I
> >> > >> still
> >> > >> >> see about 1 in 8 failures if Audacity is launched outside
> >> > >> /Applications,
> >> > >> >> but
> >> > >> >> I can go up to 25 to 40 launches from /Applications before the
> >> bug
> >> > >> >> triggers.
> >> > >> >>
> >> > >> >> So I would like to suggest we tweak sleeps further (do we need
> >> > retry?)
> >> > >> >> and that we won't need the fix of Audacity as single-user with
> a
> >> > >> forced
> >> > >> >> Portable Settings folder, or User-Settings as amelioration of
> >> that.
> >> > If
> >> > >> so,
> >> > >> >> does that automatically remove the "damaged" and excessive
> >> > >> verification
> >> > >> >> time problems encountered above?
> >> > >> >
> >> > >> >
> >> > >> > It is very good to hear at last that the sleeps appear to have
> an
> >> > >> effect
> >> > >> on
> >> > >> > the probability of the bug.
> >> > >> >
> >> > >> > I inserted one sleep near startup, in AudacityApp::InitTempDir,
> >> and
> >> > >> another
> >> > >> > at shut-down, in AudacityApp::OnExit.  In each, I made the
> >> duration
> >> > >> 1000
> >> > >> > msec.
> >> > >> >
> >> > >> > Not yet known:  is the reduced frequency of the problem due to
> one
> >> > >> sleep
> >> > >> or
> >> > >> > the other, or is the combination necessary?
> >> > >> >
> >> > >> > You can easily edit those two occurrences of the number 1000 to
> >> > >> experiment
> >> > >> > with longer intervals.
> >> > >> >
> >> > >> > If the sleep at exit is the important one, and if you must
> >> lengthen
> >> > >> that
> >> > >> > from one to several seconds, even so this might be acceptable.
> >> The
> >> > >> slightly
> >> > >> > odd-looking consequence might be that the Audacity icon is slow
> to
> >> > >> disappear
> >> > >> > from the dock, but because the single-instance checker has been
> >> > >> destroyed,
> >> > >> > that should mean you are not barred from starting up another
> >> instance
> >> > >> of
> >> > >> > Audacity before the first disappears.
> >> > >> >
> >> > >> > Surely a longer sleep at exit would be more tolerable than at
> >> > startup.
> >> > >>
> >> > >> It's the startup sleep that mainly helps on my machine, assuming I
> >> > >> relaunch
> >> > >> Audacity immediately, rather than wait a while before relaunch,
> >> which
> >> > >> ameliorates the bug.
> >> > >>
> >> > >> Increasing the exit sleep to 2000 with no startup sleep makes no
> >> > >> practical
> >> > >> difference to the bug that I can see. Increasing exit sleep to
> 3000
> >> or
> >> > >> 10000
> >> > >> with no startup sleep gets me to about 1 in 20 failures launching
> >> > >> Audacity
> >> > >> from /Applications and 1 in 5 failures launching from elsewhere
> (no
> >> > >> sleeps is about 1 in 15 and 1 in 3 respectively).
> >> > >>
> >> > >> If I remove the exit sleep and just have the startup sleep before
> >> the
> >> > >> single
> >> > >> instance checker, in one set of launches I got the bug at:
> >> > >>
> >> > >> 1000 ms = try 29 and 5 respectively
> >> > >> 2000 ms = try 27 and 8 respectively
> >> > >> 5000 ms = try 38 and 9 respectively
> >> > >> 10000 ms = not failed yet in 50 and try 9 respectively
> >> > >>
> >> > >> With exit sleep at 3000 and startup sleep at 2000 I failed at 36
> and
> >> 10
> >> > >> respectively. I did not try other sleep lengths with both sleeps.
> >> > >>
> >> > >> Perhaps we could try more sleeps of shorter durations at start up
> in
> >> > case
> >> > >> we don't have the best place yet. How about a sleep before
> creating
> >> the
> >> > >> .audacity.sock file? Other places?
> >> > >>
> >> > >> It looks like we may not fully solve Audacity launched from
> outside
> >> > >> /Applications unless we act on configuration files inside the
> >> bundle.
> >> > But
> >> > >> I
> >> > >> would like you to suggest more and shorter exit sleeps first, or
> >> other
> >> > >> suggestions if you have any.
> >> > >>
> >> > >> The fix of force quitting Audacity immediately on launch then
> >> letting
> >> > >> launch
> >> > >> complete still works, providing I get no lock file created.
> >> > >>
> >> > >>
> >> > >> Gale
> >> > >>
> >> > >
> >> > > Not yet the decisive victory I had been hoping for.
> >> > >
> >> > > Let me understand:
> >> > >
> >> > >
> >> > >    - Even unmodified, the program is less likely to suffer the bug
> if
> >> > you
> >> > >    simply pause long enough between relaunches.  So really it's
> only
> >> a
> >> > >    sequence of rapid relaunches that is the problem.
> >> >
> >> > If unmodified 2.1.2 or HEAD, the bug occurs on first launch wherever
> >> > Audacity is launched from.
> >> >
> >> > But if using an unmodified jcx codesigned build, then I see the
> >> > variability
> >> > that launching from outside /Applications is more prone to the bug,
> and
> >> > that exiting and launching again with no pause is more prone to the
> bug
> >> > than waiting between launches.
> >> >
> >> > Pausing isn't a total cure, even launching Audacity from
> /Applications.
> >> >
> >> > That made me think of testing File > Close in the build I tested that
> >> > has exit and starting sleeps. I don't have any issue if I launch
> >> Audacity
> >> > then do COMMAND + W repeatedly without pause. But if I record
> >> > something then COMMAND + W and don't save changes, this triggered
> >> > the bug on a couple of occasions. I lost plugins from the menus and
> >> lost
> >> > LAME and FFmpeg.  It did not happen if I said yes to Save Changes,
> >> > though I only tested twice.
> >> >
> >> > As yet, I don't have an issue with that in jc10, running and
> installed
> >> as
> >> > Admin with its Portable Settings folder present, but I only tested
> >> three
> >> > closes without save and three closes with save. I'd have to test more
> >> > to say jc10 is immune.
> >> >
> >> > Yikes. So I guess clearing out the AutoSave folder is also a
> potential
> >> > problem, but saving a project also clears out AutoSave. So does that
> >> > also point to another timing issue?
> >> >
> >> > If someone saves a Chain, is that going to risk triggering the bug,
> >> > given we write to a Chains folder in the configuration folder?
> >> >
> >> >
> >> > Paul Licameli wrote
> >> > >    - When it strikes once, it will invariably strike again until
> >> either
> >> > > the
> >> > >    operating system is rebooted, or you use a quick enough
> >> force-quit.
> >> >
> >> > Yes.
> >> >
> >> >
> >> > Paul Licameli wrote
> >> > >    - When you force-quit and try again, this is comparably fast, to
> a
> >> > >    normal program exit followed by another try: in other words the
> >> > timing
> >> > > of
> >> > >    your restart in this case, is not an uncontrolled variable.
> >> >
> >> > Interesting. I can force quit then start normally as fast as I am
> >> > physically
> >> > able, and that always gets rid of the bug.
> >> >
> >> > But I just now waited several minutes after force quit, then launched
> >> > Audacity and the bug is still there. Force-quit, launch at once, and
> >> the
> >> > bug has gone.
> >> >
> >> >
> >> > Paul Licameli wrote
> >> > > I had a bizarre idea to try next -- perhaps bizarre ideas are
> needed.
> >> I
> >> > > could simulate the force quit.  (By raising SIGTERM.)  I could make
> >> each
> >> > > start of Audacity launch a process, which would commit suicide, but
> >> > start
> >> > > a
> >> > > second process.  If there is something just about the starting and
> >> early
> >> > > stopping that makes the operating system straighten itself out, who
> >> > knows,
> >> > > this might work.
> >> > >
> >> > > Here is an implementation.  It does not include any of the previous
> >> > > attempted fixes.  It does contain a wxMilliSleep of just 1 msec in
> >> the
> >> > > non-crashing process.  You might adjust that number.
> >> > >
> >> > > https://github.com/Paul-Licameli/audacity/commit/
> >> > f0135d99c0f232982fe7fb4b10b68aa0385d9b6a
> >> >
> >> > OK Paul I will try it ASAP now I've seen this. I'd have said that
> >> sounds
> >> > hopeful, but there is still the new Close Project issue I would like
> >> your
> >> > opinion on.
> >> >
> >> >
> >> > Gale
> >> >
> >> > --
> >> > View this message in context: http://audacity.238276.n2.
> >> > nabble.com/Bug-1567-startup-sleeps-tp7577731p7577747.html
> >> > Sent from the audacity-quality mailing list archive at Nabble
> >>
> >>





--
View this message in context: http://audacity.238276.n2.nabble.com/Bug-1567-startup-sleeps-tp7577731p7577774.html
Sent from the audacity-quality mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality



------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 1567 startup sleeps

Gale
Administrator
In reply to this post by Paul Licameli
Paul Licameli wrote
Gale, here is my next iteration:

https://github.com/Paul-Licameli/audacity/commit/05e38f44b617577deb6840ec5a8247272e3d3c7f

At this commit, you have three more commits since the previous tip of my
bug1567-weird2 branch.

The first commit moves the fork() to an earlier point, in main(), but still
it is the child process that crashes and the original that continues.  I
don't expect this is worth experiments yet:  probably the same results as
most recently.

The second commit makes the child continue and the parent crash.  I predict
that this would fix bug 1567, just as well as the bug1567-weird branch did,
with the same problems with the windows.  But I prefer this implementation
over the first attempt.

The third commit, linked above, adds an Objective-C call to guarantee that
our windows come out on top.  It worked for me, while without these calls I
did have the lowered windows at least sometimes.

I suggest you test the third commit above, and if you are wholly satisfied
with it, we don't need to bother testing the previous stages.
Thanks Paul.

So do I assume you don't want me to build the tip of weird2 which is
"Some simplification" https://github.com/Paul-Licameli/audacity/commit/9b10b48 ?

I notice that 9b10b48 did not build on Travis and 05e38f4 stalled.

Paul Licameli wrote
Do I understand from your answer that even in bug1567-weird, which seemed
best yet but for the window problems -- the bug still appeared sometimes,
BUT it is no longer necessary to reboot macOS to clear it?  That restarting
Audacity is now enough?
Using the "weird" fix, I have never got the bug to appear when launching
Audacity, but the bug can as we now discovered sometimes occur when
closing the project with the AutoSave folder populated and you don't save
changes.

That bug occurrence when Audacity is already running isn't peculiar to the
"weird" or "weird-2" fix attempts. It happens with any of the attempts
to fix the bug or indeed in jc10.  

If the bug occurs when Audacity is already running, yes, merely launching
the "weird" version cures the bug unless close project triggers it again.
But reboot still cures it too (for me).

I should say that for some of the users who saw the bug in 2.1.2, reboot
never cured it - they had to use xattr or execute Audacity from the "MacOS"
folder within the bundle.


Gale
     
 

On Thu, Jan 12, 2017 at 9:09 PM, Gale <[hidden email]> wrote:

> Paul Licameli wrote
> > Gale,
> >
> > Here is a variation of the previous idea, implemented much more simply (I
> > remembered the Unix fork() function was what I needed).  Again it has a
> > sleep interval that you might tune.  It differs in that now the first
> > process continues while it is the child process that crashes at once.  I
> > do
> > not see the fleeting second icon on the dock and I have not yet seen the
> > initial window fail to raise itself.
> >
> > Does this still fix the bug?
> >
> > https://github.com/Paul-Licameli/audacity/commit/
> 107ec3281c62d030fde4601b93e529edad58e0a7
> >
> > PRL
>
> Thanks, Paul.
>
> This one is much better for appearance to the user - comes on top, no
> "ghosts"
> in the menu bar or Dock, and splash screen appears.
>
> It doesn't fully quash the bug as it occurs when Audacity launches. I'm
> back
> to failing in about 20 tries when launching Audacity from /Applications and
> in about five tries when launching from elsewhere.  Increasing the sleep
> where
> you have it now in the non-crashing process doesn't seem to help.
>
> So is it a sleep position problem we don't have right yet or must we really
> crash the first process? Can a child process run first with a hidden parent
> and crash the child? I may be off beam but I have a recollection that the
> old
> VST Effects dialogue that popped up before the Audacity window was a
> "child".
>
> I checked the case of the low space warning appearing, and there is no
> crash
> with this or the previous "weird" fix.
>
>
> Gale
>
> On Wed, Jan 11, 2017 at 10:06 AM, Gale <gale@> wrote:
>
> > Paul Licameli wrote
> > > Good news then!
> > >
> > > I was aware that Audacity sometimes is not on top after launch.  For
> > you,
> > > that happens always?
> > >
> > > Another weird looking thing is that if I watch the tool dock closely, I
> > > see
> > > one fleeting Audacity icon grow and shrink, and then a persistent one.
> >
> > Yes,  never on top for me. Yes, if I look at the dock I can see that too.
> >
> > I think the File > Close behaviour is a problem. But saving a Chain does
> > not trigger the bug as far as I can tell. If I find some other way to
> > trigger
> > the bug while Audacity is running I'll let you know.
> >
> > I modified your previous fix to insert another 1000 ms sleep before the
> > sock
> > file
> > (if I did it right). That helped a lot (no failures yet from
> > /Applications,
> > got to
> > about 20 tries before failing from outside /Applications). Just in case
> we
> > still go another route, but it seems you think the simulated force quit
> is
> > safe.
> >
> >
> > Gale
> >
> >
> > Paul Licameli wrote
> > >
> > > I might fix at least the first of these things.
> > >
> > > PRL
> > >
> > >
> > > On Wed, Jan 11, 2017 at 1:12 AM, Gale <
> >
> > > gale@
> >
> > > > wrote:
> > >
> > >> Paul Licameli wrote
> > >> > Did you not see my message the first time?  I thought I replied to
> > all.
> > >> > Well please try this commit.
> > >> >
> > >> > PRL
> > >>
> > >> No, I see nothing in Gmail from the lists after the 7th, though I did
> > get
> > >> this
> > >> message of yours which you Cc'd to me.
> > >>
> > >> I built your "weird" fix and at least on my machine, we are getting
> > >> somewhere
> > >> at last.
> > >>
> > >> I've so far done 40 launches of Audacity from /Applications, and
> > (really
> > >> good
> > >> news) 20 from other locations in my user space, without the bug
> > appearing
> > >> on
> > >> launch. This is with me downloading and running as admin, relaunching
> > at
> > >> once or waiting 30 seconds. I can't get to force quit Audacity's Dock
> > >> icon
> > >> now -
> > >> the option disappears too fast.
> > >>
> > >> I do still sometimes (50%?) get the bug if I File > Close with some
> > data
> > >> in
> > >> the
> > >> AutoSave folder then don't save the project. Setting the single sleep
> > you
> > >> added
> > >> to 5000 ms does not stop the File > Close issue.
> > >>
> > >> Quitting and relaunching Audacity removes the bug if File > Close has
> > >> triggered
> > >> it, but does not stop it happening again.
> > >>
> > >> Three points that may be problematic.
> > >>
> > >> * Audacity never comes on top when launched. I have to task switch to
> > it
> > >> or
> > >>    touch its Dock icon to see it.
> > >>
> > >> * When I launch Audacity, I do see the start of an Audacity menu bar
> by
> > >> the
> > >>    current menu bar which is then replaced by the menu bar of the app
> > >> that
> > >> was
> > >>    on top when I launched Audacity.
> > >>
> > >> * There is no splash screen when launching Audacity. I don't know if
> > that
> > >> is
> > >> an
> > >>    issue if e.g. the disk space warning appears that used to clash
> with
> > >> the
> > >>    splash screen.
> > >>
> > >>
> > >> Gale
> > >>
> > >>
> > >> On Tue, Jan 10, 2017 at 5:14 PM, Gale <gale@> wrote:
> > >>
> > >> > Sorry, Paul. I've been staring at Gmail for several days wondering
> > why
> > >> > there
> > >> > was
> > >> > no reply, but now I looked on Nabble. There is no trace of the
> > replies
> > >> in
> > >> > Gmail
> > >> > Bin or Spam and no trace of the new posts on -quality since the 7th,
> > >> hence
> > >> > I
> > >> > have not read those yet.
> > >> >
> > >> > I am still subscribed to -quality and my delivery enabled according
> > to
> > >> the
> > >> > control
> > >> > panel. I am not receiving -devel either. So at the moment I am
> > pointing
> > >> > the
> > >> > finger
> > >> > at Gmail and will try a desktop client.
> > >> >
> > >> >
> > >> >
> > >> > Paul Licameli wrote
> > >> > > On Sat, Jan 7, 2017 at 1:50 PM, Gale Andrews <
> > >> >
> > >> > > gale@
> > >> >
> > >> > > > wrote:
> > >> > >
> > >> > >> On 7 January 2017 at 00:46, Paul Licameli <
> > >> >
> > >> > > paul.licameli@
> > >> >
> > >> > > > wrote:
> > >> > >> >> On Fri, Jan 6, 2017 at 5:23 PM, Gale Andrews <
> > >> >
> > >> > > gale@
> > >> >
> > >> > > >
> > >> > >> wrote:
> > >> > >> >> On very brief testing, Paul's sleeps on exit and init as coded
> > >> make
> > >> > >> some
> > >> > >> >> impact on bug 1567 on my machine, without entirely preventing
> > it.
> > >> I
> > >> > >> still
> > >> > >> >> see about 1 in 8 failures if Audacity is launched outside
> > >> > >> /Applications,
> > >> > >> >> but
> > >> > >> >> I can go up to 25 to 40 launches from /Applications before the
> > >> bug
> > >> > >> >> triggers.
> > >> > >> >>
> > >> > >> >> So I would like to suggest we tweak sleeps further (do we need
> > >> > retry?)
> > >> > >> >> and that we won't need the fix of Audacity as single-user with
> > a
> > >> > >> forced
> > >> > >> >> Portable Settings folder, or User-Settings as amelioration of
> > >> that.
> > >> > If
> > >> > >> so,
> > >> > >> >> does that automatically remove the "damaged" and excessive
> > >> > >> verification
> > >> > >> >> time problems encountered above?
> > >> > >> >
> > >> > >> >
> > >> > >> > It is very good to hear at last that the sleeps appear to have
> > an
> > >> > >> effect
> > >> > >> on
> > >> > >> > the probability of the bug.
> > >> > >> >
> > >> > >> > I inserted one sleep near startup, in AudacityApp::InitTempDir,
> > >> and
> > >> > >> another
> > >> > >> > at shut-down, in AudacityApp::OnExit.  In each, I made the
> > >> duration
> > >> > >> 1000
> > >> > >> > msec.
> > >> > >> >
> > >> > >> > Not yet known:  is the reduced frequency of the problem due to
> > one
> > >> > >> sleep
> > >> > >> or
> > >> > >> > the other, or is the combination necessary?
> > >> > >> >
> > >> > >> > You can easily edit those two occurrences of the number 1000 to
> > >> > >> experiment
> > >> > >> > with longer intervals.
> > >> > >> >
> > >> > >> > If the sleep at exit is the important one, and if you must
> > >> lengthen
> > >> > >> that
> > >> > >> > from one to several seconds, even so this might be acceptable.
> > >> The
> > >> > >> slightly
> > >> > >> > odd-looking consequence might be that the Audacity icon is slow
> > to
> > >> > >> disappear
> > >> > >> > from the dock, but because the single-instance checker has been
> > >> > >> destroyed,
> > >> > >> > that should mean you are not barred from starting up another
> > >> instance
> > >> > >> of
> > >> > >> > Audacity before the first disappears.
> > >> > >> >
> > >> > >> > Surely a longer sleep at exit would be more tolerable than at
> > >> > startup.
> > >> > >>
> > >> > >> It's the startup sleep that mainly helps on my machine, assuming
> I
> > >> > >> relaunch
> > >> > >> Audacity immediately, rather than wait a while before relaunch,
> > >> which
> > >> > >> ameliorates the bug.
> > >> > >>
> > >> > >> Increasing the exit sleep to 2000 with no startup sleep makes no
> > >> > >> practical
> > >> > >> difference to the bug that I can see. Increasing exit sleep to
> > 3000
> > >> or
> > >> > >> 10000
> > >> > >> with no startup sleep gets me to about 1 in 20 failures launching
> > >> > >> Audacity
> > >> > >> from /Applications and 1 in 5 failures launching from elsewhere
> > (no
> > >> > >> sleeps is about 1 in 15 and 1 in 3 respectively).
> > >> > >>
> > >> > >> If I remove the exit sleep and just have the startup sleep before
> > >> the
> > >> > >> single
> > >> > >> instance checker, in one set of launches I got the bug at:
> > >> > >>
> > >> > >> 1000 ms = try 29 and 5 respectively
> > >> > >> 2000 ms = try 27 and 8 respectively
> > >> > >> 5000 ms = try 38 and 9 respectively
> > >> > >> 10000 ms = not failed yet in 50 and try 9 respectively
> > >> > >>
> > >> > >> With exit sleep at 3000 and startup sleep at 2000 I failed at 36
> > and
> > >> 10
> > >> > >> respectively. I did not try other sleep lengths with both sleeps.
> > >> > >>
> > >> > >> Perhaps we could try more sleeps of shorter durations at start up
> > in
> > >> > case
> > >> > >> we don't have the best place yet. How about a sleep before
> > creating
> > >> the
> > >> > >> .audacity.sock file? Other places?
> > >> > >>
> > >> > >> It looks like we may not fully solve Audacity launched from
> > outside
> > >> > >> /Applications unless we act on configuration files inside the
> > >> bundle.
> > >> > But
> > >> > >> I
> > >> > >> would like you to suggest more and shorter exit sleeps first, or
> > >> other
> > >> > >> suggestions if you have any.
> > >> > >>
> > >> > >> The fix of force quitting Audacity immediately on launch then
> > >> letting
> > >> > >> launch
> > >> > >> complete still works, providing I get no lock file created.
> > >> > >>
> > >> > >>
> > >> > >> Gale
> > >> > >>
> > >> > >
> > >> > > Not yet the decisive victory I had been hoping for.
> > >> > >
> > >> > > Let me understand:
> > >> > >
> > >> > >
> > >> > >    - Even unmodified, the program is less likely to suffer the bug
> > if
> > >> > you
> > >> > >    simply pause long enough between relaunches.  So really it's
> > only
> > >> a
> > >> > >    sequence of rapid relaunches that is the problem.
> > >> >
> > >> > If unmodified 2.1.2 or HEAD, the bug occurs on first launch wherever
> > >> > Audacity is launched from.
> > >> >
> > >> > But if using an unmodified jcx codesigned build, then I see the
> > >> > variability
> > >> > that launching from outside /Applications is more prone to the bug,
> > and
> > >> > that exiting and launching again with no pause is more prone to the
> > bug
> > >> > than waiting between launches.
> > >> >
> > >> > Pausing isn't a total cure, even launching Audacity from
> > /Applications.
> > >> >
> > >> > That made me think of testing File > Close in the build I tested
> that
> > >> > has exit and starting sleeps. I don't have any issue if I launch
> > >> Audacity
> > >> > then do COMMAND + W repeatedly without pause. But if I record
> > >> > something then COMMAND + W and don't save changes, this triggered
> > >> > the bug on a couple of occasions. I lost plugins from the menus and
> > >> lost
> > >> > LAME and FFmpeg.  It did not happen if I said yes to Save Changes,
> > >> > though I only tested twice.
> > >> >
> > >> > As yet, I don't have an issue with that in jc10, running and
> > installed
> > >> as
> > >> > Admin with its Portable Settings folder present, but I only tested
> > >> three
> > >> > closes without save and three closes with save. I'd have to test
> more
> > >> > to say jc10 is immune.
> > >> >
> > >> > Yikes. So I guess clearing out the AutoSave folder is also a
> > potential
> > >> > problem, but saving a project also clears out AutoSave. So does that
> > >> > also point to another timing issue?
> > >> >
> > >> > If someone saves a Chain, is that going to risk triggering the bug,
> > >> > given we write to a Chains folder in the configuration folder?
> > >> >
> > >> >
> > >> > Paul Licameli wrote
> > >> > >    - When it strikes once, it will invariably strike again until
> > >> either
> > >> > > the
> > >> > >    operating system is rebooted, or you use a quick enough
> > >> force-quit.
> > >> >
> > >> > Yes.
> > >> >
> > >> >
> > >> > Paul Licameli wrote
> > >> > >    - When you force-quit and try again, this is comparably fast,
> to
> > a
> > >> > >    normal program exit followed by another try: in other words the
> > >> > timing
> > >> > > of
> > >> > >    your restart in this case, is not an uncontrolled variable.
> > >> >
> > >> > Interesting. I can force quit then start normally as fast as I am
> > >> > physically
> > >> > able, and that always gets rid of the bug.
> > >> >
> > >> > But I just now waited several minutes after force quit, then
> launched
> > >> > Audacity and the bug is still there. Force-quit, launch at once, and
> > >> the
> > >> > bug has gone.
> > >> >
> > >> >
> > >> > Paul Licameli wrote
> > >> > > I had a bizarre idea to try next -- perhaps bizarre ideas are
> > needed.
> > >> I
> > >> > > could simulate the force quit.  (By raising SIGTERM.)  I could
> make
> > >> each
> > >> > > start of Audacity launch a process, which would commit suicide,
> but
> > >> > start
> > >> > > a
> > >> > > second process.  If there is something just about the starting and
> > >> early
> > >> > > stopping that makes the operating system straighten itself out,
> who
> > >> > knows,
> > >> > > this might work.
> > >> > >
> > >> > > Here is an implementation.  It does not include any of the
> previous
> > >> > > attempted fixes.  It does contain a wxMilliSleep of just 1 msec in
> > >> the
> > >> > > non-crashing process.  You might adjust that number.
> > >> > >
> > >> > > https://github.com/Paul-Licameli/audacity/commit/
> > >> > f0135d99c0f232982fe7fb4b10b68aa0385d9b6a
> > >> >
> > >> > OK Paul I will try it ASAP now I've seen this. I'd have said that
> > >> sounds
> > >> > hopeful, but there is still the new Close Project issue I would like
> > >> your
> > >> > opinion on.
> > >> >
> > >> >
> > >> > Gale
> > >> >
> > >> > --
> > >> > View this message in context: http://audacity.238276.n2.
> > >> > nabble.com/Bug-1567-startup-sleeps-tp7577731p7577747.html
> > >> > Sent from the audacity-quality mailing list archive at Nabble
> > >>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 1567 startup sleeps

Paul Licameli
Gale, I take it you have not yet tested it.

I don't know why Travis stopped notifying me.

I see you check github for yourself and see my other commits.  Do you still prefer to be given complete links to commits?

I updated the branch, applying the simplification and also reinserting a sleep that might not be needed at all -- I made it just 1 msec.  The new tip is now at 52801fc988b43ee02e0d0ec77e07366a7779984b.

PRL


On Fri, Jan 13, 2017 at 2:46 PM, Gale <[hidden email]> wrote:
Paul Licameli wrote
> Gale, here is my next iteration:
>
> https://github.com/Paul-Licameli/audacity/commit/05e38f44b617577deb6840ec5a8247272e3d3c7f
>
> At this commit, you have three more commits since the previous tip of my
> bug1567-weird2 branch.
>
> The first commit moves the fork() to an earlier point, in main(), but
> still
> it is the child process that crashes and the original that continues.  I
> don't expect this is worth experiments yet:  probably the same results as
> most recently.
>
> The second commit makes the child continue and the parent crash.  I
> predict
> that this would fix bug 1567, just as well as the bug1567-weird branch
> did,
> with the same problems with the windows.  But I prefer this implementation
> over the first attempt.
>
> The third commit, linked above, adds an Objective-C call to guarantee that
> our windows come out on top.  It worked for me, while without these calls
> I
> did have the lowered windows at least sometimes.
>
> I suggest you test the third commit above, and if you are wholly satisfied
> with it, we don't need to bother testing the previous stages.

Thanks Paul.

So do I assume you don't want me to build the tip of weird2 which is
"Some simplification"
https://github.com/Paul-Licameli/audacity/commit/9b10b48 ?

I notice that 9b10b48 did not build on Travis and 05e38f4 stalled.


Paul Licameli wrote
> Do I understand from your answer that even in bug1567-weird, which seemed
> best yet but for the window problems -- the bug still appeared sometimes,
> BUT it is no longer necessary to reboot macOS to clear it?  That
> restarting
> Audacity is now enough?

Using the "weird" fix, I have never got the bug to appear when launching
Audacity, but the bug can as we now discovered sometimes occur when
closing the project with the AutoSave folder populated and you don't save
changes.

That bug occurrence when Audacity is already running isn't peculiar to the
"weird" or "weird-2" fix attempts. It happens with any of the attempts
to fix the bug or indeed in jc10.

If the bug occurs when Audacity is already running, yes, merely launching
the "weird" version cures the bug unless close project triggers it again.
But reboot still cures it too (for me).

I should say that for some of the users who saw the bug in 2.1.2, reboot
never cured it - they had to use xattr or execute Audacity from the "MacOS"
folder within the bundle.


Gale



On Thu, Jan 12, 2017 at 9:09 PM, Gale &lt;gale@&gt; wrote:

> Paul Licameli wrote
> > Gale,
> >
> > Here is a variation of the previous idea, implemented much more simply
> (I
> > remembered the Unix fork() function was what I needed).  Again it has a
> > sleep interval that you might tune.  It differs in that now the first
> > process continues while it is the child process that crashes at once.  I
> > do
> > not see the fleeting second icon on the dock and I have not yet seen the
> > initial window fail to raise itself.
> >
> > Does this still fix the bug?
> >
> > https://github.com/Paul-Licameli/audacity/commit/
> 107ec3281c62d030fde4601b93e529edad58e0a7
> >
> > PRL
>
> Thanks, Paul.
>
> This one is much better for appearance to the user - comes on top, no
> "ghosts"
> in the menu bar or Dock, and splash screen appears.
>
> It doesn't fully quash the bug as it occurs when Audacity launches. I'm
> back
> to failing in about 20 tries when launching Audacity from /Applications
> and
> in about five tries when launching from elsewhere.  Increasing the sleep
> where
> you have it now in the non-crashing process doesn't seem to help.
>
> So is it a sleep position problem we don't have right yet or must we
> really
> crash the first process? Can a child process run first with a hidden
> parent
> and crash the child? I may be off beam but I have a recollection that the
> old
> VST Effects dialogue that popped up before the Audacity window was a
> "child".
>
> I checked the case of the low space warning appearing, and there is no
> crash
> with this or the previous "weird" fix.
>
>
> Gale
>
> On Wed, Jan 11, 2017 at 10:06 AM, Gale &lt;gale@&gt; wrote:
>
> > Paul Licameli wrote
> > > Good news then!
> > >
> > > I was aware that Audacity sometimes is not on top after launch.  For
> > you,
> > > that happens always?
> > >
> > > Another weird looking thing is that if I watch the tool dock closely,
> I
> > > see
> > > one fleeting Audacity icon grow and shrink, and then a persistent one.
> >
> > Yes,  never on top for me. Yes, if I look at the dock I can see that
> too.
> >
> > I think the File > Close behaviour is a problem. But saving a Chain does
> > not trigger the bug as far as I can tell. If I find some other way to
> > trigger
> > the bug while Audacity is running I'll let you know.
> >
> > I modified your previous fix to insert another 1000 ms sleep before the
> > sock
> > file
> > (if I did it right). That helped a lot (no failures yet from
> > /Applications,
> > got to
> > about 20 tries before failing from outside /Applications). Just in case
> we
> > still go another route, but it seems you think the simulated force quit
> is
> > safe.
> >
> >
> > Gale
> >
> >
> > Paul Licameli wrote
> > >
> > > I might fix at least the first of these things.
> > >
> > > PRL
> > >
> > >
> > > On Wed, Jan 11, 2017 at 1:12 AM, Gale &lt;
> >
> > > gale@
> >
> > > &gt; wrote:
> > >
> > >> Paul Licameli wrote
> > >> > Did you not see my message the first time?  I thought I replied to
> > all.
> > >> > Well please try this commit.
> > >> >
> > >> > PRL
> > >>
> > >> No, I see nothing in Gmail from the lists after the 7th, though I did
> > get
> > >> this
> > >> message of yours which you Cc'd to me.
> > >>
> > >> I built your "weird" fix and at least on my machine, we are getting
> > >> somewhere
> > >> at last.
> > >>
> > >> I've so far done 40 launches of Audacity from /Applications, and
> > (really
> > >> good
> > >> news) 20 from other locations in my user space, without the bug
> > appearing
> > >> on
> > >> launch. This is with me downloading and running as admin, relaunching
> > at
> > >> once or waiting 30 seconds. I can't get to force quit Audacity's Dock
> > >> icon
> > >> now -
> > >> the option disappears too fast.
> > >>
> > >> I do still sometimes (50%?) get the bug if I File > Close with some
> > data
> > >> in
> > >> the
> > >> AutoSave folder then don't save the project. Setting the single sleep
> > you
> > >> added
> > >> to 5000 ms does not stop the File > Close issue.
> > >>
> > >> Quitting and relaunching Audacity removes the bug if File > Close has
> > >> triggered
> > >> it, but does not stop it happening again.
> > >>
> > >> Three points that may be problematic.
> > >>
> > >> * Audacity never comes on top when launched. I have to task switch to
> > it
> > >> or
> > >>    touch its Dock icon to see it.
> > >>
> > >> * When I launch Audacity, I do see the start of an Audacity menu bar
> by
> > >> the
> > >>    current menu bar which is then replaced by the menu bar of the app
> > >> that
> > >> was
> > >>    on top when I launched Audacity.
> > >>
> > >> * There is no splash screen when launching Audacity. I don't know if
> > that
> > >> is
> > >> an
> > >>    issue if e.g. the disk space warning appears that used to clash
> with
> > >> the
> > >>    splash screen.
> > >>
> > >>
> > >> Gale
> > >>
> > >>
> > >> On Tue, Jan 10, 2017 at 5:14 PM, Gale &lt;gale@&gt; wrote:
> > >>
> > >> > Sorry, Paul. I've been staring at Gmail for several days wondering
> > why
> > >> > there
> > >> > was
> > >> > no reply, but now I looked on Nabble. There is no trace of the
> > replies
> > >> in
> > >> > Gmail
> > >> > Bin or Spam and no trace of the new posts on -quality since the
> 7th,
> > >> hence
> > >> > I
> > >> > have not read those yet.
> > >> >
> > >> > I am still subscribed to -quality and my delivery enabled according
> > to
> > >> the
> > >> > control
> > >> > panel. I am not receiving -devel either. So at the moment I am
> > pointing
> > >> > the
> > >> > finger
> > >> > at Gmail and will try a desktop client.
> > >> >
> > >> >
> > >> >
> > >> > Paul Licameli wrote
> > >> > > On Sat, Jan 7, 2017 at 1:50 PM, Gale Andrews &lt;
> > >> >
> > >> > > gale@
> > >> >
> > >> > > &gt; wrote:
> > >> > >
> > >> > >> On 7 January 2017 at 00:46, Paul Licameli &lt;
> > >> >
> > >> > > paul.licameli@
> > >> >
> > >> > > &gt; wrote:
> > >> > >> >> On Fri, Jan 6, 2017 at 5:23 PM, Gale Andrews &lt;
> > >> >
> > >> > > gale@
> > >> >
> > >> > > &gt;
> > >> > >> wrote:
> > >> > >> >> On very brief testing, Paul's sleeps on exit and init as
> coded
> > >> make
> > >> > >> some
> > >> > >> >> impact on bug 1567 on my machine, without entirely preventing
> > it.
> > >> I
> > >> > >> still
> > >> > >> >> see about 1 in 8 failures if Audacity is launched outside
> > >> > >> /Applications,
> > >> > >> >> but
> > >> > >> >> I can go up to 25 to 40 launches from /Applications before
> the
> > >> bug
> > >> > >> >> triggers.
> > >> > >> >>
> > >> > >> >> So I would like to suggest we tweak sleeps further (do we
> need
> > >> > retry?)
> > >> > >> >> and that we won't need the fix of Audacity as single-user
> with
> > a
> > >> > >> forced
> > >> > >> >> Portable Settings folder, or User-Settings as amelioration of
> > >> that.
> > >> > If
> > >> > >> so,
> > >> > >> >> does that automatically remove the "damaged" and excessive
> > >> > >> verification
> > >> > >> >> time problems encountered above?
> > >> > >> >
> > >> > >> >
> > >> > >> > It is very good to hear at last that the sleeps appear to have
> > an
> > >> > >> effect
> > >> > >> on
> > >> > >> > the probability of the bug.
> > >> > >> >
> > >> > >> > I inserted one sleep near startup, in
> AudacityApp::InitTempDir,
> > >> and
> > >> > >> another
> > >> > >> > at shut-down, in AudacityApp::OnExit.  In each, I made the
> > >> duration
> > >> > >> 1000
> > >> > >> > msec.
> > >> > >> >
> > >> > >> > Not yet known:  is the reduced frequency of the problem due to
> > one
> > >> > >> sleep
> > >> > >> or
> > >> > >> > the other, or is the combination necessary?
> > >> > >> >
> > >> > >> > You can easily edit those two occurrences of the number 1000
> to
> > >> > >> experiment
> > >> > >> > with longer intervals.
> > >> > >> >
> > >> > >> > If the sleep at exit is the important one, and if you must
> > >> lengthen
> > >> > >> that
> > >> > >> > from one to several seconds, even so this might be acceptable.
> > >> The
> > >> > >> slightly
> > >> > >> > odd-looking consequence might be that the Audacity icon is
> slow
> > to
> > >> > >> disappear
> > >> > >> > from the dock, but because the single-instance checker has
> been
> > >> > >> destroyed,
> > >> > >> > that should mean you are not barred from starting up another
> > >> instance
> > >> > >> of
> > >> > >> > Audacity before the first disappears.
> > >> > >> >
> > >> > >> > Surely a longer sleep at exit would be more tolerable than at
> > >> > startup.
> > >> > >>
> > >> > >> It's the startup sleep that mainly helps on my machine, assuming
> I
> > >> > >> relaunch
> > >> > >> Audacity immediately, rather than wait a while before relaunch,
> > >> which
> > >> > >> ameliorates the bug.
> > >> > >>
> > >> > >> Increasing the exit sleep to 2000 with no startup sleep makes no
> > >> > >> practical
> > >> > >> difference to the bug that I can see. Increasing exit sleep to
> > 3000
> > >> or
> > >> > >> 10000
> > >> > >> with no startup sleep gets me to about 1 in 20 failures
> launching
> > >> > >> Audacity
> > >> > >> from /Applications and 1 in 5 failures launching from elsewhere
> > (no
> > >> > >> sleeps is about 1 in 15 and 1 in 3 respectively).
> > >> > >>
> > >> > >> If I remove the exit sleep and just have the startup sleep
> before
> > >> the
> > >> > >> single
> > >> > >> instance checker, in one set of launches I got the bug at:
> > >> > >>
> > >> > >> 1000 ms = try 29 and 5 respectively
> > >> > >> 2000 ms = try 27 and 8 respectively
> > >> > >> 5000 ms = try 38 and 9 respectively
> > >> > >> 10000 ms = not failed yet in 50 and try 9 respectively
> > >> > >>
> > >> > >> With exit sleep at 3000 and startup sleep at 2000 I failed at 36
> > and
> > >> 10
> > >> > >> respectively. I did not try other sleep lengths with both
> sleeps.
> > >> > >>
> > >> > >> Perhaps we could try more sleeps of shorter durations at start
> up
> > in
> > >> > case
> > >> > >> we don't have the best place yet. How about a sleep before
> > creating
> > >> the
> > >> > >> .audacity.sock file? Other places?
> > >> > >>
> > >> > >> It looks like we may not fully solve Audacity launched from
> > outside
> > >> > >> /Applications unless we act on configuration files inside the
> > >> bundle.
> > >> > But
> > >> > >> I
> > >> > >> would like you to suggest more and shorter exit sleeps first, or
> > >> other
> > >> > >> suggestions if you have any.
> > >> > >>
> > >> > >> The fix of force quitting Audacity immediately on launch then
> > >> letting
> > >> > >> launch
> > >> > >> complete still works, providing I get no lock file created.
> > >> > >>
> > >> > >>
> > >> > >> Gale
> > >> > >>
> > >> > >
> > >> > > Not yet the decisive victory I had been hoping for.
> > >> > >
> > >> > > Let me understand:
> > >> > >
> > >> > >
> > >> > >    - Even unmodified, the program is less likely to suffer the
> bug
> > if
> > >> > you
> > >> > >    simply pause long enough between relaunches.  So really it's
> > only
> > >> a
> > >> > >    sequence of rapid relaunches that is the problem.
> > >> >
> > >> > If unmodified 2.1.2 or HEAD, the bug occurs on first launch
> wherever
> > >> > Audacity is launched from.
> > >> >
> > >> > But if using an unmodified jcx codesigned build, then I see the
> > >> > variability
> > >> > that launching from outside /Applications is more prone to the bug,
> > and
> > >> > that exiting and launching again with no pause is more prone to the
> > bug
> > >> > than waiting between launches.
> > >> >
> > >> > Pausing isn't a total cure, even launching Audacity from
> > /Applications.
> > >> >
> > >> > That made me think of testing File > Close in the build I tested
> that
> > >> > has exit and starting sleeps. I don't have any issue if I launch
> > >> Audacity
> > >> > then do COMMAND + W repeatedly without pause. But if I record
> > >> > something then COMMAND + W and don't save changes, this triggered
> > >> > the bug on a couple of occasions. I lost plugins from the menus and
> > >> lost
> > >> > LAME and FFmpeg.  It did not happen if I said yes to Save Changes,
> > >> > though I only tested twice.
> > >> >
> > >> > As yet, I don't have an issue with that in jc10, running and
> > installed
> > >> as
> > >> > Admin with its Portable Settings folder present, but I only tested
> > >> three
> > >> > closes without save and three closes with save. I'd have to test
> more
> > >> > to say jc10 is immune.
> > >> >
> > >> > Yikes. So I guess clearing out the AutoSave folder is also a
> > potential
> > >> > problem, but saving a project also clears out AutoSave. So does
> that
> > >> > also point to another timing issue?
> > >> >
> > >> > If someone saves a Chain, is that going to risk triggering the bug,
> > >> > given we write to a Chains folder in the configuration folder?
> > >> >
> > >> >
> > >> > Paul Licameli wrote
> > >> > >    - When it strikes once, it will invariably strike again until
> > >> either
> > >> > > the
> > >> > >    operating system is rebooted, or you use a quick enough
> > >> force-quit.
> > >> >
> > >> > Yes.
> > >> >
> > >> >
> > >> > Paul Licameli wrote
> > >> > >    - When you force-quit and try again, this is comparably fast,
> to
> > a
> > >> > >    normal program exit followed by another try: in other words
> the
> > >> > timing
> > >> > > of
> > >> > >    your restart in this case, is not an uncontrolled variable.
> > >> >
> > >> > Interesting. I can force quit then start normally as fast as I am
> > >> > physically
> > >> > able, and that always gets rid of the bug.
> > >> >
> > >> > But I just now waited several minutes after force quit, then
> launched
> > >> > Audacity and the bug is still there. Force-quit, launch at once,
> and
> > >> the
> > >> > bug has gone.
> > >> >
> > >> >
> > >> > Paul Licameli wrote
> > >> > > I had a bizarre idea to try next -- perhaps bizarre ideas are
> > needed.
> > >> I
> > >> > > could simulate the force quit.  (By raising SIGTERM.)  I could
> make
> > >> each
> > >> > > start of Audacity launch a process, which would commit suicide,
> but
> > >> > start
> > >> > > a
> > >> > > second process.  If there is something just about the starting
> and
> > >> early
> > >> > > stopping that makes the operating system straighten itself out,
> who
> > >> > knows,
> > >> > > this might work.
> > >> > >
> > >> > > Here is an implementation.  It does not include any of the
> previous
> > >> > > attempted fixes.  It does contain a wxMilliSleep of just 1 msec
> in
> > >> the
> > >> > > non-crashing process.  You might adjust that number.
> > >> > >
> > >> > > https://github.com/Paul-Licameli/audacity/commit/
> > >> > f0135d99c0f232982fe7fb4b10b68aa0385d9b6a
> > >> >
> > >> > OK Paul I will try it ASAP now I've seen this. I'd have said that
> > >> sounds
> > >> > hopeful, but there is still the new Close Project issue I would
> like
> > >> your
> > >> > opinion on.
> > >> >
> > >> >
> > >> > Gale
> > >> >
> > >> > --
> > >> > View this message in context: http://audacity.238276.n2.
> > >> > nabble.com/Bug-1567-startup-sleeps-tp7577731p7577747.html
> > >> > Sent from the audacity-quality mailing list archive at Nabble
> > >>




--
View this message in context: http://audacity.238276.n2.nabble.com/Bug-1567-startup-sleeps-tp7577731p7577781.html
Sent from the audacity-quality mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 1567 startup sleeps

Paul Licameli
In reply to this post by Gale


On Fri, Jan 13, 2017 at 2:46 PM, Gale <[hidden email]> wrote:
Paul Licameli wrote
> Gale, here is my next iteration:
>
> https://github.com/Paul-Licameli/audacity/commit/05e38f44b617577deb6840ec5a8247272e3d3c7f
>
> At this commit, you have three more commits since the previous tip of my
> bug1567-weird2 branch.
>
> The first commit moves the fork() to an earlier point, in main(), but
> still
> it is the child process that crashes and the original that continues.  I
> don't expect this is worth experiments yet:  probably the same results as
> most recently.
>
> The second commit makes the child continue and the parent crash.  I
> predict
> that this would fix bug 1567, just as well as the bug1567-weird branch
> did,
> with the same problems with the windows.  But I prefer this implementation
> over the first attempt.
>
> The third commit, linked above, adds an Objective-C call to guarantee that
> our windows come out on top.  It worked for me, while without these calls
> I
> did have the lowered windows at least sometimes.
>
> I suggest you test the third commit above, and if you are wholly satisfied
> with it, we don't need to bother testing the previous stages.

Thanks Paul.

So do I assume you don't want me to build the tip of weird2 which is
"Some simplification"
https://github.com/Paul-Licameli/audacity/commit/9b10b48 ?

I notice that 9b10b48 did not build on Travis and 05e38f4 stalled.


Paul Licameli wrote
> Do I understand from your answer that even in bug1567-weird, which seemed
> best yet but for the window problems -- the bug still appeared sometimes,
> BUT it is no longer necessary to reboot macOS to clear it?  That
> restarting
> Audacity is now enough?

Using the "weird" fix, I have never got the bug to appear when launching
Audacity, but the bug can as we now discovered sometimes occur when
closing the project with the AutoSave folder populated and you don't save
changes.

That bug occurrence when Audacity is already running isn't peculiar to the
"weird" or "weird-2" fix attempts. It happens with any of the attempts
to fix the bug or indeed in jc10.

If the bug occurs when Audacity is already running, yes, merely launching
the "weird" version cures the bug unless close project triggers it again.
But reboot still cures it too (for me).

I should say that for some of the users who saw the bug in 2.1.2, reboot
never cured it - they had to use xattr or execute Audacity from the "MacOS"
folder within the bundle.


Explain these workarounds to me?  Some other users in communication with me may need advice for using 2.1.2 on Sierra, and they report that they can't find certain .ny files in the effects manager dialog, no matter what folder they are in.

I am not familiar with xattr.

Do you also mean that a workaround is navigating inside the bundle in Finder, and then directly opening the executable?

PRL

 

Gale



On Thu, Jan 12, 2017 at 9:09 PM, Gale &lt;gale@&gt; wrote:

> Paul Licameli wrote
> > Gale,
> >
> > Here is a variation of the previous idea, implemented much more simply
> (I
> > remembered the Unix fork() function was what I needed).  Again it has a
> > sleep interval that you might tune.  It differs in that now the first
> > process continues while it is the child process that crashes at once.  I
> > do
> > not see the fleeting second icon on the dock and I have not yet seen the
> > initial window fail to raise itself.
> >
> > Does this still fix the bug?
> >
> > https://github.com/Paul-Licameli/audacity/commit/
> 107ec3281c62d030fde4601b93e529edad58e0a7
> >
> > PRL
>
> Thanks, Paul.
>
> This one is much better for appearance to the user - comes on top, no
> "ghosts"
> in the menu bar or Dock, and splash screen appears.
>
> It doesn't fully quash the bug as it occurs when Audacity launches. I'm
> back
> to failing in about 20 tries when launching Audacity from /Applications
> and
> in about five tries when launching from elsewhere.  Increasing the sleep
> where
> you have it now in the non-crashing process doesn't seem to help.
>
> So is it a sleep position problem we don't have right yet or must we
> really
> crash the first process? Can a child process run first with a hidden
> parent
> and crash the child? I may be off beam but I have a recollection that the
> old
> VST Effects dialogue that popped up before the Audacity window was a
> "child".
>
> I checked the case of the low space warning appearing, and there is no
> crash
> with this or the previous "weird" fix.
>
>
> Gale
>
> On Wed, Jan 11, 2017 at 10:06 AM, Gale &lt;gale@&gt; wrote:
>
> > Paul Licameli wrote
> > > Good news then!
> > >
> > > I was aware that Audacity sometimes is not on top after launch.  For
> > you,
> > > that happens always?
> > >
> > > Another weird looking thing is that if I watch the tool dock closely,
> I
> > > see
> > > one fleeting Audacity icon grow and shrink, and then a persistent one.
> >
> > Yes,  never on top for me. Yes, if I look at the dock I can see that
> too.
> >
> > I think the File > Close behaviour is a problem. But saving a Chain does
> > not trigger the bug as far as I can tell. If I find some other way to
> > trigger
> > the bug while Audacity is running I'll let you know.
> >
> > I modified your previous fix to insert another 1000 ms sleep before the
> > sock
> > file
> > (if I did it right). That helped a lot (no failures yet from
> > /Applications,
> > got to
> > about 20 tries before failing from outside /Applications). Just in case
> we
> > still go another route, but it seems you think the simulated force quit
> is
> > safe.
> >
> >
> > Gale
> >
> >
> > Paul Licameli wrote
> > >
> > > I might fix at least the first of these things.
> > >
> > > PRL
> > >
> > >
> > > On Wed, Jan 11, 2017 at 1:12 AM, Gale &lt;
> >
> > > gale@
> >
> > > &gt; wrote:
> > >
> > >> Paul Licameli wrote
> > >> > Did you not see my message the first time?  I thought I replied to
> > all.
> > >> > Well please try this commit.
> > >> >
> > >> > PRL
> > >>
> > >> No, I see nothing in Gmail from the lists after the 7th, though I did
> > get
> > >> this
> > >> message of yours which you Cc'd to me.
> > >>
> > >> I built your "weird" fix and at least on my machine, we are getting
> > >> somewhere
> > >> at last.
> > >>
> > >> I've so far done 40 launches of Audacity from /Applications, and
> > (really
> > >> good
> > >> news) 20 from other locations in my user space, without the bug
> > appearing
> > >> on
> > >> launch. This is with me downloading and running as admin, relaunching
> > at
> > >> once or waiting 30 seconds. I can't get to force quit Audacity's Dock
> > >> icon
> > >> now -
> > >> the option disappears too fast.
> > >>
> > >> I do still sometimes (50%?) get the bug if I File > Close with some
> > data
> > >> in
> > >> the
> > >> AutoSave folder then don't save the project. Setting the single sleep
> > you
> > >> added
> > >> to 5000 ms does not stop the File > Close issue.
> > >>
> > >> Quitting and relaunching Audacity removes the bug if File > Close has
> > >> triggered
> > >> it, but does not stop it happening again.
> > >>
> > >> Three points that may be problematic.
> > >>
> > >> * Audacity never comes on top when launched. I have to task switch to
> > it
> > >> or
> > >>    touch its Dock icon to see it.
> > >>
> > >> * When I launch Audacity, I do see the start of an Audacity menu bar
> by
> > >> the
> > >>    current menu bar which is then replaced by the menu bar of the app
> > >> that
> > >> was
> > >>    on top when I launched Audacity.
> > >>
> > >> * There is no splash screen when launching Audacity. I don't know if
> > that
> > >> is
> > >> an
> > >>    issue if e.g. the disk space warning appears that used to clash
> with
> > >> the
> > >>    splash screen.
> > >>
> > >>
> > >> Gale
> > >>
> > >>
> > >> On Tue, Jan 10, 2017 at 5:14 PM, Gale &lt;gale@&gt; wrote:
> > >>
> > >> > Sorry, Paul. I've been staring at Gmail for several days wondering
> > why
> > >> > there
> > >> > was
> > >> > no reply, but now I looked on Nabble. There is no trace of the
> > replies
> > >> in
> > >> > Gmail
> > >> > Bin or Spam and no trace of the new posts on -quality since the
> 7th,
> > >> hence
> > >> > I
> > >> > have not read those yet.
> > >> >
> > >> > I am still subscribed to -quality and my delivery enabled according
> > to
> > >> the
> > >> > control
> > >> > panel. I am not receiving -devel either. So at the moment I am
> > pointing
> > >> > the
> > >> > finger
> > >> > at Gmail and will try a desktop client.
> > >> >
> > >> >
> > >> >
> > >> > Paul Licameli wrote
> > >> > > On Sat, Jan 7, 2017 at 1:50 PM, Gale Andrews &lt;
> > >> >
> > >> > > gale@
> > >> >
> > >> > > &gt; wrote:
> > >> > >
> > >> > >> On 7 January 2017 at 00:46, Paul Licameli &lt;
> > >> >
> > >> > > paul.licameli@
> > >> >
> > >> > > &gt; wrote:
> > >> > >> >> On Fri, Jan 6, 2017 at 5:23 PM, Gale Andrews &lt;
> > >> >
> > >> > > gale@
> > >> >
> > >> > > &gt;
> > >> > >> wrote:
> > >> > >> >> On very brief testing, Paul's sleeps on exit and init as
> coded
> > >> make
> > >> > >> some
> > >> > >> >> impact on bug 1567 on my machine, without entirely preventing
> > it.
> > >> I
> > >> > >> still
> > >> > >> >> see about 1 in 8 failures if Audacity is launched outside
> > >> > >> /Applications,
> > >> > >> >> but
> > >> > >> >> I can go up to 25 to 40 launches from /Applications before
> the
> > >> bug
> > >> > >> >> triggers.
> > >> > >> >>
> > >> > >> >> So I would like to suggest we tweak sleeps further (do we
> need
> > >> > retry?)
> > >> > >> >> and that we won't need the fix of Audacity as single-user
> with
> > a
> > >> > >> forced
> > >> > >> >> Portable Settings folder, or User-Settings as amelioration of
> > >> that.
> > >> > If
> > >> > >> so,
> > >> > >> >> does that automatically remove the "damaged" and excessive
> > >> > >> verification
> > >> > >> >> time problems encountered above?
> > >> > >> >
> > >> > >> >
> > >> > >> > It is very good to hear at last that the sleeps appear to have
> > an
> > >> > >> effect
> > >> > >> on
> > >> > >> > the probability of the bug.
> > >> > >> >
> > >> > >> > I inserted one sleep near startup, in
> AudacityApp::InitTempDir,
> > >> and
> > >> > >> another
> > >> > >> > at shut-down, in AudacityApp::OnExit.  In each, I made the
> > >> duration
> > >> > >> 1000
> > >> > >> > msec.
> > >> > >> >
> > >> > >> > Not yet known:  is the reduced frequency of the problem due to
> > one
> > >> > >> sleep
> > >> > >> or
> > >> > >> > the other, or is the combination necessary?
> > >> > >> >
> > >> > >> > You can easily edit those two occurrences of the number 1000
> to
> > >> > >> experiment
> > >> > >> > with longer intervals.
> > >> > >> >
> > >> > >> > If the sleep at exit is the important one, and if you must
> > >> lengthen
> > >> > >> that
> > >> > >> > from one to several seconds, even so this might be acceptable.
> > >> The
> > >> > >> slightly
> > >> > >> > odd-looking consequence might be that the Audacity icon is
> slow
> > to
> > >> > >> disappear
> > >> > >> > from the dock, but because the single-instance checker has
> been
> > >> > >> destroyed,
> > >> > >> > that should mean you are not barred from starting up another
> > >> instance
> > >> > >> of
> > >> > >> > Audacity before the first disappears.
> > >> > >> >
> > >> > >> > Surely a longer sleep at exit would be more tolerable than at
> > >> > startup.
> > >> > >>
> > >> > >> It's the startup sleep that mainly helps on my machine, assuming
> I
> > >> > >> relaunch
> > >> > >> Audacity immediately, rather than wait a while before relaunch,
> > >> which
> > >> > >> ameliorates the bug.
> > >> > >>
> > >> > >> Increasing the exit sleep to 2000 with no startup sleep makes no
> > >> > >> practical
> > >> > >> difference to the bug that I can see. Increasing exit sleep to
> > 3000
> > >> or
> > >> > >> 10000
> > >> > >> with no startup sleep gets me to about 1 in 20 failures
> launching
> > >> > >> Audacity
> > >> > >> from /Applications and 1 in 5 failures launching from elsewhere
> > (no
> > >> > >> sleeps is about 1 in 15 and 1 in 3 respectively).
> > >> > >>
> > >> > >> If I remove the exit sleep and just have the startup sleep
> before
> > >> the
> > >> > >> single
> > >> > >> instance checker, in one set of launches I got the bug at:
> > >> > >>
> > >> > >> 1000 ms = try 29 and 5 respectively
> > >> > >> 2000 ms = try 27 and 8 respectively
> > >> > >> 5000 ms = try 38 and 9 respectively
> > >> > >> 10000 ms = not failed yet in 50 and try 9 respectively
> > >> > >>
> > >> > >> With exit sleep at 3000 and startup sleep at 2000 I failed at 36
> > and
> > >> 10
> > >> > >> respectively. I did not try other sleep lengths with both
> sleeps.
> > >> > >>
> > >> > >> Perhaps we could try more sleeps of shorter durations at start
> up
> > in
> > >> > case
> > >> > >> we don't have the best place yet. How about a sleep before
> > creating
> > >> the
> > >> > >> .audacity.sock file? Other places?
> > >> > >>
> > >> > >> It looks like we may not fully solve Audacity launched from
> > outside
> > >> > >> /Applications unless we act on configuration files inside the
> > >> bundle.
> > >> > But
> > >> > >> I
> > >> > >> would like you to suggest more and shorter exit sleeps first, or
> > >> other
> > >> > >> suggestions if you have any.
> > >> > >>
> > >> > >> The fix of force quitting Audacity immediately on launch then
> > >> letting
> > >> > >> launch
> > >> > >> complete still works, providing I get no lock file created.
> > >> > >>
> > >> > >>
> > >> > >> Gale
> > >> > >>
> > >> > >
> > >> > > Not yet the decisive victory I had been hoping for.
> > >> > >
> > >> > > Let me understand:
> > >> > >
> > >> > >
> > >> > >    - Even unmodified, the program is less likely to suffer the
> bug
> > if
> > >> > you
> > >> > >    simply pause long enough between relaunches.  So really it's
> > only
> > >> a
> > >> > >    sequence of rapid relaunches that is the problem.
> > >> >
> > >> > If unmodified 2.1.2 or HEAD, the bug occurs on first launch
> wherever
> > >> > Audacity is launched from.
> > >> >
> > >> > But if using an unmodified jcx codesigned build, then I see the
> > >> > variability
> > >> > that launching from outside /Applications is more prone to the bug,
> > and
> > >> > that exiting and launching again with no pause is more prone to the
> > bug
> > >> > than waiting between launches.
> > >> >
> > >> > Pausing isn't a total cure, even launching Audacity from
> > /Applications.
> > >> >
> > >> > That made me think of testing File > Close in the build I tested
> that
> > >> > has exit and starting sleeps. I don't have any issue if I launch
> > >> Audacity
> > >> > then do COMMAND + W repeatedly without pause. But if I record
> > >> > something then COMMAND + W and don't save changes, this triggered
> > >> > the bug on a couple of occasions. I lost plugins from the menus and
> > >> lost
> > >> > LAME and FFmpeg.  It did not happen if I said yes to Save Changes,
> > >> > though I only tested twice.
> > >> >
> > >> > As yet, I don't have an issue with that in jc10, running and
> > installed
> > >> as
> > >> > Admin with its Portable Settings folder present, but I only tested
> > >> three
> > >> > closes without save and three closes with save. I'd have to test
> more
> > >> > to say jc10 is immune.
> > >> >
> > >> > Yikes. So I guess clearing out the AutoSave folder is also a
> > potential
> > >> > problem, but saving a project also clears out AutoSave. So does
> that
> > >> > also point to another timing issue?
> > >> >
> > >> > If someone saves a Chain, is that going to risk triggering the bug,
> > >> > given we write to a Chains folder in the configuration folder?
> > >> >
> > >> >
> > >> > Paul Licameli wrote
> > >> > >    - When it strikes once, it will invariably strike again until
> > >> either
> > >> > > the
> > >> > >    operating system is rebooted, or you use a quick enough
> > >> force-quit.
> > >> >
> > >> > Yes.
> > >> >
> > >> >
> > >> > Paul Licameli wrote
> > >> > >    - When you force-quit and try again, this is comparably fast,
> to
> > a
> > >> > >    normal program exit followed by another try: in other words
> the
> > >> > timing
> > >> > > of
> > >> > >    your restart in this case, is not an uncontrolled variable.
> > >> >
> > >> > Interesting. I can force quit then start normally as fast as I am
> > >> > physically
> > >> > able, and that always gets rid of the bug.
> > >> >
> > >> > But I just now waited several minutes after force quit, then
> launched
> > >> > Audacity and the bug is still there. Force-quit, launch at once,
> and
> > >> the
> > >> > bug has gone.
> > >> >
> > >> >
> > >> > Paul Licameli wrote
> > >> > > I had a bizarre idea to try next -- perhaps bizarre ideas are
> > needed.
> > >> I
> > >> > > could simulate the force quit.  (By raising SIGTERM.)  I could
> make
> > >> each
> > >> > > start of Audacity launch a process, which would commit suicide,
> but
> > >> > start
> > >> > > a
> > >> > > second process.  If there is something just about the starting
> and
> > >> early
> > >> > > stopping that makes the operating system straighten itself out,
> who
> > >> > knows,
> > >> > > this might work.
> > >> > >
> > >> > > Here is an implementation.  It does not include any of the
> previous
> > >> > > attempted fixes.  It does contain a wxMilliSleep of just 1 msec
> in
> > >> the
> > >> > > non-crashing process.  You might adjust that number.
> > >> > >
> > >> > > https://github.com/Paul-Licameli/audacity/commit/
> > >> > f0135d99c0f232982fe7fb4b10b68aa0385d9b6a
> > >> >
> > >> > OK Paul I will try it ASAP now I've seen this. I'd have said that
> > >> sounds
> > >> > hopeful, but there is still the new Close Project issue I would
> like
> > >> your
> > >> > opinion on.
> > >> >
> > >> >
> > >> > Gale
> > >> >
> > >> > --
> > >> > View this message in context: http://audacity.238276.n2.
> > >> > nabble.com/Bug-1567-startup-sleeps-tp7577731p7577747.html
> > >> > Sent from the audacity-quality mailing list archive at Nabble
> > >>




--
View this message in context: http://audacity.238276.n2.nabble.com/Bug-1567-startup-sleeps-tp7577731p7577781.html
Sent from the audacity-quality mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 1567 startup sleeps

Gale
Administrator
In reply to this post by Paul Licameli
Paul Licameli wrote
Gale, I take it you have not yet tested it.

I don't know why Travis stopped notifying me.

I see you check github for yourself and see my other commits.  Do you still
prefer to be given complete links to commits?
It doesn't hurt to post the link as good practice, for when other than a single
person test things.

I do look at https://github.com/Paul-Licameli/audacity/branches and see the
tick, caution or red cross mark from Travis.  

I had not tested, since Travis seemed to be failing it.


Paul Licameli wrote
I updated the branch, applying the simplification and also reinserting a
sleep that might not be needed at all -- I made it just 1 msec.  The new
tip is now at 52801fc988b43ee02e0d0ec77e07366a7779984b.
Good, thanks. Can't test right now though.

 
Gale


On Fri, Jan 13, 2017 at 2:46 PM, Gale <[hidden email]> wrote:

> Paul Licameli wrote
> > Gale, here is my next iteration:
> >
> > https://github.com/Paul-Licameli/audacity/commit/
> 05e38f44b617577deb6840ec5a8247272e3d3c7f
> >
> > At this commit, you have three more commits since the previous tip of my
> > bug1567-weird2 branch.
> >
> > The first commit moves the fork() to an earlier point, in main(), but
> > still
> > it is the child process that crashes and the original that continues.  I
> > don't expect this is worth experiments yet:  probably the same results as
> > most recently.
> >
> > The second commit makes the child continue and the parent crash.  I
> > predict
> > that this would fix bug 1567, just as well as the bug1567-weird branch
> > did,
> > with the same problems with the windows.  But I prefer this
> implementation
> > over the first attempt.
> >
> > The third commit, linked above, adds an Objective-C call to guarantee
> that
> > our windows come out on top.  It worked for me, while without these calls
> > I
> > did have the lowered windows at least sometimes.
> >
> > I suggest you test the third commit above, and if you are wholly
> satisfied
> > with it, we don't need to bother testing the previous stages.
>
> Thanks Paul.
>
> So do I assume you don't want me to build the tip of weird2 which is
> "Some simplification"
> https://github.com/Paul-Licameli/audacity/commit/9b10b48 ?
>
> I notice that 9b10b48 did not build on Travis and 05e38f4 stalled.
>
>
> Paul Licameli wrote
> > Do I understand from your answer that even in bug1567-weird, which seemed
> > best yet but for the window problems -- the bug still appeared sometimes,
> > BUT it is no longer necessary to reboot macOS to clear it?  That
> > restarting
> > Audacity is now enough?
>
> Using the "weird" fix, I have never got the bug to appear when launching
> Audacity, but the bug can as we now discovered sometimes occur when
> closing the project with the AutoSave folder populated and you don't save
> changes.
>
> That bug occurrence when Audacity is already running isn't peculiar to the
> "weird" or "weird-2" fix attempts. It happens with any of the attempts
> to fix the bug or indeed in jc10.
>
> If the bug occurs when Audacity is already running, yes, merely launching
> the "weird" version cures the bug unless close project triggers it again.
> But reboot still cures it too (for me).
>
> I should say that for some of the users who saw the bug in 2.1.2, reboot
> never cured it - they had to use xattr or execute Audacity from the "MacOS"
> folder within the bundle.
>
>
> Gale
>
>
>
> On Thu, Jan 12, 2017 at 9:09 PM, Gale <gale@> wrote:
>
> > Paul Licameli wrote
> > > Gale,
> > >
> > > Here is a variation of the previous idea, implemented much more simply
> > (I
> > > remembered the Unix fork() function was what I needed).  Again it has a
> > > sleep interval that you might tune.  It differs in that now the first
> > > process continues while it is the child process that crashes at once.
> I
> > > do
> > > not see the fleeting second icon on the dock and I have not yet seen
> the
> > > initial window fail to raise itself.
> > >
> > > Does this still fix the bug?
> > >
> > > https://github.com/Paul-Licameli/audacity/commit/
> > 107ec3281c62d030fde4601b93e529edad58e0a7
> > >
> > > PRL
> >
> > Thanks, Paul.
> >
> > This one is much better for appearance to the user - comes on top, no
> > "ghosts"
> > in the menu bar or Dock, and splash screen appears.
> >
> > It doesn't fully quash the bug as it occurs when Audacity launches. I'm
> > back
> > to failing in about 20 tries when launching Audacity from /Applications
> > and
> > in about five tries when launching from elsewhere.  Increasing the sleep
> > where
> > you have it now in the non-crashing process doesn't seem to help.
> >
> > So is it a sleep position problem we don't have right yet or must we
> > really
> > crash the first process? Can a child process run first with a hidden
> > parent
> > and crash the child? I may be off beam but I have a recollection that the
> > old
> > VST Effects dialogue that popped up before the Audacity window was a
> > "child".
> >
> > I checked the case of the low space warning appearing, and there is no
> > crash
> > with this or the previous "weird" fix.
> >
> >
> > Gale
> >
> > On Wed, Jan 11, 2017 at 10:06 AM, Gale <gale@> wrote:
> >
> > > Paul Licameli wrote
> > > > Good news then!
> > > >
> > > > I was aware that Audacity sometimes is not on top after launch.  For
> > > you,
> > > > that happens always?
> > > >
> > > > Another weird looking thing is that if I watch the tool dock closely,
> > I
> > > > see
> > > > one fleeting Audacity icon grow and shrink, and then a persistent
> one.
> > >
> > > Yes,  never on top for me. Yes, if I look at the dock I can see that
> > too.
> > >
> > > I think the File > Close behaviour is a problem. But saving a Chain
> does
> > > not trigger the bug as far as I can tell. If I find some other way to
> > > trigger
> > > the bug while Audacity is running I'll let you know.
> > >
> > > I modified your previous fix to insert another 1000 ms sleep before the
> > > sock
> > > file
> > > (if I did it right). That helped a lot (no failures yet from
> > > /Applications,
> > > got to
> > > about 20 tries before failing from outside /Applications). Just in case
> > we
> > > still go another route, but it seems you think the simulated force quit
> > is
> > > safe.
> > >
> > >
> > > Gale
> > >
> > >
> > > Paul Licameli wrote
> > > >
> > > > I might fix at least the first of these things.
> > > >
> > > > PRL
> > > >
> > > >
> > > > On Wed, Jan 11, 2017 at 1:12 AM, Gale <
> > >
> > > > gale@
> > >
> > > > > wrote:
> > > >
> > > >> Paul Licameli wrote
> > > >> > Did you not see my message the first time?  I thought I replied to
> > > all.
> > > >> > Well please try this commit.
> > > >> >
> > > >> > PRL
> > > >>
> > > >> No, I see nothing in Gmail from the lists after the 7th, though I
> did
> > > get
> > > >> this
> > > >> message of yours which you Cc'd to me.
> > > >>
> > > >> I built your "weird" fix and at least on my machine, we are getting
> > > >> somewhere
> > > >> at last.
> > > >>
> > > >> I've so far done 40 launches of Audacity from /Applications, and
> > > (really
> > > >> good
> > > >> news) 20 from other locations in my user space, without the bug
> > > appearing
> > > >> on
> > > >> launch. This is with me downloading and running as admin,
> relaunching
> > > at
> > > >> once or waiting 30 seconds. I can't get to force quit Audacity's
> Dock
> > > >> icon
> > > >> now -
> > > >> the option disappears too fast.
> > > >>
> > > >> I do still sometimes (50%?) get the bug if I File > Close with some
> > > data
> > > >> in
> > > >> the
> > > >> AutoSave folder then don't save the project. Setting the single
> sleep
> > > you
> > > >> added
> > > >> to 5000 ms does not stop the File > Close issue.
> > > >>
> > > >> Quitting and relaunching Audacity removes the bug if File > Close
> has
> > > >> triggered
> > > >> it, but does not stop it happening again.
> > > >>
> > > >> Three points that may be problematic.
> > > >>
> > > >> * Audacity never comes on top when launched. I have to task switch
> to
> > > it
> > > >> or
> > > >>    touch its Dock icon to see it.
> > > >>
> > > >> * When I launch Audacity, I do see the start of an Audacity menu bar
> > by
> > > >> the
> > > >>    current menu bar which is then replaced by the menu bar of the
> app
> > > >> that
> > > >> was
> > > >>    on top when I launched Audacity.
> > > >>
> > > >> * There is no splash screen when launching Audacity. I don't know if
> > > that
> > > >> is
> > > >> an
> > > >>    issue if e.g. the disk space warning appears that used to clash
> > with
> > > >> the
> > > >>    splash screen.
> > > >>
> > > >>
> > > >> Gale
> > > >>
> > > >>
> > > >> On Tue, Jan 10, 2017 at 5:14 PM, Gale <gale@> wrote:
> > > >>
> > > >> > Sorry, Paul. I've been staring at Gmail for several days wondering
> > > why
> > > >> > there
> > > >> > was
> > > >> > no reply, but now I looked on Nabble. There is no trace of the
> > > replies
> > > >> in
> > > >> > Gmail
> > > >> > Bin or Spam and no trace of the new posts on -quality since the
> > 7th,
> > > >> hence
> > > >> > I
> > > >> > have not read those yet.
> > > >> >
> > > >> > I am still subscribed to -quality and my delivery enabled
> according
> > > to
> > > >> the
> > > >> > control
> > > >> > panel. I am not receiving -devel either. So at the moment I am
> > > pointing
> > > >> > the
> > > >> > finger
> > > >> > at Gmail and will try a desktop client.
> > > >> >
> > > >> >
> > > >> >
> > > >> > Paul Licameli wrote
> > > >> > > On Sat, Jan 7, 2017 at 1:50 PM, Gale Andrews <
> > > >> >
> > > >> > > gale@
> > > >> >
> > > >> > > > wrote:
> > > >> > >
> > > >> > >> On 7 January 2017 at 00:46, Paul Licameli <
> > > >> >
> > > >> > > paul.licameli@
> > > >> >
> > > >> > > > wrote:
> > > >> > >> >> On Fri, Jan 6, 2017 at 5:23 PM, Gale Andrews <
> > > >> >
> > > >> > > gale@
> > > >> >
> > > >> > > >
> > > >> > >> wrote:
> > > >> > >> >> On very brief testing, Paul's sleeps on exit and init as
> > coded
> > > >> make
> > > >> > >> some
> > > >> > >> >> impact on bug 1567 on my machine, without entirely
> preventing
> > > it.
> > > >> I
> > > >> > >> still
> > > >> > >> >> see about 1 in 8 failures if Audacity is launched outside
> > > >> > >> /Applications,
> > > >> > >> >> but
> > > >> > >> >> I can go up to 25 to 40 launches from /Applications before
> > the
> > > >> bug
> > > >> > >> >> triggers.
> > > >> > >> >>
> > > >> > >> >> So I would like to suggest we tweak sleeps further (do we
> > need
> > > >> > retry?)
> > > >> > >> >> and that we won't need the fix of Audacity as single-user
> > with
> > > a
> > > >> > >> forced
> > > >> > >> >> Portable Settings folder, or User-Settings as amelioration
> of
> > > >> that.
> > > >> > If
> > > >> > >> so,
> > > >> > >> >> does that automatically remove the "damaged" and excessive
> > > >> > >> verification
> > > >> > >> >> time problems encountered above?
> > > >> > >> >
> > > >> > >> >
> > > >> > >> > It is very good to hear at last that the sleeps appear to
> have
> > > an
> > > >> > >> effect
> > > >> > >> on
> > > >> > >> > the probability of the bug.
> > > >> > >> >
> > > >> > >> > I inserted one sleep near startup, in
> > AudacityApp::InitTempDir,
> > > >> and
> > > >> > >> another
> > > >> > >> > at shut-down, in AudacityApp::OnExit.  In each, I made the
> > > >> duration
> > > >> > >> 1000
> > > >> > >> > msec.
> > > >> > >> >
> > > >> > >> > Not yet known:  is the reduced frequency of the problem due
> to
> > > one
> > > >> > >> sleep
> > > >> > >> or
> > > >> > >> > the other, or is the combination necessary?
> > > >> > >> >
> > > >> > >> > You can easily edit those two occurrences of the number 1000
> > to
> > > >> > >> experiment
> > > >> > >> > with longer intervals.
> > > >> > >> >
> > > >> > >> > If the sleep at exit is the important one, and if you must
> > > >> lengthen
> > > >> > >> that
> > > >> > >> > from one to several seconds, even so this might be
> acceptable.
> > > >> The
> > > >> > >> slightly
> > > >> > >> > odd-looking consequence might be that the Audacity icon is
> > slow
> > > to
> > > >> > >> disappear
> > > >> > >> > from the dock, but because the single-instance checker has
> > been
> > > >> > >> destroyed,
> > > >> > >> > that should mean you are not barred from starting up another
> > > >> instance
> > > >> > >> of
> > > >> > >> > Audacity before the first disappears.
> > > >> > >> >
> > > >> > >> > Surely a longer sleep at exit would be more tolerable than at
> > > >> > startup.
> > > >> > >>
> > > >> > >> It's the startup sleep that mainly helps on my machine,
> assuming
> > I
> > > >> > >> relaunch
> > > >> > >> Audacity immediately, rather than wait a while before relaunch,
> > > >> which
> > > >> > >> ameliorates the bug.
> > > >> > >>
> > > >> > >> Increasing the exit sleep to 2000 with no startup sleep makes
> no
> > > >> > >> practical
> > > >> > >> difference to the bug that I can see. Increasing exit sleep to
> > > 3000
> > > >> or
> > > >> > >> 10000
> > > >> > >> with no startup sleep gets me to about 1 in 20 failures
> > launching
> > > >> > >> Audacity
> > > >> > >> from /Applications and 1 in 5 failures launching from elsewhere
> > > (no
> > > >> > >> sleeps is about 1 in 15 and 1 in 3 respectively).
> > > >> > >>
> > > >> > >> If I remove the exit sleep and just have the startup sleep
> > before
> > > >> the
> > > >> > >> single
> > > >> > >> instance checker, in one set of launches I got the bug at:
> > > >> > >>
> > > >> > >> 1000 ms = try 29 and 5 respectively
> > > >> > >> 2000 ms = try 27 and 8 respectively
> > > >> > >> 5000 ms = try 38 and 9 respectively
> > > >> > >> 10000 ms = not failed yet in 50 and try 9 respectively
> > > >> > >>
> > > >> > >> With exit sleep at 3000 and startup sleep at 2000 I failed at
> 36
> > > and
> > > >> 10
> > > >> > >> respectively. I did not try other sleep lengths with both
> > sleeps.
> > > >> > >>
> > > >> > >> Perhaps we could try more sleeps of shorter durations at start
> > up
> > > in
> > > >> > case
> > > >> > >> we don't have the best place yet. How about a sleep before
> > > creating
> > > >> the
> > > >> > >> .audacity.sock file? Other places?
> > > >> > >>
> > > >> > >> It looks like we may not fully solve Audacity launched from
> > > outside
> > > >> > >> /Applications unless we act on configuration files inside the
> > > >> bundle.
> > > >> > But
> > > >> > >> I
> > > >> > >> would like you to suggest more and shorter exit sleeps first,
> or
> > > >> other
> > > >> > >> suggestions if you have any.
> > > >> > >>
> > > >> > >> The fix of force quitting Audacity immediately on launch then
> > > >> letting
> > > >> > >> launch
> > > >> > >> complete still works, providing I get no lock file created.
> > > >> > >>
> > > >> > >>
> > > >> > >> Gale
> > > >> > >>
> > > >> > >
> > > >> > > Not yet the decisive victory I had been hoping for.
> > > >> > >
> > > >> > > Let me understand:
> > > >> > >
> > > >> > >
> > > >> > >    - Even unmodified, the program is less likely to suffer the
> > bug
> > > if
> > > >> > you
> > > >> > >    simply pause long enough between relaunches.  So really it's
> > > only
> > > >> a
> > > >> > >    sequence of rapid relaunches that is the problem.
> > > >> >
> > > >> > If unmodified 2.1.2 or HEAD, the bug occurs on first launch
> > wherever
> > > >> > Audacity is launched from.
> > > >> >
> > > >> > But if using an unmodified jcx codesigned build, then I see the
> > > >> > variability
> > > >> > that launching from outside /Applications is more prone to the
> bug,
> > > and
> > > >> > that exiting and launching again with no pause is more prone to
> the
> > > bug
> > > >> > than waiting between launches.
> > > >> >
> > > >> > Pausing isn't a total cure, even launching Audacity from
> > > /Applications.
> > > >> >
> > > >> > That made me think of testing File > Close in the build I tested
> > that
> > > >> > has exit and starting sleeps. I don't have any issue if I launch
> > > >> Audacity
> > > >> > then do COMMAND + W repeatedly without pause. But if I record
> > > >> > something then COMMAND + W and don't save changes, this triggered
> > > >> > the bug on a couple of occasions. I lost plugins from the menus
> and
> > > >> lost
> > > >> > LAME and FFmpeg.  It did not happen if I said yes to Save Changes,
> > > >> > though I only tested twice.
> > > >> >
> > > >> > As yet, I don't have an issue with that in jc10, running and
> > > installed
> > > >> as
> > > >> > Admin with its Portable Settings folder present, but I only tested
> > > >> three
> > > >> > closes without save and three closes with save. I'd have to test
> > more
> > > >> > to say jc10 is immune.
> > > >> >
> > > >> > Yikes. So I guess clearing out the AutoSave folder is also a
> > > potential
> > > >> > problem, but saving a project also clears out AutoSave. So does
> > that
> > > >> > also point to another timing issue?
> > > >> >
> > > >> > If someone saves a Chain, is that going to risk triggering the
> bug,
> > > >> > given we write to a Chains folder in the configuration folder?
> > > >> >
> > > >> >
> > > >> > Paul Licameli wrote
> > > >> > >    - When it strikes once, it will invariably strike again until
> > > >> either
> > > >> > > the
> > > >> > >    operating system is rebooted, or you use a quick enough
> > > >> force-quit.
> > > >> >
> > > >> > Yes.
> > > >> >
> > > >> >
> > > >> > Paul Licameli wrote
> > > >> > >    - When you force-quit and try again, this is comparably fast,
> > to
> > > a
> > > >> > >    normal program exit followed by another try: in other words
> > the
> > > >> > timing
> > > >> > > of
> > > >> > >    your restart in this case, is not an uncontrolled variable.
> > > >> >
> > > >> > Interesting. I can force quit then start normally as fast as I am
> > > >> > physically
> > > >> > able, and that always gets rid of the bug.
> > > >> >
> > > >> > But I just now waited several minutes after force quit, then
> > launched
> > > >> > Audacity and the bug is still there. Force-quit, launch at once,
> > and
> > > >> the
> > > >> > bug has gone.
> > > >> >
> > > >> >
> > > >> > Paul Licameli wrote
> > > >> > > I had a bizarre idea to try next -- perhaps bizarre ideas are
> > > needed.
> > > >> I
> > > >> > > could simulate the force quit.  (By raising SIGTERM.)  I could
> > make
> > > >> each
> > > >> > > start of Audacity launch a process, which would commit suicide,
> > but
> > > >> > start
> > > >> > > a
> > > >> > > second process.  If there is something just about the starting
> > and
> > > >> early
> > > >> > > stopping that makes the operating system straighten itself out,
> > who
> > > >> > knows,
> > > >> > > this might work.
> > > >> > >
> > > >> > > Here is an implementation.  It does not include any of the
> > previous
> > > >> > > attempted fixes.  It does contain a wxMilliSleep of just 1 msec
> > in
> > > >> the
> > > >> > > non-crashing process.  You might adjust that number.
> > > >> > >
> > > >> > > https://github.com/Paul-Licameli/audacity/commit/
> > > >> > f0135d99c0f232982fe7fb4b10b68aa0385d9b6a
> > > >> >
> > > >> > OK Paul I will try it ASAP now I've seen this. I'd have said that
> > > >> sounds
> > > >> > hopeful, but there is still the new Close Project issue I would
> > like
> > > >> your
> > > >> > opinion on.
> > > >> >
> > > >> >
> > > >> > Gale
> > > >> >
> > > >> > --
> > > >> > View this message in context: http://audacity.238276.n2.
> > > >> > nabble.com/Bug-1567-startup-sleeps-tp7577731p7577747.html
> > > >> > Sent from the audacity-quality mailing list archive at Nabble
> > > >>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 1567 startup sleeps

Gale
Administrator
In reply to this post by Paul Licameli
Paul Licameli wrote
On Fri, Jan 13, 2017 at 2:46 PM, Gale <[hidden email]> wrote:

> Paul Licameli wrote
> > Gale, here is my next iteration:
> >
> > https://github.com/Paul-Licameli/audacity/commit/
> 05e38f44b617577deb6840ec5a8247272e3d3c7f
> >
> > At this commit, you have three more commits since the previous tip of my
> > bug1567-weird2 branch.
> >
> > The first commit moves the fork() to an earlier point, in main(), but
> > still
> > it is the child process that crashes and the original that continues.  I
> > don't expect this is worth experiments yet:  probably the same results as
> > most recently.
> >
> > The second commit makes the child continue and the parent crash.  I
> > predict
> > that this would fix bug 1567, just as well as the bug1567-weird branch
> > did,
> > with the same problems with the windows.  But I prefer this
> implementation
> > over the first attempt.
> >
> > The third commit, linked above, adds an Objective-C call to guarantee
> that
> > our windows come out on top.  It worked for me, while without these calls
> > I
> > did have the lowered windows at least sometimes.
> >
> > I suggest you test the third commit above, and if you are wholly
> satisfied
> > with it, we don't need to bother testing the previous stages.
>
> Thanks Paul.
>
> So do I assume you don't want me to build the tip of weird2 which is
> "Some simplification"
> https://github.com/Paul-Licameli/audacity/commit/9b10b48 ?
>
> I notice that 9b10b48 did not build on Travis and 05e38f4 stalled.
>
>
> Paul Licameli wrote
> > Do I understand from your answer that even in bug1567-weird, which seemed
> > best yet but for the window problems -- the bug still appeared sometimes,
> > BUT it is no longer necessary to reboot macOS to clear it?  That
> > restarting
> > Audacity is now enough?
>
> Using the "weird" fix, I have never got the bug to appear when launching
> Audacity, but the bug can as we now discovered sometimes occur when
> closing the project with the AutoSave folder populated and you don't save
> changes.
>
> That bug occurrence when Audacity is already running isn't peculiar to the
> "weird" or "weird-2" fix attempts. It happens with any of the attempts
> to fix the bug or indeed in jc10.
>
> If the bug occurs when Audacity is already running, yes, merely launching
> the "weird" version cures the bug unless close project triggers it again.
> But reboot still cures it too (for me).
>
> I should say that for some of the users who saw the bug in 2.1.2, reboot
> never cured it - they had to use xattr or execute Audacity from the "MacOS"
> folder within the bundle.
>
>
Explain these workarounds to me?  Some other users in communication with me
may need advice for using 2.1.2 on Sierra, and they report that they can't
find certain .ny files in the effects manager dialog, no matter what folder
they are in.
With bug 1567 as I've experienced it and seen it reported, the blocked effects
are always listed in "All" and New" in Plug-in Manager, but are missing from the
Audacity menus. If the plugins are enabled by the user in Plug-in Manager, they
go back to "New".

The other reason that Nyquist effects (only) are missing from the menus
(unless disabled in Preferences) is if the user runs Audacity from the DMG. It's a
quite common user error:
http://forum.audacityteam.org/viewtopic.php?f=47&t=75660 .

Paul Licameli wrote
 
I am not familiar with xattr.

Do you also mean that a workaround is navigating inside the bundle in
Finder, and then directly opening the executable?
Exactly (or symlinking to it then executing the symlink).

Here is the stock answer to those hit by bug 1567 in 2.1.2 who present
on the Forum:
http://forum.audacityteam.org/viewtopic.php?p=316041#p316041 .


Gale

 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 1567 startup sleeps

Gale
Administrator
In reply to this post by Paul Licameli
Bug 543 is still fixed in latest weird2 - sufficient information is available in
System Information.

The execve made detection of Lame/FFmpeg much more reliable. It's best
left in.  

The latest weird2 at 52801fc fixes 1567 for Audacity launch exactly as weird
did. File > Close can still trigger bug 1567. Increasing or reducing the sleep
length after the fork and exec does not change that or cause 1567 to trigger
when launching.      

There is no ghost in the menu bar when launching latest weird2 and the app
always comes on top.

As I assume you know there is no splash screen (low disk space warning is
not a problem). I also notice the Audacity Dock icon behaves unlike any
other app I have. Instead of a complete and slow bounce until the app appears,
there is a fast jump up to half the normal height and back down, and then
the normal bounce.


Gale
     

Paul Licameli wrote
Gale, I had to move the call to execve in main for my latest experiment.

Reseach in code history shows this comes from commit
 36361a6b86dac4b0f2b16b7017007b4cc7717c7a

which was meant to fix http://bugzilla.audacityteam.org/show_bug.cgi?id=543

And I don't really understand the reason for this execve call, but comments
show this change was also related to the loading of LAME and FFmpeg
libraries.

I wonder now what the effect of simply deleting the execve call from master
head would be on bug 1567?

PRL



On Fri, Jan 13, 2017 at 11:15 AM, Paul Licameli <[hidden email]>
wrote:

> Gale, here is my next iteration:
>
> https://github.com/Paul-Licameli/audacity/commit/
> 05e38f44b617577deb6840ec5a8247272e3d3c7f
>
> At this commit, you have three more commits since the previous tip of my
> bug1567-weird2 branch.
>
> The first commit moves the fork() to an earlier point, in main(), but
> still it is the child process that crashes and the original that
> continues.  I don't expect this is worth experiments yet:  probably the
> same results as most recently.
>
> The second commit makes the child continue and the parent crash.  I
> predict that this would fix bug 1567, just as well as the bug1567-weird
> branch did, with the same problems with the windows.  But I prefer this
> implementation over the first attempt.
>
> The third commit, linked above, adds an Objective-C call to guarantee that
> our windows come out on top.  It worked for me, while without these calls I
> did have the lowered windows at least sometimes.
>
> I suggest you test the third commit above, and if you are wholly satisfied
> with it, we don't need to bother testing the previous stages.
>
> Do I understand from your answer that even in bug1567-weird, which seemed
> best yet but for the window problems -- the bug still appeared sometimes,
> BUT it is no longer necessary to reboot macOS to clear it?  That restarting
> Audacity is now enough?
>
> PRL
>
>
>
> On Thu, Jan 12, 2017 at 9:09 PM, Gale <[hidden email]> wrote:
>
>> Paul Licameli wrote
>> > Gale,
>> >
>> > Here is a variation of the previous idea, implemented much more simply
>> (I
>> > remembered the Unix fork() function was what I needed).  Again it has a
>> > sleep interval that you might tune.  It differs in that now the first
>> > process continues while it is the child process that crashes at once.  I
>> > do
>> > not see the fleeting second icon on the dock and I have not yet seen the
>> > initial window fail to raise itself.
>> >
>> > Does this still fix the bug?
>> >
>> > https://github.com/Paul-Licameli/audacity/commit/107ec3281c6
>> 2d030fde4601b93e529edad58e0a7
>> >
>> > PRL
>>
>> Thanks, Paul.
>>
>> This one is much better for appearance to the user - comes on top, no
>> "ghosts"
>> in the menu bar or Dock, and splash screen appears.
>>
>> It doesn't fully quash the bug as it occurs when Audacity launches. I'm
>> back
>> to failing in about 20 tries when launching Audacity from /Applications
>> and
>> in about five tries when launching from elsewhere.  Increasing the sleep
>> where
>> you have it now in the non-crashing process doesn't seem to help.
>>
>> So is it a sleep position problem we don't have right yet or must we
>> really
>> crash the first process? Can a child process run first with a hidden
>> parent
>> and crash the child? I may be off beam but I have a recollection that the
>> old
>> VST Effects dialogue that popped up before the Audacity window was a
>> "child".
>>
>> I checked the case of the low space warning appearing, and there is no
>> crash
>> with this or the previous "weird" fix.
>>
>>
>> Gale
>>
>> On Wed, Jan 11, 2017 at 10:06 AM, Gale <gale@> wrote:
>>
>> > Paul Licameli wrote
>> > > Good news then!
>> > >
>> > > I was aware that Audacity sometimes is not on top after launch.  For
>> > you,
>> > > that happens always?
>> > >
>> > > Another weird looking thing is that if I watch the tool dock closely,
>> I
>> > > see
>> > > one fleeting Audacity icon grow and shrink, and then a persistent one.
>> >
>> > Yes,  never on top for me. Yes, if I look at the dock I can see that
>> too.
>> >
>> > I think the File > Close behaviour is a problem. But saving a Chain does
>> > not trigger the bug as far as I can tell. If I find some other way to
>> > trigger
>> > the bug while Audacity is running I'll let you know.
>> >
>> > I modified your previous fix to insert another 1000 ms sleep before the
>> > sock
>> > file
>> > (if I did it right). That helped a lot (no failures yet from
>> > /Applications,
>> > got to
>> > about 20 tries before failing from outside /Applications). Just in case
>> we
>> > still go another route, but it seems you think the simulated force quit
>> is
>> > safe.
>> >
>> >
>> > Gale
>> >
>> >
>> > Paul Licameli wrote
>> > >
>> > > I might fix at least the first of these things.
>> > >
>> > > PRL
>> > >
>> > >
>> > > On Wed, Jan 11, 2017 at 1:12 AM, Gale <
>> >
>> > > gale@
>> >
>> > > > wrote:
>> > >
>> > >> Paul Licameli wrote
>> > >> > Did you not see my message the first time?  I thought I replied to
>> > all.
>> > >> > Well please try this commit.
>> > >> >
>> > >> > PRL
>> > >>
>> > >> No, I see nothing in Gmail from the lists after the 7th, though I did
>> > get
>> > >> this
>> > >> message of yours which you Cc'd to me.
>> > >>
>> > >> I built your "weird" fix and at least on my machine, we are getting
>> > >> somewhere
>> > >> at last.
>> > >>
>> > >> I've so far done 40 launches of Audacity from /Applications, and
>> > (really
>> > >> good
>> > >> news) 20 from other locations in my user space, without the bug
>> > appearing
>> > >> on
>> > >> launch. This is with me downloading and running as admin, relaunching
>> > at
>> > >> once or waiting 30 seconds. I can't get to force quit Audacity's Dock
>> > >> icon
>> > >> now -
>> > >> the option disappears too fast.
>> > >>
>> > >> I do still sometimes (50%?) get the bug if I File > Close with some
>> > data
>> > >> in
>> > >> the
>> > >> AutoSave folder then don't save the project. Setting the single sleep
>> > you
>> > >> added
>> > >> to 5000 ms does not stop the File > Close issue.
>> > >>
>> > >> Quitting and relaunching Audacity removes the bug if File > Close has
>> > >> triggered
>> > >> it, but does not stop it happening again.
>> > >>
>> > >> Three points that may be problematic.
>> > >>
>> > >> * Audacity never comes on top when launched. I have to task switch to
>> > it
>> > >> or
>> > >>    touch its Dock icon to see it.
>> > >>
>> > >> * When I launch Audacity, I do see the start of an Audacity menu bar
>> by
>> > >> the
>> > >>    current menu bar which is then replaced by the menu bar of the app
>> > >> that
>> > >> was
>> > >>    on top when I launched Audacity.
>> > >>
>> > >> * There is no splash screen when launching Audacity. I don't know if
>> > that
>> > >> is
>> > >> an
>> > >>    issue if e.g. the disk space warning appears that used to clash
>> with
>> > >> the
>> > >>    splash screen.
>> > >>
>> > >>
>> > >> Gale
>> > >>
>> > >>
>> > >> On Tue, Jan 10, 2017 at 5:14 PM, Gale <gale@> wrote:
>> > >>
>> > >> > Sorry, Paul. I've been staring at Gmail for several days wondering
>> > why
>> > >> > there
>> > >> > was
>> > >> > no reply, but now I looked on Nabble. There is no trace of the
>> > replies
>> > >> in
>> > >> > Gmail
>> > >> > Bin or Spam and no trace of the new posts on -quality since the
>> 7th,
>> > >> hence
>> > >> > I
>> > >> > have not read those yet.
>> > >> >
>> > >> > I am still subscribed to -quality and my delivery enabled according
>> > to
>> > >> the
>> > >> > control
>> > >> > panel. I am not receiving -devel either. So at the moment I am
>> > pointing
>> > >> > the
>> > >> > finger
>> > >> > at Gmail and will try a desktop client.
>> > >> >
>> > >> >
>> > >> >
>> > >> > Paul Licameli wrote
>> > >> > > On Sat, Jan 7, 2017 at 1:50 PM, Gale Andrews <
>> > >> >
>> > >> > > gale@
>> > >> >
>> > >> > > > wrote:
>> > >> > >
>> > >> > >> On 7 January 2017 at 00:46, Paul Licameli <
>> > >> >
>> > >> > > paul.licameli@
>> > >> >
>> > >> > > > wrote:
>> > >> > >> >> On Fri, Jan 6, 2017 at 5:23 PM, Gale Andrews <
>> > >> >
>> > >> > > gale@
>> > >> >
>> > >> > > >
>> > >> > >> wrote:
>> > >> > >> >> On very brief testing, Paul's sleeps on exit and init as
>> coded
>> > >> make
>> > >> > >> some
>> > >> > >> >> impact on bug 1567 on my machine, without entirely preventing
>> > it.
>> > >> I
>> > >> > >> still
>> > >> > >> >> see about 1 in 8 failures if Audacity is launched outside
>> > >> > >> /Applications,
>> > >> > >> >> but
>> > >> > >> >> I can go up to 25 to 40 launches from /Applications before
>> the
>> > >> bug
>> > >> > >> >> triggers.
>> > >> > >> >>
>> > >> > >> >> So I would like to suggest we tweak sleeps further (do we
>> need
>> > >> > retry?)
>> > >> > >> >> and that we won't need the fix of Audacity as single-user
>> with
>> > a
>> > >> > >> forced
>> > >> > >> >> Portable Settings folder, or User-Settings as amelioration of
>> > >> that.
>> > >> > If
>> > >> > >> so,
>> > >> > >> >> does that automatically remove the "damaged" and excessive
>> > >> > >> verification
>> > >> > >> >> time problems encountered above?
>> > >> > >> >
>> > >> > >> >
>> > >> > >> > It is very good to hear at last that the sleeps appear to have
>> > an
>> > >> > >> effect
>> > >> > >> on
>> > >> > >> > the probability of the bug.
>> > >> > >> >
>> > >> > >> > I inserted one sleep near startup, in
>> AudacityApp::InitTempDir,
>> > >> and
>> > >> > >> another
>> > >> > >> > at shut-down, in AudacityApp::OnExit.  In each, I made the
>> > >> duration
>> > >> > >> 1000
>> > >> > >> > msec.
>> > >> > >> >
>> > >> > >> > Not yet known:  is the reduced frequency of the problem due to
>> > one
>> > >> > >> sleep
>> > >> > >> or
>> > >> > >> > the other, or is the combination necessary?
>> > >> > >> >
>> > >> > >> > You can easily edit those two occurrences of the number 1000
>> to
>> > >> > >> experiment
>> > >> > >> > with longer intervals.
>> > >> > >> >
>> > >> > >> > If the sleep at exit is the important one, and if you must
>> > >> lengthen
>> > >> > >> that
>> > >> > >> > from one to several seconds, even so this might be acceptable.
>> > >> The
>> > >> > >> slightly
>> > >> > >> > odd-looking consequence might be that the Audacity icon is
>> slow
>> > to
>> > >> > >> disappear
>> > >> > >> > from the dock, but because the single-instance checker has
>> been
>> > >> > >> destroyed,
>> > >> > >> > that should mean you are not barred from starting up another
>> > >> instance
>> > >> > >> of
>> > >> > >> > Audacity before the first disappears.
>> > >> > >> >
>> > >> > >> > Surely a longer sleep at exit would be more tolerable than at
>> > >> > startup.
>> > >> > >>
>> > >> > >> It's the startup sleep that mainly helps on my machine,
>> assuming I
>> > >> > >> relaunch
>> > >> > >> Audacity immediately, rather than wait a while before relaunch,
>> > >> which
>> > >> > >> ameliorates the bug.
>> > >> > >>
>> > >> > >> Increasing the exit sleep to 2000 with no startup sleep makes no
>> > >> > >> practical
>> > >> > >> difference to the bug that I can see. Increasing exit sleep to
>> > 3000
>> > >> or
>> > >> > >> 10000
>> > >> > >> with no startup sleep gets me to about 1 in 20 failures
>> launching
>> > >> > >> Audacity
>> > >> > >> from /Applications and 1 in 5 failures launching from elsewhere
>> > (no
>> > >> > >> sleeps is about 1 in 15 and 1 in 3 respectively).
>> > >> > >>
>> > >> > >> If I remove the exit sleep and just have the startup sleep
>> before
>> > >> the
>> > >> > >> single
>> > >> > >> instance checker, in one set of launches I got the bug at:
>> > >> > >>
>> > >> > >> 1000 ms = try 29 and 5 respectively
>> > >> > >> 2000 ms = try 27 and 8 respectively
>> > >> > >> 5000 ms = try 38 and 9 respectively
>> > >> > >> 10000 ms = not failed yet in 50 and try 9 respectively
>> > >> > >>
>> > >> > >> With exit sleep at 3000 and startup sleep at 2000 I failed at 36
>> > and
>> > >> 10
>> > >> > >> respectively. I did not try other sleep lengths with both
>> sleeps.
>> > >> > >>
>> > >> > >> Perhaps we could try more sleeps of shorter durations at start
>> up
>> > in
>> > >> > case
>> > >> > >> we don't have the best place yet. How about a sleep before
>> > creating
>> > >> the
>> > >> > >> .audacity.sock file? Other places?
>> > >> > >>
>> > >> > >> It looks like we may not fully solve Audacity launched from
>> > outside
>> > >> > >> /Applications unless we act on configuration files inside the
>> > >> bundle.
>> > >> > But
>> > >> > >> I
>> > >> > >> would like you to suggest more and shorter exit sleeps first, or
>> > >> other
>> > >> > >> suggestions if you have any.
>> > >> > >>
>> > >> > >> The fix of force quitting Audacity immediately on launch then
>> > >> letting
>> > >> > >> launch
>> > >> > >> complete still works, providing I get no lock file created.
>> > >> > >>
>> > >> > >>
>> > >> > >> Gale
>> > >> > >>
>> > >> > >
>> > >> > > Not yet the decisive victory I had been hoping for.
>> > >> > >
>> > >> > > Let me understand:
>> > >> > >
>> > >> > >
>> > >> > >    - Even unmodified, the program is less likely to suffer the
>> bug
>> > if
>> > >> > you
>> > >> > >    simply pause long enough between relaunches.  So really it's
>> > only
>> > >> a
>> > >> > >    sequence of rapid relaunches that is the problem.
>> > >> >
>> > >> > If unmodified 2.1.2 or HEAD, the bug occurs on first launch
>> wherever
>> > >> > Audacity is launched from.
>> > >> >
>> > >> > But if using an unmodified jcx codesigned build, then I see the
>> > >> > variability
>> > >> > that launching from outside /Applications is more prone to the bug,
>> > and
>> > >> > that exiting and launching again with no pause is more prone to the
>> > bug
>> > >> > than waiting between launches.
>> > >> >
>> > >> > Pausing isn't a total cure, even launching Audacity from
>> > /Applications.
>> > >> >
>> > >> > That made me think of testing File > Close in the build I tested
>> that
>> > >> > has exit and starting sleeps. I don't have any issue if I launch
>> > >> Audacity
>> > >> > then do COMMAND + W repeatedly without pause. But if I record
>> > >> > something then COMMAND + W and don't save changes, this triggered
>> > >> > the bug on a couple of occasions. I lost plugins from the menus and
>> > >> lost
>> > >> > LAME and FFmpeg.  It did not happen if I said yes to Save Changes,
>> > >> > though I only tested twice.
>> > >> >
>> > >> > As yet, I don't have an issue with that in jc10, running and
>> > installed
>> > >> as
>> > >> > Admin with its Portable Settings folder present, but I only tested
>> > >> three
>> > >> > closes without save and three closes with save. I'd have to test
>> more
>> > >> > to say jc10 is immune.
>> > >> >
>> > >> > Yikes. So I guess clearing out the AutoSave folder is also a
>> > potential
>> > >> > problem, but saving a project also clears out AutoSave. So does
>> that
>> > >> > also point to another timing issue?
>> > >> >
>> > >> > If someone saves a Chain, is that going to risk triggering the bug,
>> > >> > given we write to a Chains folder in the configuration folder?
>> > >> >
>> > >> >
>> > >> > Paul Licameli wrote
>> > >> > >    - When it strikes once, it will invariably strike again until
>> > >> either
>> > >> > > the
>> > >> > >    operating system is rebooted, or you use a quick enough
>> > >> force-quit.
>> > >> >
>> > >> > Yes.
>> > >> >
>> > >> >
>> > >> > Paul Licameli wrote
>> > >> > >    - When you force-quit and try again, this is comparably fast,
>> to
>> > a
>> > >> > >    normal program exit followed by another try: in other words
>> the
>> > >> > timing
>> > >> > > of
>> > >> > >    your restart in this case, is not an uncontrolled variable.
>> > >> >
>> > >> > Interesting. I can force quit then start normally as fast as I am
>> > >> > physically
>> > >> > able, and that always gets rid of the bug.
>> > >> >
>> > >> > But I just now waited several minutes after force quit, then
>> launched
>> > >> > Audacity and the bug is still there. Force-quit, launch at once,
>> and
>> > >> the
>> > >> > bug has gone.
>> > >> >
>> > >> >
>> > >> > Paul Licameli wrote
>> > >> > > I had a bizarre idea to try next -- perhaps bizarre ideas are
>> > needed.
>> > >> I
>> > >> > > could simulate the force quit.  (By raising SIGTERM.)  I could
>> make
>> > >> each
>> > >> > > start of Audacity launch a process, which would commit suicide,
>> but
>> > >> > start
>> > >> > > a
>> > >> > > second process.  If there is something just about the starting
>> and
>> > >> early
>> > >> > > stopping that makes the operating system straighten itself out,
>> who
>> > >> > knows,
>> > >> > > this might work.
>> > >> > >
>> > >> > > Here is an implementation.  It does not include any of the
>> previous
>> > >> > > attempted fixes.  It does contain a wxMilliSleep of just 1 msec
>> in
>> > >> the
>> > >> > > non-crashing process.  You might adjust that number.
>> > >> > >
>> > >> > > https://github.com/Paul-Licameli/audacity/commit/
>> > >> > f0135d99c0f232982fe7fb4b10b68aa0385d9b6a
>> > >> >
>> > >> > OK Paul I will try it ASAP now I've seen this. I'd have said that
>> > >> sounds
>> > >> > hopeful, but there is still the new Close Project issue I would
>> like
>> > >> your
>> > >> > opinion on.
>> > >> >
>> > >> >
>> > >> > Gale
>> > >> >
>> > >> > --
>> > >> > View this message in context: http://audacity.238276.n2.
>> > >> > nabble.com/Bug-1567-startup-sleeps-tp7577731p7577747.html
>> > >> > Sent from the audacity-quality mailing list ar
12
Loading...