[Audacity-devel] GetLinked()

Paul, are we going to banish GetLinked() for 2.2.0 or wait until a later
release?

--James.

David Bailes

2017-06-17 09:52:57 UTC

Post by James Crook
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a later
release?

James, is this a change to how stereo tracks are handled? What is the new
design going to be?

I've been looking at why Audacity is crashing when Jaws is also running on
the Windows 10 creators update.
When Jaws is running there appear to be more paint messages being sent to
Audacity, though it's unclear to me what is causing this.
For example when deleting a stereo track, a paint message can occur after
one of the tracks has been removed, and this causes audacity to crash.
Regardless of whether these extra paint message should be occurring, the
code for removing stereo tracks sends update events after each of the two
tracks is removed from the track list, rather than a single update event
after both tracks have be removed. This doesn't seem right.

Hence my interest in any changes to the design of stereo tracks.

David.

Post by James Crook
--James.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

James Crook

2017-06-17 10:42:43 UTC

David,

I'm relatively new to the party in terms of looking at actual screen
reader behaviour. I notice that Audacity with Narrator on leaks memory
like a sieve. Paul's cleaning up of naked news means non-narrator use
does not memory leak, so it makes these leaks more obvious. That leads
me to think that wxWidgets with any screen reader is code that is less
well exercised and tested, i.e. expect many bugs relating to screen
readers in wxWidgets. Probably we can find workarounds, staying on the
parts that do work, rather than complete fixes. But we may only be able
to ameliorate the problems rather than fix them.

I talked with Leland about screen readers at AU14 conference, and we
both were keen to provide access to Audacity algorithms at more of a
command line like level to get better accessibility. Long term this is
still in my view the best way to improve accessibility of Audacity -
i.e. have an alternative front end for the same audio engine. Have the
normal GUI which makes some assumptions about a user using a mouse, and
a more command line GUI that still has menus for access, but that is
geared for automation and keyboard use - with explicit binding of mouse
wheel and x-y to controlled values rather than implicit binding by click
and drag.

IF frequent repainting is causing problems for Jaws, we can / should
ameliorate by removing redundant repaintings. That will be better for
all. Audacity has a somewhat Jekyll and Hyde attitude to repainting.
It has event based repainting and periodic painting off a timer. At
some future time we should clean that up too.

The Windows 10 creators update has done some strange things at start
up. The splash screen now appears sooner, and so it appears before it
has been positioned. We have some strange code with the splash screen
to work around a problem with the possibility of having splash screen
and error dialog at the same time, before the app has fully started.
There should not be a need for our own event loop (which is what we
have). I think our workarounds maybe should be untangled. As it is we
show and hide our splash screen rather quickly now, so it does not serve
the role of a splash screen, that reassures you that the app is starting
up.

This doesn't directly answer the question of Jaws crashes, but may be
useful none the less.

--James.

Post by James Crook
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a later
release?

James, is this a change to how stereo tracks are handled? What is the new
design going to be?
I've been looking at why Audacity is crashing when Jaws is also running on
the Windows 10 creators update.
When Jaws is running there appear to be more paint messages being sent to
Audacity, though it's unclear to me what is causing this.
For example when deleting a stereo track, a paint message can occur after
one of the tracks has been removed, and this causes audacity to crash.
Regardless of whether these extra paint message should be occurring, the
code for removing stereo tracks sends update events after each of the two
tracks is removed from the track list, rather than a single update event
after both tracks have be removed. This doesn't seem right.
Hence my interest in any changes to the design of stereo tracks.
David.

Post by James Crook
--James.

David Bailes

2017-06-17 11:28:28 UTC

I'm unsure about this alternative front end, but it's a discussion for
another day.

Post by James Crook
IF frequent repainting is causing problems for Jaws, we can / should
ameliorate by removing redundant repaintings. That will be better for
all. Audacity has a somewhat Jekyll and Hyde attitude to repainting. It
has event based repainting and periodic painting off a timer.

Is the periodic painting off a timer "on" all the time? Where is the code?

Is there more than one event loop? Where is the code for our own event loop?

Post by James Crook
I think our workarounds maybe should be untangled. As it is we show and
hide our splash screen rather quickly now, so it does not serve the role of
a splash screen, that reassures you that the app is starting up.
This doesn't directly answer the question of Jaws crashes, but may be
useful none the less.

very useful, thanks.

Post by James Crook
--James.

Post by James Crook
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a later

Post by James Crook
release?
James, is this a change to how stereo tracks are handled? What is the new

design going to be?
I've been looking at why Audacity is crashing when Jaws is also running on
the Windows 10 creators update.
When Jaws is running there appear to be more paint messages being sent to
Audacity, though it's unclear to me what is causing this.
For example when deleting a stereo track, a paint message can occur after
one of the tracks has been removed, and this causes audacity to crash.
Regardless of whether these extra paint message should be occurring, the
code for removing stereo tracks sends update events after each of the two
tracks is removed from the track list, rather than a single update event
after both tracks have be removed. This doesn't seem right.
Hence my interest in any changes to the design of stereo tracks.
David.
--James.

James Crook

2017-06-17 13:04:17 UTC

I'm unsure about this alternative front end, but it's a discussion for
another day.

Is the periodic painting off a timer "on" all the time? Where is the code?

You'll need to investigate..

mTimer.Start(kTimerInterval, FALSE);

kTimerInterval is 50ms, which is 20 fps, which applies to the overlays.

void TrackPanel::OnTimer(wxTimerEvent& )

Which calls
DrawOverlays(false);
mRuler->DrawOverlays(false);

And every fifth call does:

mRefreshBacking = true;
Refresh( false );

so 4fps for complete repaints.

Is there more than one event loop? Where is the code for our own event loop?

At start up we have:
wxEventLoopGuarantor eventLoop;

created in
bool AudacityApp::OnInit()

I (probably mistakenly) thought this created a temporary event loop.

--James.

very useful, thanks.

Post by James Crook
--James.

Post by James Crook
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a later

Post by James Crook
release?
James, is this a change to how stereo tracks are handled? What is the new

Paul Licameli

2017-06-17 14:52:25 UTC

Maybe I need to work my way onto the wxWidget team too and do for their
memory management what I did for ours.

Post by James Crook
I talked with Leland about screen readers at AU14 conference, and we both
were keen to provide access to Audacity algorithms at more of a command
line like level to get better accessibility. Long term this is still in my
view the best way to improve accessibility of Audacity - i.e. have an
alternative front end for the same audio engine. Have the normal GUI which
makes some assumptions about a user using a mouse, and a more command line
GUI that still has menus for access, but that is geared for automation and
keyboard use - with explicit binding of mouse wheel and x-y to controlled
values rather than implicit binding by click and drag.
I'm unsure about this alternative front end, but it's a discussion for
another day.
IF frequent repainting is causing problems for Jaws, we can / should
ameliorate by removing redundant repaintings. That will be better for
all. Audacity has a somewhat Jekyll and Hyde attitude to repainting. It
has event based repainting and periodic painting off a timer.
Is the periodic painting off a timer "on" all the time? Where is the code?
You'll need to investigate..
mTimer.Start(kTimerInterval, FALSE);
kTimerInterval is 50ms, which is 20 fps, which applies to the overlays.
void TrackPanel::OnTimer(wxTimerEvent& )
Which calls
DrawOverlays(false);
mRuler->DrawOverlays(false);
mRefreshBacking = true;
Refresh( false );
so 4fps for complete repaints.

I believe that timer driven repaint occurs only during recording and
playback. If you only play back, with an unpinned play head, then I
believe it is doing only a cheap update of the green line, by repainting a
saved rectangle over its old position, saving the pixels at the new
position, and then overpainting those.

As you can imagine, more complete repaints are needed if the playhead is
pinned, or if you record and lay down new audio.

In 2.1.3 Track preferences we had a checkbox for "Update display when
Recording/Playback head unpinned" which might help you here. But that has
been removed from 2.2.0. I recall there was some discussion whether faster
computers these days make this choice less valuable to anybody. Maybe you
want to lobby to put that preference back?

PRL

Post by James Crook
At some future time we should clean that up too.
The Windows 10 creators update has done some strange things at start up.
The splash screen now appears sooner, and so it appears before it has been
positioned. We have some strange code with the splash screen to work
around a problem with the possibility of having splash screen and error
dialog at the same time, before the app has fully started. There should
not be a need for our own event loop (which is what we have).
Is there more than one event loop? Where is the code for our own event loop?
wxEventLoopGuarantor eventLoop;
created in
bool AudacityApp::OnInit()
I (probably mistakenly) thought this created a temporary event loop.
--James.
I think our workarounds maybe should be untangled. As it is we show and
hide our splash screen rather quickly now, so it does not serve the role of
a splash screen, that reassures you that the app is starting up.
This doesn't directly answer the question of Jaws crashes, but may be
useful none the less.
very useful, thanks.
--James.
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a later
release?
James, is this a change to how stereo tracks are handled? What is the new
design going to be?
I've been looking at why Audacity is crashing when Jaws is also running on
the Windows 10 creators update.
When Jaws is running there appear to be more paint messages being sent to
Audacity, though it's unclear to me what is causing this.
For example when deleting a stereo track, a paint message can occur after
one of the tracks has been removed, and this causes audacity to crash.
Regardless of whether these extra paint message should be occurring, the
code for removing stereo tracks sends update events after each of the two
tracks is removed from the track list, rather than a single update event
after both tracks have be removed. This doesn't seem right.
Hence my interest in any changes to the design of stereo tracks.
David.
--James.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale Andrews

2017-06-17 15:47:27 UTC

Maybe I need to work my way onto the wxWidget team too and do for their
memory management what I did for ours.

I believe that timer driven repaint occurs only during recording and
playback. If you only play back, with an unpinned play head, then I believe
it is doing only a cheap update of the green line, by repainting a saved
rectangle over its old position, saving the pixels at the new position, and
then overpainting those.
As you can imagine, more complete repaints are needed if the playhead is
pinned, or if you record and lay down new audio.
In 2.1.3 Track preferences we had a checkbox for "Update display when
Recording/Playback head unpinned" which might help you here. But that has
been removed from 2.2.0. I recall there was some discussion whether faster
computers these days make this choice less valuable to anybody. Maybe you
want to lobby to put that preference back?

The preference is still there, now shortened to "Auto-scroll if head unpinned".

Gale

Post by James Crook
At some future time we should clean that up too.
The Windows 10 creators update has done some strange things at start up.
The splash screen now appears sooner, and so it appears before it has been
positioned. We have some strange code with the splash screen to work
around a problem with the possibility of having splash screen and error
dialog at the same time, before the app has fully started. There should
not be a need for our own event loop (which is what we have).
Is there more than one event loop? Where is the code for our own event loop?
wxEventLoopGuarantor eventLoop;
created in
bool AudacityApp::OnInit()
I (probably mistakenly) thought this created a temporary event loop.
--James.
I think our workarounds maybe should be untangled. As it is we show and
hide our splash screen rather quickly now, so it does not serve the role of
a splash screen, that reassures you that the app is starting up.
This doesn't directly answer the question of Jaws crashes, but may be
useful none the less.
very useful, thanks.
--James.
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a later
release?
James, is this a change to how stereo tracks are handled? What is the new
design going to be?
I've been looking at why Audacity is crashing when Jaws is also running on
the Windows 10 creators update.
When Jaws is running there appear to be more paint messages being sent to
Audacity, though it's unclear to me what is causing this.
For example when deleting a stereo track, a paint message can occur after
one of the tracks has been removed, and this causes audacity to crash.
Regardless of whether these extra paint message should be occurring, the
code for removing stereo tracks sends update events after each of the two
tracks is removed from the track list, rather than a single update event
after both tracks have be removed. This doesn't seem right.
Hence my interest in any changes to the design of stereo tracks.
David.
--James.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Paul Licameli

2017-06-17 16:23:01 UTC

Post by James Crook
David,
I'm relatively new to the party in terms of looking at actual screen
reader behaviour. I notice that Audacity with Narrator on leaks memory
like a sieve. Paul's cleaning up of naked news means non-narrator use does
not memory leak, so it makes these leaks more obvious. That leads me to
think that wxWidgets with any screen reader is code that is less well
exercised and tested, i.e. expect many bugs relating to screen readers in
wxWidgets. Probably we can find workarounds, staying on the parts that do
work, rather than complete fixes. But we may only be able to ameliorate
the problems rather than fix them.
I talked with Leland about screen readers at AU14 conference, and we both
were keen to provide access to Audacity algorithms at more of a command
line like level to get better accessibility. Long term this is still in my
view the best way to improve accessibility of Audacity - i.e. have an
alternative front end for the same audio engine. Have the normal GUI which
makes some assumptions about a user using a mouse, and a more command line
GUI that still has menus for access, but that is geared for automation and
keyboard use - with explicit binding of mouse wheel and x-y to controlled
values rather than implicit binding by click and drag.
IF frequent repainting is causing problems for Jaws, we can / should
ameliorate by removing redundant repaintings. That will be better for
all. Audacity has a somewhat Jekyll and Hyde attitude to repainting. It
has event based repainting and periodic painting off a timer. At some
future time we should clean that up too.
The Windows 10 creators update has done some strange things at start up.
The splash screen now appears sooner, and so it appears before it has been
positioned. We have some strange code with the splash screen to work
around a problem with the possibility of having splash screen and error
dialog at the same time, before the app has fully started. There should
not be a need for our own event loop (which is what we have). I think our
workarounds maybe should be untangled. As it is we show and hide our
splash screen rather quickly now, so it does not serve the role of a splash
screen, that reassures you that the app is starting up.
This doesn't directly answer the question of Jaws crashes, but may be
useful none the less.
--James.

Post by James Crook
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a later

Post by James Crook
release?
James, is this a change to how stereo tracks are handled? What is the new

design going to be?
I've been looking at why Audacity is crashing when Jaws is also running on
the Windows 10 creators update.

How reliably can you make these crashes happen?

I notice this comment in TrackPanel.cpp, which dates to Jan 2010 or earlier
-- I can't discover who wrote it first in the confusing git repository for
the older commits. I think it was new in version 1.3.9.

// The check for a null linked track is necessary because there's

// a possible race condition between the time the 2 linked tracks

// are added and when wxAccessible methods are called. This is

// most evident when using Jaws.

So this suggests multi-threading was involved. This makes me suspect that
the bare pointer, Track *TrackPanelAx::mFocusedTrack, is the problematic
dangling pointer here.

And this makes me suspect that a solution would involve changing our
management of Track objects everywhere to use std::shared_ptr rather that
std::unique_ptr. That might not be as hard as it sounds -- it could be
only a matter of changint some "using" type aliases.

Then, TrackPanelAx should point to its track by a shared_ptr.

This would not be sufficient: uses of that shared_ptr member of
TrackPanelAx should then themselves be guarded by a mutex. Standard
share_ptr gives you thread safety for free when threads each use different
shared_ptrs to the shared object, but not when threads contend for the same
shared_ptr. That is explained here:
http://en.cppreference.com/w/cpp/memory/shared_ptr

Is this a sufficient description, and do you understand C++11 smart
pointers enough, that you might attempt this rewrite yourself?

PRL

Post by James Crook
When Jaws is running there appear to be more paint messages being sent to

Post by James Crook
Audacity, though it's unclear to me what is causing this.
For example when deleting a stereo track, a paint message can occur after
one of the tracks has been removed, and this causes audacity to crash.
Regardless of whether these extra paint message should be occurring, the
code for removing stereo tracks sends update events after each of the two
tracks is removed from the track list, rather than a single update event
after both tracks have be removed. This doesn't seem right.
Hence my interest in any changes to the design of stereo tracks.
David.
--James.

Paul Licameli

2017-06-22 23:31:35 UTC

Post by James Crook
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a later

Post by James Crook
release?
James, is this a change to how stereo tracks are handled? What is the

new
design going to be?
I've been looking at why Audacity is crashing when Jaws is also running on
the Windows 10 creators update.

How reliably can you make these crashes happen?
I notice this comment in TrackPanel.cpp, which dates to Jan 2010 or
earlier -- I can't discover who wrote it first in the confusing git
repository for the older commits. I think it was new in version 1.3.9.
// The check for a null linked track is necessary because there's
// a possible race condition between the time the 2 linked tracks
// are added and when wxAccessible methods are called. This is
// most evident when using Jaws.
So this suggests multi-threading was involved. This makes me suspect that
the bare pointer, Track *TrackPanelAx::mFocusedTrack, is the problematic
dangling pointer here.
And this makes me suspect that a solution would involve changing our
management of Track objects everywhere to use std::shared_ptr rather that
std::unique_ptr. That might not be as hard as it sounds -- it could be
only a matter of changint some "using" type aliases.
Then, TrackPanelAx should point to its track by a shared_ptr.
This would not be sufficient: uses of that shared_ptr member of
TrackPanelAx should then themselves be guarded by a mutex. Standard
share_ptr gives you thread safety for free when threads each use different
shared_ptrs to the shared object, but not when threads contend for the same
shared_ptr. That is explained here: http://en.cppreference.com/w/
cpp/memory/shared_ptr
Is this a sufficient description, and do you understand C++11 smart
pointers enough, that you might attempt this rewrite yourself?
PRL

David, have you explored my suggestion?

PRL

Post by James Crook
When Jaws is running there appear to be more paint messages being sent to

Paul Licameli

2017-06-23 12:19:08 UTC

Post by James Crook
David,
I'm relatively new to the party in terms of looking at actual screen
reader behaviour. I notice that Audacity with Narrator on leaks memory
like a sieve. Paul's cleaning up of naked news means non-narrator use does
not memory leak, so it makes these leaks more obvious. That leads me to
think that wxWidgets with any screen reader is code that is less well
exercised and tested, i.e. expect many bugs relating to screen readers in
wxWidgets. Probably we can find workarounds, staying on the parts that do
work, rather than complete fixes. But we may only be able to ameliorate
the problems rather than fix them.
I talked with Leland about screen readers at AU14 conference, and we
both were keen to provide access to Audacity algorithms at more of a
command line like level to get better accessibility. Long term this is
still in my view the best way to improve accessibility of Audacity - i.e.
have an alternative front end for the same audio engine. Have the normal
GUI which makes some assumptions about a user using a mouse, and a more
command line GUI that still has menus for access, but that is geared for
automation and keyboard use - with explicit binding of mouse wheel and x-y
to controlled values rather than implicit binding by click and drag.
IF frequent repainting is causing problems for Jaws, we can / should
ameliorate by removing redundant repaintings. That will be better for
all. Audacity has a somewhat Jekyll and Hyde attitude to repainting. It
has event based repainting and periodic painting off a timer. At some
future time we should clean that up too.
The Windows 10 creators update has done some strange things at start
up. The splash screen now appears sooner, and so it appears before it has
been positioned. We have some strange code with the splash screen to work
around a problem with the possibility of having splash screen and error
dialog at the same time, before the app has fully started. There should
not be a need for our own event loop (which is what we have). I think our
workarounds maybe should be untangled. As it is we show and hide our
splash screen rather quickly now, so it does not serve the role of a splash
screen, that reassures you that the app is starting up.
This doesn't directly answer the question of Jaws crashes, but may be
useful none the less.
--James.

Post by James Crook
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a later

Post by James Crook
release?
James, is this a change to how stereo tracks are handled? What is the

new
design going to be?
I've been looking at why Audacity is crashing when Jaws is also running on
the Windows 10 creators update.

How reliably can you make these crashes happen?
I notice this comment in TrackPanel.cpp, which dates to Jan 2010 or
earlier -- I can't discover who wrote it first in the confusing git
repository for the older commits. I think it was new in version 1.3.9.
// The check for a null linked track is necessary because there's
// a possible race condition between the time the 2 linked tracks
// are added and when wxAccessible methods are called. This is
// most evident when using Jaws.
So this suggests multi-threading was involved. This makes me suspect
that the bare pointer, Track *TrackPanelAx::mFocusedTrack, is the
problematic dangling pointer here.
And this makes me suspect that a solution would involve changing our
management of Track objects everywhere to use std::shared_ptr rather that
std::unique_ptr. That might not be as hard as it sounds -- it could be
only a matter of changint some "using" type aliases.
Then, TrackPanelAx should point to its track by a shared_ptr.
This would not be sufficient: uses of that shared_ptr member of
TrackPanelAx should then themselves be guarded by a mutex. Standard
share_ptr gives you thread safety for free when threads each use different
shared_ptrs to the shared object, but not when threads contend for the same
shared_ptr. That is explained here: http://en.cppreference.com/w/
cpp/memory/shared_ptr
Is this a sufficient description, and do you understand C++11 smart
pointers enough, that you might attempt this rewrite yourself?
PRL

David, have you explored my suggestion?
PRL

I asked because I decided that I want to manage Track objects by shared_ptr
for other reasons too. I figured out the necessary changes myself and will
push them soon.

I am also considering the problem of possible race conditions in
TrackPanelAx used by other threads. It was hard to resist some coding
here. This is less easy to reason about.

I think there are three sources of races that might explain the crashes in
JAWS.

First, it may be that TrackPanel is being destroyed, but methods of
TrackPanelAx try to use it. But this is unlikely to expain crashes that
happen at other times than closing of windows.

Secondly, TrackPanelAx methods may iterate the list of tracks, while that
list is changing because of addition, deletion, or permutation. Perhaps
this only causes an incorrect result in TrackPanelAx queries, but perhaps
it also causes a dangling pointer to be followed.

Thirdly, TrackPanelAx stores a pointer to a track, but that track is being
destroyed, or has been. Using a shared_ptr would prevent this, but then
uses of that shared_ptr must also be serialized.

So there would be problems in defining mutexes and locking them in all
places, and then we must also make sure that this does not cause deadlocks.

PRL

Post by James Crook
When Jaws is running there appear to be more paint messages being sent to

David Bailes

2017-06-24 10:59:57 UTC

Post by James Crook
David,
I'm relatively new to the party in terms of looking at actual screen
reader behaviour. I notice that Audacity with Narrator on leaks memory
like a sieve. Paul's cleaning up of naked news means non-narrator use does
not memory leak, so it makes these leaks more obvious. That leads me to
think that wxWidgets with any screen reader is code that is less well
exercised and tested, i.e. expect many bugs relating to screen readers in
wxWidgets. Probably we can find workarounds, staying on the parts that do
work, rather than complete fixes. But we may only be able to ameliorate
the problems rather than fix them.
I talked with Leland about screen readers at AU14 conference, and we
both were keen to provide access to Audacity algorithms at more of a
command line like level to get better accessibility. Long term this is
still in my view the best way to improve accessibility of Audacity - i.e.
have an alternative front end for the same audio engine. Have the normal
GUI which makes some assumptions about a user using a mouse, and a more
command line GUI that still has menus for access, but that is geared for
automation and keyboard use - with explicit binding of mouse wheel and x-y
to controlled values rather than implicit binding by click and drag.
IF frequent repainting is causing problems for Jaws, we can / should
ameliorate by removing redundant repaintings. That will be better for
all. Audacity has a somewhat Jekyll and Hyde attitude to repainting. It
has event based repainting and periodic painting off a timer. At some
future time we should clean that up too.
The Windows 10 creators update has done some strange things at start
up. The splash screen now appears sooner, and so it appears before it has
been positioned. We have some strange code with the splash screen to work
around a problem with the possibility of having splash screen and error
dialog at the same time, before the app has fully started. There should
not be a need for our own event loop (which is what we have). I think our
workarounds maybe should be untangled. As it is we show and hide our
splash screen rather quickly now, so it does not serve the role of a splash
screen, that reassures you that the app is starting up.
This doesn't directly answer the question of Jaws crashes, but may be
useful none the less.
--James.

Post by James Crook
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a

Post by James Crook
later
release?
James, is this a change to how stereo tracks are handled? What is the

new
design going to be?
I've been looking at why Audacity is crashing when Jaws is also running on
the Windows 10 creators update.

How reliably can you make these crashes happen?
I notice this comment in TrackPanel.cpp, which dates to Jan 2010 or
earlier -- I can't discover who wrote it first in the confusing git
repository for the older commits. I think it was new in version 1.3.9.
// The check for a null linked track is necessary because there's
// a possible race condition between the time the 2 linked tracks
// are added and when wxAccessible methods are called. This is
// most evident when using Jaws.
So this suggests multi-threading was involved. This makes me suspect
that the bare pointer, Track *TrackPanelAx::mFocusedTrack, is the
problematic dangling pointer here.
And this makes me suspect that a solution would involve changing our
management of Track objects everywhere to use std::shared_ptr rather that
std::unique_ptr. That might not be as hard as it sounds -- it could be
only a matter of changint some "using" type aliases.
Then, TrackPanelAx should point to its track by a shared_ptr.
This would not be sufficient: uses of that shared_ptr member of
TrackPanelAx should then themselves be guarded by a mutex. Standard
share_ptr gives you thread safety for free when threads each use different
shared_ptrs to the shared object, but not when threads contend for the same
shared_ptr. That is explained here: http://en.cppreference.com/w/
cpp/memory/shared_ptr
Is this a sufficient description, and do you understand C++11 smart
pointers enough, that you might attempt this rewrite yourself?
PRL

David, have you explored my suggestion?
PRL

I don't think that these sources of races are the problem (with one
exception noted below).
The main problem seems to be that when Jaws is running, audacity is getting
more paint messages - no idea why.
Some of these messages can occur at times which cause the subsequent
drawing to crash audacity due to null or dangling pointers. For example:
1. When closing an audacity window, there are a couple of causes of
crashes, but these can be fixed by small modifications to the way/order
objects are deleted.
2. When a stereo track is added, there is a similar problem to the one that
Leland fixed - drawing when only one track of a stereo pair has been added
to the track list.

Post by Paul Licameli
First, it may be that TrackPanel is being destroyed, but methods of
TrackPanelAx try to use it. But this is unlikely to expain crashes that
happen at other times than closing of windows.
Secondly, TrackPanelAx methods may iterate the list of tracks, while that
list is changing because of addition, deletion, or permutation. Perhaps
this only causes an incorrect result in TrackPanelAx queries, but perhaps
it also causes a dangling pointer to be followed.
Thirdly, TrackPanelAx stores a pointer to a track, but that track is being
destroyed, or has been. Using a shared_ptr would prevent this, but then
uses of that shared_ptr must also be serialized.

There is a problem with deleting a stereo track, but the problem appears to
be that an object_focus event for the track is sent for the track, and then
the track is immediately deleted. However, the problem is that that
object_focus event should not have been sent, and the solution is simply
not to send it.

Post by Paul Licameli
So there would be problems in defining mutexes and locking them in all
places, and then we must also make sure that this does not cause deadlocks.

I don't think that adding mutexes is solving a problem, and it would just
make the code unnecessarily complicated.

David.

Post by James Crook
When Jaws is running there appear to be more paint messages being sent

Post by James Crook
to
Audacity, though it's unclear to me what is causing this.
For example when deleting a stereo track, a paint message can occur after
one of the tracks has been removed, and this causes audacity to crash.
Regardless of whether these extra paint message should be occurring, the
code for removing stereo tracks sends update events after each of the two
tracks is removed from the track list, rather than a single update event
after both tracks have be removed. This doesn't seem right.
Hence my interest in any changes to the design of stereo tracks.
David.
--James.

Paul Licameli

2017-06-24 14:01:24 UTC

Post by James Crook
David,
I'm relatively new to the party in terms of looking at actual screen
reader behaviour. I notice that Audacity with Narrator on leaks memory
like a sieve. Paul's cleaning up of naked news means non-narrator use does
not memory leak, so it makes these leaks more obvious. That leads me to
think that wxWidgets with any screen reader is code that is less well
exercised and tested, i.e. expect many bugs relating to screen readers in
wxWidgets. Probably we can find workarounds, staying on the parts that do
work, rather than complete fixes. But we may only be able to ameliorate
the problems rather than fix them.
I talked with Leland about screen readers at AU14 conference, and we
both were keen to provide access to Audacity algorithms at more of a
command line like level to get better accessibility. Long term this is
still in my view the best way to improve accessibility of Audacity - i.e.
have an alternative front end for the same audio engine. Have the normal
GUI which makes some assumptions about a user using a mouse, and a more
command line GUI that still has menus for access, but that is geared for
automation and keyboard use - with explicit binding of mouse wheel and x-y
to controlled values rather than implicit binding by click and drag.
IF frequent repainting is causing problems for Jaws, we can / should
ameliorate by removing redundant repaintings. That will be better for
all. Audacity has a somewhat Jekyll and Hyde attitude to repainting. It
has event based repainting and periodic painting off a timer. At some
future time we should clean that up too.
The Windows 10 creators update has done some strange things at start
up. The splash screen now appears sooner, and so it appears before it has
been positioned. We have some strange code with the splash screen to work
around a problem with the possibility of having splash screen and error
dialog at the same time, before the app has fully started. There should
not be a need for our own event loop (which is what we have). I think our
workarounds maybe should be untangled. As it is we show and hide our
splash screen rather quickly now, so it does not serve the role of a splash
screen, that reassures you that the app is starting up.
This doesn't directly answer the question of Jaws crashes, but may be
useful none the less.
--James.

Post by James Crook
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a

Post by James Crook
later
release?
James, is this a change to how stereo tracks are handled? What is

the new
design going to be?
I've been looking at why Audacity is crashing when Jaws is also running on
the Windows 10 creators update.

How reliably can you make these crashes happen?
I notice this comment in TrackPanel.cpp, which dates to Jan 2010 or
earlier -- I can't discover who wrote it first in the confusing git
repository for the older commits. I think it was new in version 1.3.9.
// The check for a null linked track is necessary because there's
// a possible race condition between the time the 2 linked tracks
// are added and when wxAccessible methods are called. This is
// most evident when using Jaws.
So this suggests multi-threading was involved. This makes me suspect
that the bare pointer, Track *TrackPanelAx::mFocusedTrack, is the
problematic dangling pointer here.
And this makes me suspect that a solution would involve changing our
management of Track objects everywhere to use std::shared_ptr rather that
std::unique_ptr. That might not be as hard as it sounds -- it could be
only a matter of changint some "using" type aliases.
Then, TrackPanelAx should point to its track by a shared_ptr.
This would not be sufficient: uses of that shared_ptr member of
TrackPanelAx should then themselves be guarded by a mutex. Standard
share_ptr gives you thread safety for free when threads each use different
shared_ptrs to the shared object, but not when threads contend for the same
shared_ptr. That is explained here: http://en.cppreference.com/w/
cpp/memory/shared_ptr
Is this a sufficient description, and do you understand C++11 smart
pointers enough, that you might attempt this rewrite yourself?
PRL

David, have you explored my suggestion?
PRL

I don't think that these sources of races are the problem (with one
exception noted below).

I do not yet see that you have pushed any fixes.

I am not sure what is the exception below that you mean, that really may be
a race.

You did see the old comment in TrackPanel::FindTrackRect, author unknown?
Someone had reason to suspect races, but was that incorrect?

It should be an easy experiment to set breakpoints in the methods of
TrackPanelAx that are overrides, the ones that return wxAccStatus, and then
use Jaws or another reader, and see whether indeed you are not on the main
thread when you enter those. Please try this and report what you find.

I tried this with VoiceOver on Mac, but no, it is the main thread. But if
even one screen reader executes these methods on another thread, that
suggests that synchronizations of access to the TrackList may be the right
thing to do to avoid some crashes that would be hard to reproduce, though
they may have low probability.

Post by David Bailes
The main problem seems to be that when Jaws is running, audacity is
getting more paint messages - no idea why.
Some of these messages can occur at times which cause the subsequent
1. When closing an audacity window, there are a couple of causes of
crashes, but these can be fixed by small modifications to the way/order
objects are deleted.

Which are the null and dangling pointers that cause the crash?

Even without thread synchronizations, the avoidance of this problem by use
of std::shared_ptr could be a good thing to do. I have written changes to
make TrackPanelAx::mFocusedTrack a shared_ptr.

Post by David Bailes
2. When a stereo track is added, there is a similar problem to the one
that Leland fixed - drawing when only one track of a stereo pair has been
added to the track list.

I had not mentioned Leland. What do you refer to? I find this very old
thread by Leland.
http://audacity.238276.n2.nabble.com/Found-the-original-wxProgressDialog-problem-td259250.html
I think the problem he pointed out is not necessarily a multi-thread
problem, and a fix like what he proposed was made at
commit d561e1a5fb8285a52d1b243661543ba2e4eeeda0 in the wxWidgets repository.

Post by Paul Licameli
First, it may be that TrackPanel is being destroyed, but methods of
TrackPanelAx try to use it. But this is unlikely to expain crashes that
happen at other times than closing of windows.
Secondly, TrackPanelAx methods may iterate the list of tracks, while that
list is changing because of addition, deletion, or permutation. Perhaps
this only causes an incorrect result in TrackPanelAx queries, but perhaps
it also causes a dangling pointer to be followed.
Thirdly, TrackPanelAx stores a pointer to a track, but that track is
being destroyed, or has been. Using a shared_ptr would prevent this, but
then uses of that shared_ptr must also be serialized.

There is a problem with deleting a stereo track, but the problem appears
to be that an object_focus event for the track is sent for the track, and
then the track is immediately deleted. However, the problem is that that
object_focus event should not have been sent, and the solution is simply
not to send it.

What is "an object_focus event" ?

I see calls to NotifyEvent in TrackPanelAx. Do you mean that you make
changes to issue fewer of those?

Can you determine in the debugger whether calls back to the wxAccessible
overrides happen during the calls to NotifyEvent on the same thread, or
only after? Or again, perhaps on a different thread.

Post by Paul Licameli
So there would be problems in defining mutexes and locking them in all
places, and then we must also make sure that this does not cause deadlocks.

I don't think that adding mutexes is solving a problem, and it would just
make the code unnecessarily complicated.

I am not persuaded that mutexes have no value here, and I think the
complications would be tolerable. I admit you have not given me evidence
that races are possible. But you may find proof that multiple threads
really are involved.

PRL

Post by David Bailes
David.

Post by James Crook
When Jaws is running there appear to be more paint messages being sent

Post by James Crook
to
Audacity, though it's unclear to me what is causing this.
For example when deleting a stereo track, a paint message can occur after
one of the tracks has been removed, and this causes audacity to
crash.
Regardless of whether these extra paint message should be occurring, the
code for removing stereo tracks sends update events after each of the two
tracks is removed from the track list, rather than a single update event
after both tracks have be removed. This doesn't seem right.
Hence my interest in any changes to the design of stereo tracks.
David.
--James.

Henric Jungheim

2017-06-24 14:40:12 UTC

Post by Paul Licameli
I am not persuaded that mutexes have no value here, and I think the
complications would be tolerable. I admit you have not given me
evidence that races are possible. But you may find proof that
multiple threads really are involved.

Speaking only for Win32 here, but I think the general idea
applies to Mac and Linux as well.

If a mutex helps then there are more serious problems.
Messages must be received and handled on the thread that
created the window. One may run into re-entrancy issues
where something causes the message pump to run while still
handling a message, but a mutex is likely to cause more
trouble than it solves. E.g., the effect trying to lock a
std::mutex while already holding it is undefined.

Snooping on the window is going to result in more messages
in the message pump. The effect may also be to alter the
order of some messages. I haven't used the tool in ages
(since the mid-90s? Yikes...), but this has proved helpful
in the past when needing to monitor a message pump:
https://docs.microsoft.com/en-us/visualstudio/debugger/introducing-spy-increment
In particular, for messages:
https://docs.microsoft.com/en-us/visualstudio/debugger/messages-view

Post by Paul Licameli
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Paul Licameli

2017-06-24 15:09:30 UTC

Post by Henric Jungheim

The locking could be conditionally compiled. wxMutex on Windows, where we
would really need it, should not have reentrancy problems.

But the proper thing to do is examine the scope of each locking of the
mutex and be sure that there is no possibility of messages dispatched
during it which cause callback to the same or other routines that use the
lock.

I think the needed locks would all have such narrow scopes.

The question here is not what thread dispatches window events, but rather
which thread or threads may execute the methods of a wxAccessible. We
don't know the answer yet.

PRL

Post by Henric Jungheim
Snooping on the window is going to result in more messages
in the message pump. The effect may also be to alter the
order of some messages. I haven't used the tool in ages
(since the mid-90s? Yikes...), but this has proved helpful
https://docs.microsoft.com/en-us/visualstudio/debugger/
introducing-spy-increment
https://docs.microsoft.com/en-us/visualstudio/debugger/messages-view

Post by Paul Licameli
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

David Engebretson Jr

2017-06-24 21:38:15 UTC

I was pushed Windows 10 CE (Wince?) and Iâm now experiencing the crashes using Audacity 2.1.3 and JAWS 18 with the latest scriptset.

Is there something I can do to help narrow the ishâs down?

Side note; how do you blind folk follow these threads efficiently when the text is interspursed? How do you know which are the most recent comments? Itâs not obvious to me whoâs comments are whoâs. Iâm using Windows Live Mail... html...

Best,
David

David Bailes

2017-06-26 14:08:57 UTC

Hi David,
what would be very helpful would be to try and find all the situations in
which Audacity crashes when using Jaws and the creators update. I'm aware
of some, for example when opening a stereo file, but there may be some
which I'm not aware of, and need fixing.

thanks,
David.

On Sat, Jun 24, 2017 at 10:38 PM, David Engebretson Jr <

*I was pushed Windows 10 CE (Wince?) and Iâm now experiencing the crashes
using Audacity 2.1.3 and JAWS 18 with the latest scriptset.*
*Is there something I can do to help narrow the ishâs down?*
*Side note; how do you blind folk follow these threads efficiently when
the text is interspursed? How do you know which are the most recent
comments? Itâs not obvious to me whoâs comments are whoâs. Iâm using
Windows Live Mail... html...*
*Best,*
*David*
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

David Engebretson Jr

2017-06-26 21:29:39 UTC

The simplest way for me to make Audacity crash is:
1. Open Audacity.
2. Press alt+f4 to close Audacity.

Result; Windows says its looking for a solution to the problem, none is found so I click the close button. Rinse and repeat.

Are there any debug builds available that might be able to keep track of breakpoints? I donât have a build environment setup, but would be happy to run a debug build and try the same thing. Any builds with error reporting built in so relevant information could be sent to developers?

Best,
David

From: David Bailes
Sent: Monday, June 26, 2017 7:08 AM
To: Audacity Development
Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())

Hi David,
what would be very helpful would be to try and find all the situations in which Audacity crashes when using Jaws and the creators update. I'm aware of some, for example when opening a stereo file, but there may be some which I'm not aware of, and need fixing.

thanks,
David.

On Sat, Jun 24, 2017 at 10:38 PM, David Engebretson Jr <***@comcast.net> wrote:

I was pushed Windows 10 CE (Wince?) and Iâm now experiencing the crashes using Audacity 2.1.3 and JAWS 18 with the latest scriptset.

Is there something I can do to help narrow the ishâs down?

Side note; how do you blind folk follow these threads efficiently when the text is interspursed? How do you know which are the most recent comments? Itâs not obvious to me whoâs comments are whoâs. Iâm using Windows Live Mail... html...

Best,
David

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
audacity-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/audacity-devel

--------------------------------------------------------------------------------

David Bailes

2017-06-27 13:30:38 UTC

Hi David,
thanks, we are already have a fix for Audacity crashing on closing.
Unfortunately, to help with any debugging, you'd need a build environment.
If you don't want to do that, then it would be still very useful if you
could help to make sure that we know all the circumstances in which
Audacity crashes when Jaws is running.

David.

On Mon, Jun 26, 2017 at 10:29 PM, David Engebretson Jr <

Post by David Engebretson Jr
1. Open Audacity.
2. Press alt+f4 to close Audacity.
Result; Windows says its looking for a solution to the problem, none is
found so I click the close button. Rinse and repeat.
Are there any debug builds available that might be able to keep track of
breakpoints? I donât have a build environment setup, but would be happy to
run a debug build and try the same thing. Any builds with error reporting
built in so relevant information could be sent to developers?
Best,
David
*From:* David Bailes
*Sent:* Monday, June 26, 2017 7:08 AM
*To:* Audacity Development
*Subject:* Re: [Audacity-devel] Jaws Crashes (was: GetLinked())
Hi David,
what would be very helpful would be to try and find all the situations in
which Audacity crashes when using Jaws and the creators update. I'm aware
of some, for example when opening a stereo file, but there may be some
which I'm not aware of, and need fixing.
thanks,
David.
On Sat, Jun 24, 2017 at 10:38 PM, David Engebretson Jr <

------------------------------
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
------------------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

David Engebretson Jr

2017-06-27 13:44:35 UTC

Do you have a list of the âknown issuesâ? You said earlier that you crash when switching from stereo to mono?

How about nightly builds? Where would I find the builds that have the opening/closing screen fix?

Best,
David

From: David Bailes
Sent: Tuesday, June 27, 2017 6:30 AM
To: Audacity Development
Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())

Hi David,
thanks, we are already have a fix for Audacity crashing on closing. Unfortunately, to help with any debugging, you'd need a build environment. If you don't want to do that, then it would be still very useful if you could help to make sure that we know all the circumstances in which Audacity crashes when Jaws is running.

David.

On Mon, Jun 26, 2017 at 10:29 PM, David Engebretson Jr <***@comcast.net> wrote:

The simplest way for me to make Audacity crash is:
1. Open Audacity.
2. Press alt+f4 to close Audacity.

Result; Windows says its looking for a solution to the problem, none is found so I click the close button. Rinse and repeat.

Are there any debug builds available that might be able to keep track of breakpoints? I donât have a build environment setup, but would be happy to run a debug build and try the same thing. Any builds with error reporting built in so relevant information could be sent to developers?

Best,
David

From: David Bailes
Sent: Monday, June 26, 2017 7:08 AM
To: Audacity Development
Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())

Hi David,
what would be very helpful would be to try and find all the situations in which Audacity crashes when using Jaws and the creators update. I'm aware of some, for example when opening a stereo file, but there may be some which I'm not aware of, and need fixing.

thanks,
David.

On Sat, Jun 24, 2017 at 10:38 PM, David Engebretson Jr <***@comcast.net> wrote:

I was pushed Windows 10 CE (Wince?) and Iâm now experiencing the crashes using Audacity 2.1.3 and JAWS 18 with the latest scriptset.

Is there something I can do to help narrow the ishâs down?

Side note; how do you blind folk follow these threads efficiently when the text is interspursed? How do you know which are the most recent comments? Itâs not obvious to me whoâs comments are whoâs. Iâm using Windows Live Mail... html...

Best,
David

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
audacity-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
audacity-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
audacity-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/audacity-devel

--------------------------------------------------------------------------------

David Bailes

2017-06-28 11:04:43 UTC

Hi David,
as you may well already be aware, nightly builds are available on this page:
http://gaclrecords.org.uk/win-nightly/

Currently, the last build was on 26 June. When the next build is posted
there it will include fixes both for the closing crash, and opening stereo
files crash. At the moment I haven't been able to crash Audacity using the
current build, but you might like to have a good try.

David.

On Tue, Jun 27, 2017 at 2:44 PM, David Engebretson Jr <

Post by David Engebretson Jr
Do you have a list of the âknown issuesâ? You said earlier that you crash
when switching from stereo to mono?
How about nightly builds? Where would I find the builds that have the
opening/closing screen fix?
Best,
David
*From:* David Bailes
*Sent:* Tuesday, June 27, 2017 6:30 AM
*To:* Audacity Development
*Subject:* Re: [Audacity-devel] Jaws Crashes (was: GetLinked())
Hi David,
thanks, we are already have a fix for Audacity crashing on closing.
Unfortunately, to help with any debugging, you'd need a build environment.
If you don't want to do that, then it would be still very useful if you
could help to make sure that we know all the circumstances in which
Audacity crashes when Jaws is running.
David.
On Mon, Jun 26, 2017 at 10:29 PM, David Engebretson Jr <

*I was pushed Windows 10 CE (Wince?) and Iâm now experiencing the
crashes using Audacity 2.1.3 and JAWS 18 with the latest scriptset.*
*Is there something I can do to help narrow the ishâs down?*
*Side note; how do you blind folk follow these threads efficiently when
the text is interspursed? How do you know which are the most recent
comments? Itâs not obvious to me whoâs comments are whoâs. Iâm using
Windows Live Mail... html...*
*Best,*
*David*
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Henric Jungheim

2017-06-28 14:50:54 UTC

The current build here is for 27f706bb (exactly; none of my
hacks are included):
https://ci.appveyor.com/project/henricj/audacity-n5suy/build/artifacts

I can open and Alt-F4 it while JAWS is running without it
blowing up.

Note that it doesn't include the help or locale.

Should this be set up for the official Audacity GitHub repo?
The changes to get it working are only to appveyor.yml. It
works automatically, but only after I sync my fork.

The build with my hacks is running now (so far only the
x64/none/VS2017 build is done).
https://ci.appveyor.com/project/henricj/audacity/build/1.0.74

Click the job, then "ARTIFACTS" (at the far right) to find
the .zip. It includes the locale, but in the wrong folder
(move it, and it should work).

Post by David Bailes
Hi David,
[1]http://gaclrecords.org.uk/win-nightly/
Currently, the last build was on 26 June. When the next build is posted
there it will include fixes both for the closing crash, and opening
stereo files crash. At the moment I haven't been able to crash Audacity
using the current build, but you might like to have a good try.
David.
On Tue, Jun 27, 2017 at 2:44 PM, David Engebretson Jr
Do you have a list of the âknown issuesâ?Â You said earlier that you
crash when switching from stereo to mono?
Â
How about nightly builds?Â Where would I find the builds that have the
opening/closing screen fix?
Â
Best,
David
Â
Â
Â
From: David Bailes
Sent: Tuesday, June 27, 2017 6:30 AM
To: Audacity Development
Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())
Â
Hi David,
thanks, we are already have a fix for Audacity crashing on closing.
Unfortunately, to help with any debugging, you'd need a build
environment. If you don't want to do that, then it would be still very
useful if you could help to make sure that we know all the
circumstances in which Audacity crashes when Jaws is running.
Â
David.
Â
On Mon, Jun 26, 2017 at 10:29 PM, David Engebretson Jr
1. Open Audacity.
2. Press alt+f4 to close Audacity.
Â
Result; Windows says its looking for a solution to the problem, none is
found so I click the close button.Â Rinse and repeat.
Â
Are there any debug builds available that might be able to keep track
of breakpoints?Â I donât have a build environment setup, but would be
happy to run a debug build and try the same thing.Â Any builds with
error reporting built in so relevant information could be sent to
developers?
Â
Best,
David
Â
Â
From: David Bailes
Sent: Monday, June 26, 2017 7:08 AM
To: Audacity Development
Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())
Â
Hi David,
what would be very helpful would be to try and find all the situations
in which Audacity crashes when using Jaws and the creators update. I'm
aware of some, for example when opening a stereo file, but there may be
some which I'm not aware of, and need fixing.
Â
thanks,
David.
Â
On Sat, Jun 24, 2017 at 10:38 PM, David Engebretson Jr
I was pushed Windows 10 CE (Wince?) and Iâm now experiencing the
crashes using Audacity 2.1.3 and JAWS 18 with the latest scriptset.
Â
Is there something I can do to help narrow the ishâs down?
Â
Side note; how do you blind folk follow these threads efficiently when
the text is interspursed?Â How do you know which are the most recent
comments?Â Itâs not obvious to me whoâs comments are whoâs. Iâm using
Windows Live Mail... html...
Â
Best,
David
Â
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! [3]http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[4]https://lists.sourceforge.net/lists/listinfo/audacity-devel
Â
__________________________________________________________________
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! [5]http://sdm.link/slashdot
__________________________________________________________________
_______________________________________________
audacity-devel mailing list
[6]https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! [7]http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[8]https://lists.sourceforge.net/lists/listinfo/audacity-devel
Â
__________________________________________________________________
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! [9]http://sdm.link/slashdot
__________________________________________________________________
_______________________________________________
audacity-devel mailing list
[11]https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! [12]http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[14]https://lists.sourceforge.net/lists/listinfo/audacity-devel
References
1. http://gaclrecords.org.uk/win-nightly/
3. http://sdm.link/slashdot
4. https://lists.sourceforge.net/lists/listinfo/audacity-devel
5. http://sdm.link/slashdot
6. https://lists.sourceforge.net/lists/listinfo/audacity-devel
7. http://sdm.link/slashdot
8. https://lists.sourceforge.net/lists/listinfo/audacity-devel
9. http://sdm.link/slashdot
11. https://lists.sourceforge.net/lists/listinfo/audacity-devel
12. http://sdm.link/slashdot
14. https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

David Engebretson Jr

2017-06-28 16:20:12 UTC

Good morning. With this build (2.2.0 alpha 28) I don't get the crash.
Instead I am told that Audacity is cleaning up temporary files. Very nice!

Interestingly 'r' appends instead of adding a second track. Not so great
for laying down seperate tracks in music production but I could see how this
as a default could be helpful for those making voice recordings.

Also, JAWS no longer reports track length or position with the scriptset by
Gary Campbell. Maybe he should be involved?

Regarding JAWS sending paint commands; I wonder if it is part of the virtual
viewer. They would have to send paint commands to show the virtual viewer,
right? Are there other methods of creating windows that avoid onPaint?

-----Original Message-----
From: Henric Jungheim
Sent: Wednesday, June 28, 2017 7:50 AM
To: audacity-***@lists.sourceforge.net
Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())

The current build here is for 27f706bb (exactly; none of my
hacks are included):
https://ci.appveyor.com/project/henricj/audacity-n5suy/build/artifacts

I can open and Alt-F4 it while JAWS is running without it
blowing up.

Note that it doesn't include the help or locale.

Should this be set up for the official Audacity GitHub repo?
The changes to get it working are only to appveyor.yml. It
works automatically, but only after I sync my fork.

The build with my hacks is running now (so far only the
x64/none/VS2017 build is done).
https://ci.appveyor.com/project/henricj/audacity/build/1.0.74

Click the job, then "ARTIFACTS" (at the far right) to find
the .zip. It includes the locale, but in the wrong folder
(move it, and it should work).

James Crook

2017-06-28 17:01:19 UTC

Post by David Engebretson Jr
Interestingly 'r' appends instead of adding a second track. Not so
great for laying down seperate tracks in music production but I could
see how this as a default could be helpful for those making voice
recordings.

Shift+R will record to a new track.
--James.

David Bailes

2017-06-30 08:02:24 UTC

Hi David,
I'll let Gary know about the changes to the selection bar.
Jaws virtual viewer isn't involved. I think that it's a Jaws/Windows bug
that the extra paint messages are being sent to Audacity.

David.

On Wed, Jun 28, 2017 at 5:20 PM, David Engebretson Jr <

Post by David Engebretson Jr
Good morning. With this build (2.2.0 alpha 28) I don't get the crash.
Instead I am told that Audacity is cleaning up temporary files. Very nice!
Interestingly 'r' appends instead of adding a second track. Not so great
for laying down seperate tracks in music production but I could see how
this as a default could be helpful for those making voice recordings.
Also, JAWS no longer reports track length or position with the scriptset
by Gary Campbell. Maybe he should be involved?
Regarding JAWS sending paint commands; I wonder if it is part of the
virtual viewer. They would have to send paint commands to show the virtual
viewer, right? Are there other methods of creating windows that avoid
onPaint?
-----Original Message----- From: Henric Jungheim
Sent: Wednesday, June 28, 2017 7:50 AM
Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())
The current build here is for 27f706bb (exactly; none of my
https://ci.appveyor.com/project/henricj/audacity-n5suy/build/artifacts
I can open and Alt-F4 it while JAWS is running without it
blowing up.
Note that it doesn't include the help or locale.
Should this be set up for the official Audacity GitHub repo?
The changes to get it working are only to appveyor.yml. It
works automatically, but only after I sync my fork.
The build with my hacks is running now (so far only the
x64/none/VS2017 build is done).
https://ci.appveyor.com/project/henricj/audacity/build/1.0.74
Click the job, then "ARTIFACTS" (at the far right) to find
the .zip. It includes the locale, but in the wrong folder
(move it, and it should work).

Post by David Bailes
Hi David,
[1]http://gaclrecords.org.uk/win-nightly/
Currently, the last build was on 26 June. When the next build is posted
there it will include fixes both for the closing crash, and opening
stereo files crash. At the moment I haven't been able to crash Audacity
using the current build, but you might like to have a good try.
David.
On Tue, Jun 27, 2017 at 2:44 PM, David Engebretson Jr
Do you have a list of the Ã¢known issuesÃ¢?Ã You said earlier that you
crash when switching from stereo to mono?
Ã
How about nightly builds?Ã Where would I find the builds that have the
opening/closing screen fix?
Ã
Best,
David
Ã
Ã
Ã
From: David Bailes
Sent: Tuesday, June 27, 2017 6:30 AM
To: Audacity Development
Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())
Ã
Hi David,
thanks, we are already have a fix for Audacity crashing on closing.
Unfortunately, to help with any debugging, you'd need a build
environment. If you don't want to do that, then it would be still very
useful if you could help to make sure that we know all the
circumstances in which Audacity crashes when Jaws is running.
Ã
David.
Ã
On Mon, Jun 26, 2017 at 10:29 PM, David Engebretson Jr
1. Open Audacity.
2. Press alt+f4 to close Audacity.
Ã
Result; Windows says its looking for a solution to the problem, none is
found so I click the close button.Ã Rinse and repeat.
Ã
Are there any debug builds available that might be able to keep track
of breakpoints?Ã I donÃ¢t have a build environment setup, but would be
happy to run a debug build and try the same thing.Ã Any builds with
error reporting built in so relevant information could be sent to
developers?
Ã
Best,
David
Ã
Ã
From: David Bailes
Sent: Monday, June 26, 2017 7:08 AM
To: Audacity Development
Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())
Ã
Hi David,
what would be very helpful would be to try and find all the situations
in which Audacity crashes when using Jaws and the creators update. I'm
aware of some, for example when opening a stereo file, but there may be
some which I'm not aware of, and need fixing.
Ã
thanks,
David.
Ã
On Sat, Jun 24, 2017 at 10:38 PM, David Engebretson Jr
I was pushed Windows 10 CE (Wince?) and IÃ¢m now experiencing the
crashes using Audacity 2.1.3 and JAWS 18 with the latest scriptset.
Ã
Is there something I can do to help narrow the ishÃ¢s down?
Ã
Side note; how do you blind folk follow these threads efficiently when
the text is interspursed?Ã How do you know which are the most recent
comments?Ã ItÃ¢s not obvious to me whoÃ¢s comments are whoÃ¢s. IÃ¢m using
Windows Live Mail... html...
Ã
Best,
David
Ã
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! [3]http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[4]https://lists.sourceforge.net/lists/listinfo/audacity-devel
Ã
__________________________________________________________________
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! [5]http://sdm.link/slashdot
__________________________________________________________________
_______________________________________________
audacity-devel mailing list
[6]https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! [7]http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[8]https://lists.sourceforge.net/lists/listinfo/audacity-devel
Ã
__________________________________________________________________
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! [9]http://sdm.link/slashdot
__________________________________________________________________
_______________________________________________
audacity-devel mailing list
[11]https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! [12]http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[14]https://lists.sourceforge.net/lists/listinfo/audacity-devel
References
1. http://gaclrecords.org.uk/win-nightly/
3. http://sdm.link/slashdot
4. https://lists.sourceforge.net/lists/listinfo/audacity-devel
5. http://sdm.link/slashdot
6. https://lists.sourceforge.net/lists/listinfo/audacity-devel
7. http://sdm.link/slashdot
8. https://lists.sourceforge.net/lists/listinfo/audacity-devel
9. http://sdm.link/slashdot
11. https://lists.sourceforge.net/lists/listinfo/audacity-devel
12. http://sdm.link/slashdot
14. https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------

Post by David Bailes
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________

Post by David Bailes
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

David Bailes

2017-06-26 14:04:08 UTC

On Sat, Jun 17, 2017 at 12:23 PM, Paul Licameli <

Post by James Crook
David,
I'm relatively new to the party in terms of looking at actual screen
reader behaviour. I notice that Audacity with Narrator on leaks memory
like a sieve. Paul's cleaning up of naked news means non-narrator use does
not memory leak, so it makes these leaks more obvious. That leads me to
think that wxWidgets with any screen reader is code that is less well
exercised and tested, i.e. expect many bugs relating to screen readers in
wxWidgets. Probably we can find workarounds, staying on the parts that do
work, rather than complete fixes. But we may only be able to ameliorate
the problems rather than fix them.
I talked with Leland about screen readers at AU14 conference, and we
both were keen to provide access to Audacity algorithms at more of a
command line like level to get better accessibility. Long term this is
still in my view the best way to improve accessibility of Audacity - i.e.
have an alternative front end for the same audio engine. Have the normal
GUI which makes some assumptions about a user using a mouse, and a more
command line GUI that still has menus for access, but that is geared for
automation and keyboard use - with explicit binding of mouse wheel and x-y
to controlled values rather than implicit binding by click and drag.
IF frequent repainting is causing problems for Jaws, we can / should
ameliorate by removing redundant repaintings. That will be better for
all. Audacity has a somewhat Jekyll and Hyde attitude to repainting. It
has event based repainting and periodic painting off a timer. At some
future time we should clean that up too.
The Windows 10 creators update has done some strange things at start
up. The splash screen now appears sooner, and so it appears before it has
been positioned. We have some strange code with the splash screen to work
around a problem with the possibility of having splash screen and error
dialog at the same time, before the app has fully started. There should
not be a need for our own event loop (which is what we have). I think our
workarounds maybe should be untangled. As it is we show and hide our
splash screen rather quickly now, so it does not serve the role of a splash
screen, that reassures you that the app is starting up.
This doesn't directly answer the question of Jaws crashes, but may be
useful none the less.
--James.

Post by James Crook
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a

Post by James Crook
later
release?
James, is this a change to how stereo tracks are handled? What is

the new
design going to be?
I've been looking at why Audacity is crashing when Jaws is also running on
the Windows 10 creators update.

How reliably can you make these crashes happen?
I notice this comment in TrackPanel.cpp, which dates to Jan 2010 or
earlier -- I can't discover who wrote it first in the confusing git
repository for the older commits. I think it was new in version 1.3.9.
// The check for a null linked track is necessary because there's
// a possible race condition between the time the 2 linked tracks
// are added and when wxAccessible methods are called. This is
// most evident when using Jaws.
So this suggests multi-threading was involved. This makes me suspect
that the bare pointer, Track *TrackPanelAx::mFocusedTrack, is the
problematic dangling pointer here.
And this makes me suspect that a solution would involve changing our
management of Track objects everywhere to use std::shared_ptr rather that
std::unique_ptr. That might not be as hard as it sounds -- it could be
only a matter of changint some "using" type aliases.
Then, TrackPanelAx should point to its track by a shared_ptr.
This would not be sufficient: uses of that shared_ptr member of
TrackPanelAx should then themselves be guarded by a mutex. Standard
share_ptr gives you thread safety for free when threads each use different
shared_ptrs to the shared object, but not when threads contend for the same
shared_ptr. That is explained here: http://en.cppreference.com/w/
cpp/memory/shared_ptr
Is this a sufficient description, and do you understand C++11 smart
pointers enough, that you might attempt this rewrite yourself?
PRL

David, have you explored my suggestion?
PRL

I don't think that these sources of races are the problem (with one
exception noted below).

I do not yet see that you have pushed any fixes.

That's because I'm still working on this.

Post by Paul Licameli
I am not sure what is the exception below that you mean, that really may
be a race.
You did see the old comment in TrackPanel::FindTrackRect, author unknown?
Someone had reason to suspect races, but was that incorrect?

I presume Leland thought that there was uncertainty in the timing of when
the screen reader sends messages to Audacity requesting information such as
location after it has received an object focus event from Audacity.

Post by Paul Licameli
It should be an easy experiment to set breakpoints in the methods of
TrackPanelAx that are overrides, the ones that return wxAccStatus, and then
use Jaws or another reader, and see whether indeed you are not on the main
thread when you enter those. Please try this and report what you find.

I checked that TrackPanelAx::SetFocus and TrackPanelAx::GetLocation were in
the same thread.

Post by Paul Licameli
I tried this with VoiceOver on Mac, but no, it is the main thread. But if
even one screen reader executes these methods on another thread, that
suggests that synchronizations of access to the TrackList may be the right
thing to do to avoid some crashes that would be hard to reproduce, though
they may have low probability.

Which are the null and dangling pointers that cause the crash?

There are a couple of problems in the destructor of a project when Jaws is
running:
1. The ruler is painted after the trackpanel has been destroyed, but the
ruler calls trackpanel on drawing. So a fix is to destroy mRuler before the
trackpanel.
2. Tooldocks are painted after the toolbars have gone. So a fix is to clear
the configuration of the tooldocks in the destructor of the toolmanager.

Post by Paul Licameli
Even without thread synchronizations, the avoidance of this problem by use
of std::shared_ptr could be a good thing to do. I have written changes to
make TrackPanelAx::mFocusedTrack a shared_ptr.

Post by David Bailes
2. When a stereo track is added, there is a similar problem to the one
that Leland fixed - drawing when only one track of a stereo pair has been
added to the track list.

I had not mentioned Leland. What do you refer to?

It was Leland who fixed TrackPanel::FindTrackRect.

Post by Paul Licameli
I find this very old thread by Leland. http://audacity.238276.n2.
nabble.com/Found-the-original-wxProgressDialog-problem-td259250.html I
think the problem he pointed out is not necessarily a multi-thread problem,
and a fix like what he proposed was made at commit
d561e1a5fb8285a52d1b243661543ba2e4eeeda0 in the wxWidgets repository.

I don't think this is connected with the current problems.

Post by Paul Licameli
First, it may be that TrackPanel is being destroyed, but methods of
TrackPanelAx try to use it. But this is unlikely to expain crashes that
happen at other times than closing of windows.
Secondly, TrackPanelAx methods may iterate the list of tracks, while
that list is changing because of addition, deletion, or permutation.
Perhaps this only causes an incorrect result in TrackPanelAx queries, but
perhaps it also causes a dangling pointer to be followed.
Thirdly, TrackPanelAx stores a pointer to a track, but that track is
being destroyed, or has been. Using a shared_ptr would prevent this, but
then uses of that shared_ptr must also be serialized.

There is a problem with deleting a stereo track, but the problem appears
to be that an object_focus event for the track is sent for the track, and
then the track is immediately deleted. However, the problem is that that
object_focus event should not have been sent, and the solution is simply
not to send it.

What is "an object_focus event" ?

I was just using it as an abbreviation for wxACC_EVENT_OBJECT_FOCUS.

Post by Paul Licameli
I see calls to NotifyEvent in TrackPanelAx. Do you mean that you make
changes to issue fewer of those?

Making sure that events are sent when they shouldn't be.

Post by Paul Licameli
Can you determine in the debugger whether calls back to the wxAccessible
overrides happen during the calls to NotifyEvent on the same thread, or
only after? Or again, perhaps on a different thread.

As stated above, it's the same thread.

David.

Post by Paul Licameli
So there would be problems in defining mutexes and locking them in all
places, and then we must also make sure that this does not cause deadlocks.

I don't think that adding mutexes is solving a problem, and it would just
make the code unnecessarily complicated.

Post by David Bailes
David.

Post by James Crook
When Jaws is running there appear to be more paint messages being

Post by James Crook
sent to
Audacity, though it's unclear to me what is causing this.
For example when deleting a stereo track, a paint message can occur after
one of the tracks has been removed, and this causes audacity to
crash.
Regardless of whether these extra paint message should be occurring, the
code for removing stereo tracks sends update events after each of the two
tracks is removed from the track list, rather than a single update event
after both tracks have be removed. This doesn't seem right.
Hence my interest in any changes to the design of stereo tracks.
David.
--James.

David Bailes

2017-06-26 14:05:29 UTC

On Sat, Jun 17, 2017 at 12:23 PM, Paul Licameli <

Post by James Crook
David,
I'm relatively new to the party in terms of looking at actual screen
reader behaviour. I notice that Audacity with Narrator on leaks memory
like a sieve. Paul's cleaning up of naked news means non-narrator use does
not memory leak, so it makes these leaks more obvious. That leads me to
think that wxWidgets with any screen reader is code that is less well
exercised and tested, i.e. expect many bugs relating to screen readers in
wxWidgets. Probably we can find workarounds, staying on the parts that do
work, rather than complete fixes. But we may only be able to ameliorate
the problems rather than fix them.
I talked with Leland about screen readers at AU14 conference, and we
both were keen to provide access to Audacity algorithms at more of a
command line like level to get better accessibility. Long term this is
still in my view the best way to improve accessibility of Audacity - i.e.
have an alternative front end for the same audio engine. Have the normal
GUI which makes some assumptions about a user using a mouse, and a more
command line GUI that still has menus for access, but that is geared for
automation and keyboard use - with explicit binding of mouse wheel and x-y
to controlled values rather than implicit binding by click and drag.
IF frequent repainting is causing problems for Jaws, we can / should
ameliorate by removing redundant repaintings. That will be better for
all. Audacity has a somewhat Jekyll and Hyde attitude to repainting. It
has event based repainting and periodic painting off a timer. At some
future time we should clean that up too.
The Windows 10 creators update has done some strange things at start
up. The splash screen now appears sooner, and so it appears before it has
been positioned. We have some strange code with the splash screen to work
around a problem with the possibility of having splash screen and error
dialog at the same time, before the app has fully started. There should
not be a need for our own event loop (which is what we have). I think our
workarounds maybe should be untangled. As it is we show and hide our
splash screen rather quickly now, so it does not serve the role of a splash
screen, that reassures you that the app is starting up.
This doesn't directly answer the question of Jaws crashes, but may
be useful none the less.
--James.

Post by James Crook
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a

Post by James Crook
later
release?
James, is this a change to how stereo tracks are handled? What is

the new
design going to be?
I've been looking at why Audacity is crashing when Jaws is also running on
the Windows 10 creators update.

How reliably can you make these crashes happen?
I notice this comment in TrackPanel.cpp, which dates to Jan 2010 or
earlier -- I can't discover who wrote it first in the confusing git
repository for the older commits. I think it was new in version 1.3.9.
// The check for a null linked track is necessary because there's
// a possible race condition between the time the 2 linked tracks
// are added and when wxAccessible methods are called. This is
// most evident when using Jaws.
So this suggests multi-threading was involved. This makes me suspect
that the bare pointer, Track *TrackPanelAx::mFocusedTrack, is the
problematic dangling pointer here.
And this makes me suspect that a solution would involve changing our
management of Track objects everywhere to use std::shared_ptr rather that
std::unique_ptr. That might not be as hard as it sounds -- it could be
only a matter of changint some "using" type aliases.
Then, TrackPanelAx should point to its track by a shared_ptr.
This would not be sufficient: uses of that shared_ptr member of
TrackPanelAx should then themselves be guarded by a mutex. Standard
share_ptr gives you thread safety for free when threads each use different
shared_ptrs to the shared object, but not when threads contend for the same
shared_ptr. That is explained here: http://en.cppreference.com/w/
cpp/memory/shared_ptr
Is this a sufficient description, and do you understand C++11 smart
pointers enough, that you might attempt this rewrite yourself?
PRL

David, have you explored my suggestion?
PRL

I don't think that these sources of races are the problem (with one
exception noted below).

I do not yet see that you have pushed any fixes.

That's because I'm still working on this.

Post by Paul Licameli
I am not sure what is the exception below that you mean, that really may
be a race.
You did see the old comment in TrackPanel::FindTrackRect, author
unknown? Someone had reason to suspect races, but was that incorrect?

I checked that TrackPanelAx::SetFocus and TrackPanelAx::GetLocation were
in the same thread.

Post by Paul Licameli
I tried this with VoiceOver on Mac, but no, it is the main thread. But
if even one screen reader executes these methods on another thread, that
suggests that synchronizations of access to the TrackList may be the right
thing to do to avoid some crashes that would be hard to reproduce, though
they may have low probability.

Which are the null and dangling pointers that cause the crash?

There are a couple of problems in the destructor of a project when Jaws is
1. The ruler is painted after the trackpanel has been destroyed, but the
ruler calls trackpanel on drawing. So a fix is to destroy mRuler before the
trackpanel.
2. Tooldocks are painted after the toolbars have gone. So a fix is to
clear the configuration of the tooldocks in the destructor of the
toolmanager.

Post by Paul Licameli
Even without thread synchronizations, the avoidance of this problem by
use of std::shared_ptr could be a good thing to do. I have written changes
to make TrackPanelAx::mFocusedTrack a shared_ptr.

Post by David Bailes
2. When a stereo track is added, there is a similar problem to the one
that Leland fixed - drawing when only one track of a stereo pair has been
added to the track list.

I had not mentioned Leland. What do you refer to?

It was Leland who fixed TrackPanel::FindTrackRect.

Post by Paul Licameli
I find this very old thread by Leland. http://audacity.238276.n2.nab
ble.com/Found-the-original-wxProgressDialog-problem-td259250.html I
think the problem he pointed out is not necessarily a multi-thread problem,
and a fix like what he proposed was made at commit d561e1a5fb8285a52d1b243661543ba2e4eeeda0
in the wxWidgets repository.

I don't think this is connected with the current problems.

Post by Paul Licameli
First, it may be that TrackPanel is being destroyed, but methods of
TrackPanelAx try to use it. But this is unlikely to expain crashes that
happen at other times than closing of windows.
Secondly, TrackPanelAx methods may iterate the list of tracks, while
that list is changing because of addition, deletion, or permutation.
Perhaps this only causes an incorrect result in TrackPanelAx queries, but
perhaps it also causes a dangling pointer to be followed.
Thirdly, TrackPanelAx stores a pointer to a track, but that track is
being destroyed, or has been. Using a shared_ptr would prevent this, but
then uses of that shared_ptr must also be serialized.

There is a problem with deleting a stereo track, but the problem appears
to be that an object_focus event for the track is sent for the track, and
then the track is immediately deleted. However, the problem is that that
object_focus event should not have been sent, and the solution is simply
not to send it.

What is "an object_focus event" ?

I was just using it as an abbreviation for wxACC_EVENT_OBJECT_FOCUS.

Post by Paul Licameli
I see calls to NotifyEvent in TrackPanelAx. Do you mean that you make
changes to issue fewer of those?

Making sure that events are sent when they shouldn't be.

not!

David.

As stated above, it's the same thread.
David.

Post by Paul Licameli
So there would be problems in defining mutexes and locking them in all
places, and then we must also make sure that this does not cause deadlocks.

I don't think that adding mutexes is solving a problem, and it would
just make the code unnecessarily complicated.

Post by David Bailes
David.

Post by James Crook
When Jaws is running there appear to be more paint messages being

Paul Licameli

2017-06-26 14:33:49 UTC

On Sat, Jun 17, 2017 at 12:23 PM, Paul Licameli <

Post by James Crook
David,
I'm relatively new to the party in terms of looking at actual screen
reader behaviour. I notice that Audacity with Narrator on leaks memory
like a sieve. Paul's cleaning up of naked news means non-narrator use does
not memory leak, so it makes these leaks more obvious. That leads me to
think that wxWidgets with any screen reader is code that is less well
exercised and tested, i.e. expect many bugs relating to screen readers in
wxWidgets. Probably we can find workarounds, staying on the parts that do
work, rather than complete fixes. But we may only be able to ameliorate
the problems rather than fix them.
I talked with Leland about screen readers at AU14 conference, and we
both were keen to provide access to Audacity algorithms at more of a
command line like level to get better accessibility. Long term this is
still in my view the best way to improve accessibility of Audacity - i.e.
have an alternative front end for the same audio engine. Have the normal
GUI which makes some assumptions about a user using a mouse, and a more
command line GUI that still has menus for access, but that is geared for
automation and keyboard use - with explicit binding of mouse wheel and x-y
to controlled values rather than implicit binding by click and drag.
IF frequent repainting is causing problems for Jaws, we can / should
ameliorate by removing redundant repaintings. That will be better for
all. Audacity has a somewhat Jekyll and Hyde attitude to repainting. It
has event based repainting and periodic painting off a timer. At some
future time we should clean that up too.
The Windows 10 creators update has done some strange things at start
up. The splash screen now appears sooner, and so it appears before it has
been positioned. We have some strange code with the splash screen to work
around a problem with the possibility of having splash screen and error
dialog at the same time, before the app has fully started. There should
not be a need for our own event loop (which is what we have). I think our
workarounds maybe should be untangled. As it is we show and hide our
splash screen rather quickly now, so it does not serve the role of a splash
screen, that reassures you that the app is starting up.
This doesn't directly answer the question of Jaws crashes, but may
be useful none the less.
--James.

Post by James Crook
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a

Post by James Crook
later
release?
James, is this a change to how stereo tracks are handled? What is

the new
design going to be?
I've been looking at why Audacity is crashing when Jaws is also running on
the Windows 10 creators update.

How reliably can you make these crashes happen?
I notice this comment in TrackPanel.cpp, which dates to Jan 2010 or
earlier -- I can't discover who wrote it first in the confusing git
repository for the older commits. I think it was new in version 1.3.9.
// The check for a null linked track is necessary because there's
// a possible race condition between the time the 2 linked tracks
// are added and when wxAccessible methods are called. This is
// most evident when using Jaws.
So this suggests multi-threading was involved. This makes me suspect
that the bare pointer, Track *TrackPanelAx::mFocusedTrack, is the
problematic dangling pointer here.
And this makes me suspect that a solution would involve changing our
management of Track objects everywhere to use std::shared_ptr rather that
std::unique_ptr. That might not be as hard as it sounds -- it could be
only a matter of changint some "using" type aliases.
Then, TrackPanelAx should point to its track by a shared_ptr.
This would not be sufficient: uses of that shared_ptr member of
TrackPanelAx should then themselves be guarded by a mutex. Standard
share_ptr gives you thread safety for free when threads each use different
shared_ptrs to the shared object, but not when threads contend for the same
shared_ptr. That is explained here: http://en.cppreference.com/w/
cpp/memory/shared_ptr
Is this a sufficient description, and do you understand C++11 smart
pointers enough, that you might attempt this rewrite yourself?
PRL

David, have you explored my suggestion?
PRL

I don't think that these sources of races are the problem (with one
exception noted below).

I do not yet see that you have pushed any fixes.

That's because I'm still working on this.

Post by Paul Licameli
I am not sure what is the exception below that you mean, that really may
be a race.
You did see the old comment in TrackPanel::FindTrackRect, author
unknown? Someone had reason to suspect races, but was that incorrect?

Do we know it was Leland who wrote that? I could not find the origin of
the comment, it is before the start of the repository.

I checked that TrackPanelAx::SetFocus and TrackPanelAx::GetLocation were
in the same thread.

Though that's not a proof that other threads are never used, it suggests to
me that "race condition" was indeed a misleading, unjustified description
of the problem, and so I will hold back any change that adds mutexes.

Post by Paul Licameli
I tried this with VoiceOver on Mac, but no, it is the main thread. But
if even one screen reader executes these methods on another thread, that
suggests that synchronizations of access to the TrackList may be the right
thing to do to avoid some crashes that would be hard to reproduce, though
they may have low probability.

Which are the null and dangling pointers that cause the crash?

Fixing these ordering problems sounds worthy, but could it also be that my
change that uses QueueEvent instead of ProcessEvent in TrackList eliminates
some of the problem? (Commit d3c9a1decb41b5ef27443dd7e9377ffe8363c3b3)

It could be that destroying TrackList emits events to be processed by the
project window that is being destroyed too, but by delaying the events to
the next event loop pass, they will be discarded because that pass never
happens?

PRL

Post by Paul Licameli
Even without thread synchronizations, the avoidance of this problem by
use of std::shared_ptr could be a good thing to do. I have written changes
to make TrackPanelAx::mFocusedTrack a shared_ptr.

Post by David Bailes
2. When a stereo track is added, there is a similar problem to the one
that Leland fixed - drawing when only one track of a stereo pair has been
added to the track list.

I had not mentioned Leland. What do you refer to?

It was Leland who fixed TrackPanel::FindTrackRect.

Post by Paul Licameli
I find this very old thread by Leland. http://audacity.238276.n2.nab
ble.com/Found-the-original-wxProgressDialog-problem-td259250.html I
think the problem he pointed out is not necessarily a multi-thread problem,
and a fix like what he proposed was made at commit d561e1a5fb8285a52d1b243661543ba2e4eeeda0
in the wxWidgets repository.

I don't think this is connected with the current problems.

Post by Paul Licameli
First, it may be that TrackPanel is being destroyed, but methods of
TrackPanelAx try to use it. But this is unlikely to expain crashes that
happen at other times than closing of windows.
Secondly, TrackPanelAx methods may iterate the list of tracks, while
that list is changing because of addition, deletion, or permutation.
Perhaps this only causes an incorrect result in TrackPanelAx queries, but
perhaps it also causes a dangling pointer to be followed.
Thirdly, TrackPanelAx stores a pointer to a track, but that track is
being destroyed, or has been. Using a shared_ptr would prevent this, but
then uses of that shared_ptr must also be serialized.

There is a problem with deleting a stereo track, but the problem appears
to be that an object_focus event for the track is sent for the track, and
then the track is immediately deleted. However, the problem is that that
object_focus event should not have been sent, and the solution is simply
not to send it.

What is "an object_focus event" ?

I was just using it as an abbreviation for wxACC_EVENT_OBJECT_FOCUS.

Post by Paul Licameli
I see calls to NotifyEvent in TrackPanelAx. Do you mean that you make
changes to issue fewer of those?

Making sure that events are sent when they shouldn't be.

As stated above, it's the same thread.
David.

Post by Paul Licameli
So there would be problems in defining mutexes and locking them in all
places, and then we must also make sure that this does not cause deadlocks.

I don't think that adding mutexes is solving a problem, and it would
just make the code unnecessarily complicated.

Post by David Bailes
David.

Post by James Crook
When Jaws is running there appear to be more paint messages being

David Bailes

2017-06-30 07:58:29 UTC

On Thu, Jun 22, 2017 at 7:31 PM, Paul Licameli <

On Sat, Jun 17, 2017 at 12:23 PM, Paul Licameli <

Post by James Crook
David,
I'm relatively new to the party in terms of looking at actual
screen reader behaviour. I notice that Audacity with Narrator on leaks
memory like a sieve. Paul's cleaning up of naked news means non-narrator
use does not memory leak, so it makes these leaks more obvious. That leads
me to think that wxWidgets with any screen reader is code that is less well
exercised and tested, i.e. expect many bugs relating to screen readers in
wxWidgets. Probably we can find workarounds, staying on the parts that do
work, rather than complete fixes. But we may only be able to ameliorate
the problems rather than fix them.
I talked with Leland about screen readers at AU14 conference, and
we both were keen to provide access to Audacity algorithms at more of a
command line like level to get better accessibility. Long term this is
still in my view the best way to improve accessibility of Audacity - i.e.
have an alternative front end for the same audio engine. Have the normal
GUI which makes some assumptions about a user using a mouse, and a more
command line GUI that still has menus for access, but that is geared for
automation and keyboard use - with explicit binding of mouse wheel and x-y
to controlled values rather than implicit binding by click and drag.
IF frequent repainting is causing problems for Jaws, we can /
should ameliorate by removing redundant repaintings. That will be better
for all. Audacity has a somewhat Jekyll and Hyde attitude to repainting.
It has event based repainting and periodic painting off a timer. At some
future time we should clean that up too.
The Windows 10 creators update has done some strange things at
start up. The splash screen now appears sooner, and so it appears before
it has been positioned. We have some strange code with the splash screen
to work around a problem with the possibility of having splash screen and
error dialog at the same time, before the app has fully started. There
should not be a need for our own event loop (which is what we have). I
think our workarounds maybe should be untangled. As it is we show and hide
our splash screen rather quickly now, so it does not serve the role of a
splash screen, that reassures you that the app is starting up.
This doesn't directly answer the question of Jaws crashes, but may
be useful none the less.
--James.

Post by James Crook
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a

Post by James Crook
later
release?
James, is this a change to how stereo tracks are handled? What is

the new
design going to be?
I've been looking at why Audacity is crashing when Jaws is also running on
the Windows 10 creators update.

How reliably can you make these crashes happen?
I notice this comment in TrackPanel.cpp, which dates to Jan 2010 or
earlier -- I can't discover who wrote it first in the confusing git
repository for the older commits. I think it was new in version 1.3.9.
// The check for a null linked track is necessary because there's
// a possible race condition between the time the 2 linked tracks
// are added and when wxAccessible methods are called. This is
// most evident when using Jaws.
So this suggests multi-threading was involved. This makes me
suspect that the bare pointer, Track *TrackPanelAx::mFocusedTrack, is the
problematic dangling pointer here.
And this makes me suspect that a solution would involve changing our
management of Track objects everywhere to use std::shared_ptr rather that
std::unique_ptr. That might not be as hard as it sounds -- it could be
only a matter of changint some "using" type aliases.
Then, TrackPanelAx should point to its track by a shared_ptr.
This would not be sufficient: uses of that shared_ptr member of
TrackPanelAx should then themselves be guarded by a mutex. Standard
share_ptr gives you thread safety for free when threads each use different
shared_ptrs to the shared object, but not when threads contend for the same
shared_ptr. That is explained here: http://en.cppreference.com/w/
cpp/memory/shared_ptr
Is this a sufficient description, and do you understand C++11 smart
pointers enough, that you might attempt this rewrite yourself?
PRL

David, have you explored my suggestion?
PRL

I don't think that these sources of races are the problem (with one
exception noted below).

I do not yet see that you have pushed any fixes.

That's because I'm still working on this.

Post by Paul Licameli
I am not sure what is the exception below that you mean, that really may
be a race.
You did see the old comment in TrackPanel::FindTrackRect, author
unknown? Someone had reason to suspect races, but was that incorrect?

Do we know it was Leland who wrote that? I could not find the origin of
the comment, it is before the start of the repository.

I checked in the old git stuff, and it was Leland.

David.

I checked that TrackPanelAx::SetFocus and TrackPanelAx::GetLocation were
in the same thread.

Though that's not a proof that other threads are never used, it suggests
to me that "race condition" was indeed a misleading, unjustified
description of the problem, and so I will hold back any change that adds
mutexes.

Post by Paul Licameli
I tried this with VoiceOver on Mac, but no, it is the main thread. But
if even one screen reader executes these methods on another thread, that
suggests that synchronizations of access to the TrackList may be the right
thing to do to avoid some crashes that would be hard to reproduce, though
they may have low probability.

Which are the null and dangling pointers that cause the crash?

There are a couple of problems in the destructor of a project when Jaws
1. The ruler is painted after the trackpanel has been destroyed, but the
ruler calls trackpanel on drawing. So a fix is to destroy mRuler before the
trackpanel.
2. Tooldocks are painted after the toolbars have gone. So a fix is to
clear the configuration of the tooldocks in the destructor of the
toolmanager.

Fixing these ordering problems sounds worthy, but could it also be that my
change that uses QueueEvent instead of ProcessEvent in TrackList eliminates
some of the problem? (Commit d3c9a1decb41b5ef27443dd7e9377ffe8363c3b3)
It could be that destroying TrackList emits events to be processed by the
project window that is being destroyed too, but by delaying the events to
the next event loop pass, they will be discarded because that pass never
happens?
PRL

Post by Paul Licameli
Even without thread synchronizations, the avoidance of this problem by
use of std::shared_ptr could be a good thing to do. I have written changes
to make TrackPanelAx::mFocusedTrack a shared_ptr.

Post by David Bailes
2. When a stereo track is added, there is a similar problem to the one
that Leland fixed - drawing when only one track of a stereo pair has been
added to the track list.

I had not mentioned Leland. What do you refer to?

It was Leland who fixed TrackPanel::FindTrackRect.

Post by Paul Licameli
I find this very old thread by Leland. http://audacity.238276.n2.nab
ble.com/Found-the-original-wxProgressDialog-problem-td259250.html I
think the problem he pointed out is not necessarily a multi-thread problem,
and a fix like what he proposed was made at commit d561e1a5fb8285a52d1b243661543ba2e4eeeda0
in the wxWidgets repository.

I don't think this is connected with the current problems.

First, it may be that TrackPanel is being destroyed, but methods of
TrackPanelAx try to use it. But this is unlikely to expain crashes that
happen at other times than closing of windows.
Secondly, TrackPanelAx methods may iterate the list of tracks, while
that list is changing because of addition, deletion, or permutation.
Perhaps this only causes an incorrect result in TrackPanelAx queries, but
perhaps it also causes a dangling pointer to be followed.
Thirdly, TrackPanelAx stores a pointer to a track, but that track is
being destroyed, or has been. Using a shared_ptr would prevent this, but
then uses of that shared_ptr must also be serialized.

There is a problem with deleting a stereo track, but the problem
appears to be that an object_focus event for the track is sent for the
track, and then the track is immediately deleted. However, the problem is
that that object_focus event should not have been sent, and the solution is
simply not to send it.

What is "an object_focus event" ?

I was just using it as an abbreviation for wxACC_EVENT_OBJECT_FOCUS.

Post by Paul Licameli
I see calls to NotifyEvent in TrackPanelAx. Do you mean that you make
changes to issue fewer of those?

Making sure that events are sent when they shouldn't be.

As stated above, it's the same thread.
David.

So there would be problems in defining mutexes and locking them in all
places, and then we must also make sure that this does not cause deadlocks.

I don't think that adding mutexes is solving a problem, and it would
just make the code unnecessarily complicated.

Post by David Bailes
David.

PRL

Post by James Crook
When Jaws is running there appear to be more paint messages being

Paul Licameli

2017-06-24 22:11:31 UTC

Post by David Bailes
I don't think that these sources of races are the problem (with one
exception noted below).

David, I think I understand more now. I think the unidentified commenter
in TrackPanel::FindTrackRect, and you too, used the term "race"
misleadingly to describe a problem that does not involve multiple threads.

Where is the evidence that multiple threads are really involved with Jaws?
A debugger breakpoint could give easy proof, but nobody has reported that
yet.

The old comment in TrackPanel code is trying to explain why the condition

if (target->GetLinked() && target->GetLink()) {

is not simply

if (target->GetLinked()) {

and when I change the code to that, I can make crashes happen with
VoiceOver, for instance by creating a stereo track, undoing, and redoing.

But this crash is deterministic and the detailed explanation has nothing to
do with multiple threads.

That is not the cause of the crashes you saw, but perhaps you are
describing a similar problem of processing events too soon during low-level
TrackList manipulations, though all execution is sequential.

Earlier this year I made this comment in TrackList::UpdatedEvent:

// PRL: ProcessEvent, not QueueEvent! Listeners may need their last

// chance to examine some removed tracks that are about to be destroyed.

I want to remove the reasons for that, by using more std::shared_ptr and
std::weak_ptr. I want that too for independently motivated reasons of code
simplification. I may push these changes soon. It may mitigate the Jaws
crashes, and all of it without mutexes, and without sending fewer events,
but rather just changing the timing of the processing of them.

PRL

Paul Licameli

2017-06-25 17:37:49 UTC

Post by David Bailes
I don't think that these sources of races are the problem (with one

Post by David Bailes
exception noted below).

David, I think I understand more now. I think the unidentified commenter
in TrackPanel::FindTrackRect, and you too, used the term "race"
misleadingly to describe a problem that does not involve multiple threads.
Where is the evidence that multiple threads are really involved with
Jaws? A debugger breakpoint could give easy proof, but nobody has reported
that yet.
The old comment in TrackPanel code is trying to explain why the condition
if (target->GetLinked() && target->GetLink()) {
is not simply
if (target->GetLinked()) {
and when I change the code to that, I can make crashes happen with
VoiceOver, for instance by creating a stereo track, undoing, and redoing.
But this crash is deterministic and the detailed explanation has nothing
to do with multiple threads.
That is not the cause of the crashes you saw, but perhaps you are
describing a similar problem of processing events too soon during low-level
TrackList manipulations, though all execution is sequential.
// PRL: ProcessEvent, not QueueEvent! Listeners may need their last
// chance to examine some removed tracks that are about to be destroyed.
I want to remove the reasons for that, by using more std::shared_ptr and
std::weak_ptr. I want that too for independently motivated reasons of code
simplification. I may push these changes soon. It may mitigate the Jaws
crashes, and all of it without mutexes, and without sending fewer events,
but rather just changing the timing of the processing of them.
PRL

David, I have accomplished what I described above at
commit d3c9a1decb41b5ef27443dd7e9377ffe8363c3b3

I wanted to do this even for other reasons unrelated to JAWS. Please try
it out.

I have written other changes that do some mutex locking, but I will hold
those back if there is no need. But I still want someone to test whether
there is need. If the callbacks in TrackPanelAx are reached from other
than the main thread, as a debugger could easily show, then some locking
should be done for safety.

PRL

David Bailes

2017-06-27 14:04:37 UTC

Post by David Bailes
I don't think that these sources of races are the problem (with one

Post by David Bailes
exception noted below).

David, I think I understand more now. I think the unidentified commenter
in TrackPanel::FindTrackRect, and you too, used the term "race"
misleadingly to describe a problem that does not involve multiple threads.
Where is the evidence that multiple threads are really involved with
Jaws? A debugger breakpoint could give easy proof, but nobody has reported
that yet.
The old comment in TrackPanel code is trying to explain why the condition
if (target->GetLinked() && target->GetLink()) {
is not simply
if (target->GetLinked()) {
and when I change the code to that, I can make crashes happen with
VoiceOver, for instance by creating a stereo track, undoing, and redoing.
But this crash is deterministic and the detailed explanation has nothing
to do with multiple threads.
That is not the cause of the crashes you saw, but perhaps you are
describing a similar problem of processing events too soon during low-level
TrackList manipulations, though all execution is sequential.
// PRL: ProcessEvent, not QueueEvent! Listeners may need their last
// chance to examine some removed tracks that are about to be destroyed.
I want to remove the reasons for that, by using more std::shared_ptr and
std::weak_ptr. I want that too for independently motivated reasons of code
simplification. I may push these changes soon. It may mitigate the Jaws
crashes, and all of it without mutexes, and without sending fewer events,
but rather just changing the timing of the processing of them.
PRL

David, I have accomplished what I described above at commit
d3c9a1decb41b5ef27443dd7e9377ffe8363c3b3
I wanted to do this even for other reasons unrelated to JAWS. Please try
it out.

That fixes that particular crash.

Why in TrackPanelAx::SetFocus did you change the place where mFocusedTrack
is updated? This needs to be updated before the object focus event is sent
to ensure that when TrackPanelAx::GetState is called, mFocusedTrack has the
correct value.

David.

I have written other changes that do some mutex locking, but I will hold
those back if there is no need. But I still want someone to test whether
there is need. If the callbacks in TrackPanelAx are reached from other
than the main thread, as a debugger could easily show, then some locking
should be done for safety.
PRL
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Paul Licameli

2017-06-27 17:03:55 UTC

Post by David Bailes
I don't think that these sources of races are the problem (with one

Post by David Bailes
exception noted below).

David, I think I understand more now. I think the unidentified
commenter in TrackPanel::FindTrackRect, and you too, used the term "race"
misleadingly to describe a problem that does not involve multiple threads.
Where is the evidence that multiple threads are really involved with
Jaws? A debugger breakpoint could give easy proof, but nobody has reported
that yet.
The old comment in TrackPanel code is trying to explain why the condition
if (target->GetLinked() && target->GetLink()) {
is not simply
if (target->GetLinked()) {
and when I change the code to that, I can make crashes happen with
VoiceOver, for instance by creating a stereo track, undoing, and redoing.
But this crash is deterministic and the detailed explanation has nothing
to do with multiple threads.
That is not the cause of the crashes you saw, but perhaps you are
describing a similar problem of processing events too soon during low-level
TrackList manipulations, though all execution is sequential.
// PRL: ProcessEvent, not QueueEvent! Listeners may need their last
// chance to examine some removed tracks that are about to be destroyed.
I want to remove the reasons for that, by using more std::shared_ptr and
std::weak_ptr. I want that too for independently motivated reasons of code
simplification. I may push these changes soon. It may mitigate the Jaws
crashes, and all of it without mutexes, and without sending fewer events,
but rather just changing the timing of the processing of them.
PRL

David, I have accomplished what I described above at
commit d3c9a1decb41b5ef27443dd7e9377ffe8363c3b3
I wanted to do this even for other reasons unrelated to JAWS. Please try
it out.

That fixes that particular crash.
Why in TrackPanelAx::SetFocus did you change the place where mFocusedTrack
is updated? This needs to be updated before the object focus event is sent
to ensure that when TrackPanelAx::GetState is called, mFocusedTrack has the
correct value.

I am not sure what I was thinking. Change that as you wish.

PRL

Post by David Bailes
David.

Post by Paul Licameli
I have written other changes that do some mutex locking, but I will hold
those back if there is no need. But I still want someone to test whether
there is need. If the callbacks in TrackPanelAx are reached from other
than the main thread, as a debugger could easily show, then some locking
should be done for safety.
PRL
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

David Engebretson Jr

2017-06-28 03:45:14 UTC

2.2.0 alpha 26, Windows 10 CE, JAWS 18:

1. Open Audacity
2. press alt+f4 to close Audacity

result:
Audacity crashes.

Henric Jungheim

2017-06-28 04:55:25 UTC

"Me too."

I don't know why it crashes, but at least I can confirm that
the same thing happens on my laptop (Win10 x64, Jaws 18).

Post by David Engebretson Jr
1. Open Audacity
2. press alt+f4 to close Audacity
Audacity crashes.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Paul Licameli

2017-06-28 05:04:42 UTC

If the crashes are still happening in builds after
commit d3c9a1decb41b5ef27443dd7e9377ffe8363c3b3, then what I did is
insufficient, and I leave it to David B. to investigate further.

Please clarify, whether you, Henric and David E., see the same problem in
2.1.3 or whether you think 2.2.0 shows a regression.

PRL

Post by Henric Jungheim
"Me too."
I don't know why it crashes, but at least I can confirm that
the same thing happens on my laptop (Win10 x64, Jaws 18).

Post by David Engebretson Jr
1. Open Audacity
2. press alt+f4 to close Audacity
Audacity crashes.
------------------------------------------------------------

------------------

Post by David Engebretson Jr
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

David Engebretson Jr

2017-06-28 05:28:18 UTC

Same thing happens in 2.1.3 using Windows 10 CE and JAWS 18.

From: Paul Licameli
Sent: Tuesday, June 27, 2017 10:04 PM
To: Audacity-Devel list
Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())

If the crashes are still happening in builds after commit d3c9a1decb41b5ef27443dd7e9377ffe8363c3b3, then what I did is insufficient, and I leave it to David B. to investigate further.

Please clarify, whether you, Henric and David E., see the same problem in 2.1.3 or whether you think 2.2.0 shows a regression.

PRL

On Wed, Jun 28, 2017 at 12:55 AM, Henric Jungheim <***@henric.org> wrote:

"Me too."

I don't know why it crashes, but at least I can confirm that
the same thing happens on my laptop (Win10 x64, Jaws 18).

Henric Jungheim

2017-06-28 05:52:27 UTC

I'm using VS2017 with my changes on top of the latest
Audacity master (b3208ab12d364abddf13ba107937ac46633276d6).

In a debug build, the exeption is throw when the deleted
ToolBar is used here:
https://github.com/audacity/audacity/blob/master/src/toolbars/ToolDock.cpp#L897
The toolbar pointer is not null, but what is is pointing to
has been overwritten with "0xdddddddd".

Note that this paint message is being handled during a dtor
when the window is being closed down
("wxWindow::~wxWindow()" from inside
"AudacityProject::OnCloseWindow(wxCloseEvent & event)").

The full stack trace is here:
Audacity.exe!wxWindowBase::GetPosition(int * x, int * y) Line 303 C++
Audacity.exe!wxWindowBase::GetRect() Line 345 C++

Audacity.exe!ToolDock::OnPaint(wxPaintEvent & __formal) Line 899 C++

Audacity.exe!wxAppConsoleBase::HandleEvent(wxEvtHandler * handler, void(wxEvtHandler::*)(wxEvent &) func, wxEvent & event) Line 612 C++
Audacity.exe!wxAppConsoleBase::CallEventHandler(wxEvtHandler * handler, wxEventFunctor & functor, wxEvent & event) Line 624 C++
Audacity.exe!wxEvtHandler::ProcessEventIfMatchesId(const wxEventTableEntryBase & entry, wxEvtHandler * handler, wxEvent & event) Line 1392 C++
Audacity.exe!wxEventHashTable::HandleEvent(wxEvent & event, wxEvtHandler * self) Line 996 C++
Audacity.exe!wxEvtHandler::TryHereOnly(wxEvent & event) Line 1587 C++
Audacity.exe!wxEvtHandler::TryBeforeAndHere(wxEvent & event) Line 3671 C++
Audacity.exe!wxEvtHandler::ProcessEventLocally(wxEvent & event) Line 1520 C++
Audacity.exe!wxEvtHandler::ProcessEvent(wxEvent & event) Line 1493 C++
Audacity.exe!wxEvtHandler::SafelyProcessEvent(wxEvent & event) Line 1611 C++
Audacity.exe!wxWindowBase::HandleWindowEvent(wxEvent & event) Line 1526 C++
Audacity.exe!wxWindow::HandlePaint() Line 4893 C++
Audacity.exe!wxWindow::MSWHandleMessage(__int64 * result, unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 2891 C++
Audacity.exe!wxWindow::MSWWindowProc(unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 3681 C++
Audacity.exe!wxWndProc(HWND__ * hWnd, unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 2746 C++
[External Code]
jhook.dll!000000006b4c368e() Unknown
jhook.dll!000000006b4843c4() Unknown
jhook.dll!000000006b484b2c() Unknown
jhook.dll!000000006b481e2c() Unknown
jhook.dll!000000006b481eb1() Unknown
jhook.dll!000000006b481cb3() Unknown
jhook.dll!000000006b490bc9() Unknown
jhook.dll!000000006b48fc2e() Unknown
jhook.dll!000000006b47cdd8() Unknown
jhook.dll!000000006b4af6cb() Unknown
jhook.dll!000000006b4b8841() Unknown
[External Code]
Audacity.exe!wxWindow::~wxWindow() Line 496 C++
[External Code]
Audacity.exe!wxTabTraversalWrapper<wxPanel>::~wxTabTraversalWrapper<wxPanel>() Line 32 C++
[External Code]
Audacity.exe!wxWindowBase::Destroy() Line 576 C++
Audacity.exe!wxWindowBase::DestroyChildren() Line 610 C++
Audacity.exe!AudacityProject::OnCloseWindow(wxCloseEvent & event) Line 2673 C++
Audacity.exe!wxAppConsoleBase::HandleEvent(wxEvtHandler * handler, void(wxEvtHandler::*)(wxEvent &) func, wxEvent & event) Line 612 C++
Audacity.exe!wxAppConsoleBase::CallEventHandler(wxEvtHandler * handler, wxEventFunctor & functor, wxEvent & event) Line 624 C++
Audacity.exe!wxEvtHandler::ProcessEventIfMatchesId(const wxEventTableEntryBase & entry, wxEvtHandler * handler, wxEvent & event) Line 1392 C++
Audacity.exe!wxEventHashTable::HandleEvent(wxEvent & event, wxEvtHandler * self) Line 996 C++
Audacity.exe!wxEvtHandler::TryHereOnly(wxEvent & event) Line 1587 C++
Audacity.exe!wxEvtHandler::TryBeforeAndHere(wxEvent & event) Line 3671 C++
Audacity.exe!wxEvtHandler::ProcessEvent(wxEvent & event) Line 1489 C++
Audacity.exe!wxEvtHandler::DoTryChain(wxEvent & event) Line 1552 C++
Audacity.exe!wxEvtHandler::ProcessEventLocally(wxEvent & event) Line 1520 C++
Audacity.exe!wxEvtHandler::ProcessEvent(wxEvent & event) Line 1493 C++
Audacity.exe!wxEvtHandler::SafelyProcessEvent(wxEvent & event) Line 1611 C++
Audacity.exe!wxWindowBase::HandleWindowEvent(wxEvent & event) Line 1526 C++
Audacity.exe!wxWindowBase::Close(bool force) Line 589 C++
Audacity.exe!wxFrame::MSWWindowProc(unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 848 C++
Audacity.exe!wxWndProc(HWND__ * hWnd, unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 2746 C++
[External Code]
Audacity.exe!wxWindow::MSWDefWindowProc(unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 2307 C++
Audacity.exe!wxWindow::MSWWindowProc(unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 3687 C++
Audacity.exe!wxTopLevelWindowMSW::MSWWindowProc(unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 467 C++
Audacity.exe!wxFrame::MSWWindowProc(unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 887 C++
Audacity.exe!wxWndProc(HWND__ * hWnd, unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 2746 C++
[External Code]
Audacity.exe!wxGUIEventLoop::ProcessMessage(tagMSG * msg) Line 172 C++
Audacity.exe!wxGUIEventLoop::Dispatch() Line 232 C++
Audacity.exe!wxEventLoopManual::ProcessEvents() Line 173 C++
Audacity.exe!wxEventLoopManual::DoRun() Line 206 C++
Audacity.exe!wxEventLoopBase::Run() Line 78 C++
Audacity.exe!wxAppConsoleBase::MainLoop() Line 334 C++
Audacity.exe!wxAppConsoleBase::OnRun() Line 260 C++
Audacity.exe!wxAppBase::OnRun() Line 305 C++
Audacity.exe!wxEntryReal(int & argc, wchar_t * * argv) Line 506 C++
Audacity.exe!wxEntry(int & argc, wchar_t * * argv) Line 188 C++
Audacity.exe!wxEntry(HINSTANCE__ * hInstance, HINSTANCE__ * __formal, char * __formal, int nCmdShow) Line 432 C++
Audacity.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * __formal, int nCmdShow) Line 733 C++
[External Code]

If the crashes are still happening in builds after
commitÂ d3c9a1decb41b5ef27443dd7e9377ffe8363c3b3, then what I did is
insufficient, and I leave it to David B. to investigate further.
Please clarify, whether you, Henric and David E., see the same problem
in 2.1.3 or whether you think 2.2.0 shows a regression.
PRL
On Wed, Jun 28, 2017 at 12:55 AM, Henric Jungheim
"Me too."
I don't know why it crashes, but at least I can confirm that
the same thing happens on my laptop (Win10 x64, Jaws 18).

Â Â 1. Open Audacity
Â Â 2. press alt+f4 to close Audacity
Â Â Audacity crashes.
------------------------------------------------------------

------------------

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

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! [5]http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[7]https://lists.sourceforge.net/lists/listinfo/audacity-devel
References
2. http://sdm.link/slashdot
4. https://lists.sourceforge.net/lists/listinfo/audacity-devel
5. http://sdm.link/slashdot
7. https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

David Bailes

2017-06-28 09:56:50 UTC

Post by Henric Jungheim
I'm using VS2017 with my changes on top of the latest
Audacity master (b3208ab12d364abddf13ba107937ac46633276d6).
In a debug build, the exeption is throw when the deleted
https://github.com/audacity/audacity/blob/master/src/
toolbars/ToolDock.cpp#L897
The toolbar pointer is not null, but what is is pointing to
has been overwritten with "0xdddddddd".
Note that this paint message is being handled during a dtor
when the window is being closed down
("wxWindow::~wxWindow()" from inside
"AudacityProject::OnCloseWindow(wxCloseEvent & event)").

thanks. In fact I'd already got a fix for this, and I've now committed it:
https://github.com/audacity/audacity/commit/69ab49c3a443c858f62bf0d6e2139e327d944187

It seems that Jaws is sending Audacity paint messages. I don't think Jaws
has any right to send paint messages to Audacity. Would that be your
interpretation of what's going on?

David.

Post by Henric Jungheim
Audacity.exe!wxWindowBase::GetPosition(int * x, int * y) Line
303 C++
Audacity.exe!wxWindowBase::GetRect() Line 345 C++

Audacity.exe!ToolDock::OnPaint(wxPaintEvent & __formal) Line 899

C++
Audacity.exe!wxAppConsoleBase::HandleEvent(wxEvtHandler *
handler, void(wxEvtHandler::*)(wxEvent &) func, wxEvent & event) Line 612
C++
Audacity.exe!wxAppConsoleBase::CallEventHandler(wxEvtHandler *
handler, wxEventFunctor & functor, wxEvent & event) Line 624 C++
Audacity.exe!wxEvtHandler::ProcessEventIfMatchesId(const
wxEventTableEntryBase & entry, wxEvtHandler * handler, wxEvent & event)
Line 1392 C++
Audacity.exe!wxEventHashTable::HandleEvent(wxEvent & event,
wxEvtHandler * self) Line 996 C++
Audacity.exe!wxEvtHandler::TryHereOnly(wxEvent & event) Line
1587 C++
Audacity.exe!wxEvtHandler::TryBeforeAndHere(wxEvent & event) Line
3671 C++
Audacity.exe!wxEvtHandler::ProcessEventLocally(wxEvent & event)
Line 1520 C++
Audacity.exe!wxEvtHandler::ProcessEvent(wxEvent & event) Line
1493 C++
Audacity.exe!wxEvtHandler::SafelyProcessEvent(wxEvent & event)
Line 1611 C++
Audacity.exe!wxWindowBase::HandleWindowEvent(wxEvent & event)
Line 1526 C++
Audacity.exe!wxWindow::HandlePaint() Line 4893 C++
Audacity.exe!wxWindow::MSWHandleMessage(__int64 * result,
unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 2891
C++
Audacity.exe!wxWindow::MSWWindowProc(unsigned int message,
unsigned __int64 wParam, __int64 lParam) Line 3681 C++
Audacity.exe!wxWndProc(HWND__ * hWnd, unsigned int message,
unsigned __int64 wParam, __int64 lParam) Line 2746 C++
[External Code]
jhook.dll!000000006b4c368e() Unknown
jhook.dll!000000006b4843c4() Unknown
jhook.dll!000000006b484b2c() Unknown
jhook.dll!000000006b481e2c() Unknown
jhook.dll!000000006b481eb1() Unknown
jhook.dll!000000006b481cb3() Unknown
jhook.dll!000000006b490bc9() Unknown
jhook.dll!000000006b48fc2e() Unknown
jhook.dll!000000006b47cdd8() Unknown
jhook.dll!000000006b4af6cb() Unknown
jhook.dll!000000006b4b8841() Unknown
[External Code]
Audacity.exe!wxWindow::~wxWindow() Line 496 C++
[External Code]
Audacity.exe!wxTabTraversalWrapper<wxPanel>
::~wxTabTraversalWrapper<wxPanel>() Line 32 C++
[External Code]
Audacity.exe!wxWindowBase::Destroy() Line 576 C++
Audacity.exe!wxWindowBase::DestroyChildren() Line 610 C++
Audacity.exe!AudacityProject::OnCloseWindow(wxCloseEvent & event)
Line 2673 C++
Audacity.exe!wxAppConsoleBase::HandleEvent(wxEvtHandler *
handler, void(wxEvtHandler::*)(wxEvent &) func, wxEvent & event) Line 612
C++
Audacity.exe!wxAppConsoleBase::CallEventHandler(wxEvtHandler *
handler, wxEventFunctor & functor, wxEvent & event) Line 624 C++
Audacity.exe!wxEvtHandler::ProcessEventIfMatchesId(const
wxEventTableEntryBase & entry, wxEvtHandler * handler, wxEvent & event)
Line 1392 C++
Audacity.exe!wxEventHashTable::HandleEvent(wxEvent & event,
wxEvtHandler * self) Line 996 C++
Audacity.exe!wxEvtHandler::TryHereOnly(wxEvent & event) Line
1587 C++
Audacity.exe!wxEvtHandler::TryBeforeAndHere(wxEvent & event) Line
3671 C++
Audacity.exe!wxEvtHandler::ProcessEvent(wxEvent & event) Line
1489 C++
Audacity.exe!wxEvtHandler::DoTryChain(wxEvent & event) Line 1552
C++
Audacity.exe!wxEvtHandler::ProcessEventLocally(wxEvent & event)
Line 1520 C++
Audacity.exe!wxEvtHandler::ProcessEvent(wxEvent & event) Line
1493 C++
Audacity.exe!wxEvtHandler::SafelyProcessEvent(wxEvent & event)
Line 1611 C++
Audacity.exe!wxWindowBase::HandleWindowEvent(wxEvent & event)
Line 1526 C++
Audacity.exe!wxWindowBase::Close(bool force) Line 589 C++
Audacity.exe!wxFrame::MSWWindowProc(unsigned int message,
unsigned __int64 wParam, __int64 lParam) Line 848 C++
Audacity.exe!wxWndProc(HWND__ * hWnd, unsigned int message,
unsigned __int64 wParam, __int64 lParam) Line 2746 C++
[External Code]
Audacity.exe!wxWindow::MSWDefWindowProc(unsigned int nMsg,
unsigned __int64 wParam, __int64 lParam) Line 2307 C++
Audacity.exe!wxWindow::MSWWindowProc(unsigned int message,
unsigned __int64 wParam, __int64 lParam) Line 3687 C++
Audacity.exe!wxTopLevelWindowMSW::MSWWindowProc(unsigned int
message, unsigned __int64 wParam, __int64 lParam) Line 467 C++
Audacity.exe!wxFrame::MSWWindowProc(unsigned int message,
unsigned __int64 wParam, __int64 lParam) Line 887 C++
Audacity.exe!wxWndProc(HWND__ * hWnd, unsigned int message,
unsigned __int64 wParam, __int64 lParam) Line 2746 C++
[External Code]
Audacity.exe!wxGUIEventLoop::ProcessMessage(tagMSG * msg) Line
172 C++
Audacity.exe!wxGUIEventLoop::Dispatch() Line 232 C++
Audacity.exe!wxEventLoopManual::ProcessEvents() Line 173
C++
Audacity.exe!wxEventLoopManual::DoRun() Line 206 C++
Audacity.exe!wxEventLoopBase::Run() Line 78 C++
Audacity.exe!wxAppConsoleBase::MainLoop() Line 334 C++
Audacity.exe!wxAppConsoleBase::OnRun() Line 260 C++
Audacity.exe!wxAppBase::OnRun() Line 305 C++
Audacity.exe!wxEntryReal(int & argc, wchar_t * * argv) Line 506 C++
Audacity.exe!wxEntry(int & argc, wchar_t * * argv) Line 188 C++
Audacity.exe!wxEntry(HINSTANCE__ * hInstance, HINSTANCE__ *
__formal, char * __formal, int nCmdShow) Line 432 C++
Audacity.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ *
hPrevInstance, char * __formal, int nCmdShow) Line 733 C++
[External Code]

If the crashes are still happening in builds after
commitÃ d3c9a1decb41b5ef27443dd7e9377ffe8363c3b3, then what I did is
insufficient, and I leave it to David B. to investigate further.
Please clarify, whether you, Henric and David E., see the same problem
in 2.1.3 or whether you think 2.2.0 shows a regression.
PRL
On Wed, Jun 28, 2017 at 12:55 AM, Henric Jungheim
"Me too."
I don't know why it crashes, but at least I can confirm that
the same thing happens on my laptop (Win10 x64, Jaws 18).

Ã Ã 1. Open Audacity
Ã Ã 2. press alt+f4 to close Audacity
Ã Ã Audacity crashes.
------------------------------------------------------------

------------------

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

David Bailes

2017-06-30 07:55:47 UTC

Post by David Bailes
I don't think that these sources of races are the problem (with one

Post by David Bailes
exception noted below).

David, I think I understand more now. I think the unidentified
commenter in TrackPanel::FindTrackRect, and you too, used the term "race"
misleadingly to describe a problem that does not involve multiple threads.
Where is the evidence that multiple threads are really involved with
Jaws? A debugger breakpoint could give easy proof, but nobody has reported
that yet.
The old comment in TrackPanel code is trying to explain why the condition
if (target->GetLinked() && target->GetLink()) {
is not simply
if (target->GetLinked()) {
and when I change the code to that, I can make crashes happen with
VoiceOver, for instance by creating a stereo track, undoing, and redoing.
But this crash is deterministic and the detailed explanation has nothing
to do with multiple threads.
That is not the cause of the crashes you saw, but perhaps you are
describing a similar problem of processing events too soon during low-level
TrackList manipulations, though all execution is sequential.
// PRL: ProcessEvent, not QueueEvent! Listeners may need their last
// chance to examine some removed tracks that are about to be destroyed.
I want to remove the reasons for that, by using more std::shared_ptr and
std::weak_ptr. I want that too for independently motivated reasons of code
simplification. I may push these changes soon. It may mitigate the Jaws
crashes, and all of it without mutexes, and without sending fewer events,
but rather just changing the timing of the processing of them.
PRL

David, I have accomplished what I described above at
commit d3c9a1decb41b5ef27443dd7e9377ffe8363c3b3
I wanted to do this even for other reasons unrelated to JAWS. Please try
it out.

That fixes that particular crash.

It also fixes the crash when deleting a stereo file. Thanks.

David.

Post by David Bailes
Why in TrackPanelAx::SetFocus did you change the place where mFocusedTrack
is updated? This needs to be updated before the object focus event is sent
to ensure that when TrackPanelAx::GetState is called, mFocusedTrack has the
correct value.
David.

David Bailes

2017-06-24 10:29:50 UTC

Post by James Crook
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a later

Post by James Crook
release?
James, is this a change to how stereo tracks are handled? What is the

new
design going to be?
I've been looking at why Audacity is crashing when Jaws is also running on
the Windows 10 creators update.

How reliably can you make these crashes happen?

They are reproducible, and can occur in a number of different circumstances.

Post by Paul Licameli
I notice this comment in TrackPanel.cpp, which dates to Jan 2010 or
earlier -- I can't discover who wrote it first in the confusing git
repository for the older commits. I think it was new in version 1.3.9.
// The check for a null linked track is necessary because there's
// a possible race condition between the time the 2 linked tracks
// are added and when wxAccessible methods are called. This is
// most evident when using Jaws.
So this suggests multi-threading was involved.

The problem was that an object_focus event was sent for the first track of
a stereo track pair when the second track had not been added to the track
list.

Post by Paul Licameli
This makes me suspect that the bare pointer, Track
*TrackPanelAx::mFocusedTrack, is the problematic dangling pointer here.

I don't think that was the problem.

David.

Post by Paul Licameli
And this makes me suspect that a solution would involve changing our
management of Track objects everywhere to use std::shared_ptr rather that
std::unique_ptr. That might not be as hard as it sounds -- it could be
only a matter of changint some "using" type aliases.
Then, TrackPanelAx should point to its track by a shared_ptr.
This would not be sufficient: uses of that shared_ptr member of
TrackPanelAx should then themselves be guarded by a mutex. Standard
share_ptr gives you thread safety for free when threads each use different
shared_ptrs to the shared object, but not when threads contend for the same
shared_ptr. That is explained here: http://en.cppreference.com/w/
cpp/memory/shared_ptr
Is this a sufficient description, and do you understand C++11 smart
pointers enough, that you might attempt this rewrite yourself?
PRL

Post by James Crook
When Jaws is running there appear to be more paint messages being sent to

James Crook

2017-06-17 11:02:25 UTC

GetLinked() in Audacity is overly special case code. It treats stereo
tracks as a special case embellishment of mono tracks.

A more logical design would not care whether we had none, one, two or
twenty channels in a 'track'.
Our code would just iterate through all channels, rather than as now do
the first channel and then possibly do a second channel as a special
case. That special case code is often mostly a reduplication of the
'first channel' code. It is not causing serious problems (we think) but
it is messy having 85 or so mini-duplications of code that are
completely avoidable.

My expectation is that we will move in two steps. In the first step we
make the number of channels in a track arbitrary and clean up
GetLinked(). In the second step, we put channels, views and different
kinds of track on the same footing, so we can have a track that has
other views, channels and tracks in it, so we can have spectrogram and
wave view of the same track, with a label track overlay on one of them,
for example. We will then need to be clearer what we are iterating
over, e.g. iterate over all views of the data in a track, or over all
data in a track, or over all audio data in a track.

In the course of such changes, we would likely need to reexamine what
events happen when. E.g refreshes and flushes inside loops or outside.
So very indirectly this would have a bearing on the repeated update
events you are talking about.

Jaws not working with the creators update is a much more pressing
problem than our code for GetLinked() being messy, so I wouldn't expect
us to proceed down the cleaning up GetLinked() route in order to
indirectly clear or ameliorate the Jaws issue.

--James.

Post by James Crook
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a later
release?

James, is this a change to how stereo tracks are handled? What is the new
design going to be?
I've been looking at why Audacity is crashing when Jaws is also running on
the Windows 10 creators update.
When Jaws is running there appear to be more paint messages being sent to
Audacity, though it's unclear to me what is causing this.
For example when deleting a stereo track, a paint message can occur after
one of the tracks has been removed, and this causes audacity to crash.
Regardless of whether these extra paint message should be occurring, the
code for removing stereo tracks sends update events after each of the two
tracks is removed from the track list, rather than a single update event
after both tracks have be removed. This doesn't seem right.
Hence my interest in any changes to the design of stereo tracks.
David.

Post by James Crook
--James.

Paul Licameli

2017-06-17 14:57:39 UTC

Post by James Crook
GetLinked() in Audacity is overly special case code. It treats stereo
tracks as a special case embellishment of mono tracks.
A more logical design would not care whether we had none, one, two or
twenty channels in a 'track'.
Our code would just iterate through all channels, rather than as now do
the first channel and then possibly do a second channel as a special case.
That special case code is often mostly a reduplication of the 'first
channel' code. It is not causing serious problems (we think) but it is
messy having 85 or so mini-duplications of code that are completely
avoidable.
My expectation is that we will move in two steps. In the first step we
make the number of channels in a track arbitrary and clean up GetLinked().
In the second step, we put channels, views and different kinds of track on
the same footing, so we can have a track that has other views, channels and
tracks in it, so we can have spectrogram and wave view of the same track,
with a label track overlay on one of them, for example. We will then need
to be clearer what we are iterating over, e.g. iterate over all views of
the data in a track, or over all data in a track, or over all audio data in
a track.
In the course of such changes, we would likely need to reexamine what
events happen when. E.g refreshes and flushes inside loops or outside. So
very indirectly this would have a bearing on the repeated update events you
are talking about.

My understanding is that wxWindows does not send one refresh event for each
Refresh() call to a window. Rather it only sends one message to each
window that has had at least one call to Refresh between one event loop
pass and the next. Am I wrong?
PRL

Post by James Crook
Jaws not working with the creators update is a much more pressing problem
than our code for GetLinked() being messy, so I wouldn't expect us to
proceed down the cleaning up GetLinked() route in order to indirectly clear
or ameliorate the Jaws issue.
--James.

Post by James Crook
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a later

Post by James Crook
release?
James, is this a change to how stereo tracks are handled? What is the new

Paul Licameli

2017-06-17 15:23:27 UTC

Post by James Crook
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a later
release?

My present thinking is no, this would be an overreach for 2.2.0. I would
rather like to get it ready as a big-bang for the start of 2.2.1. Which
could be stabilized sooner than otherwise, without these changes.

Why do you ask now? Do you want to persuade me otherwise? Do you want to
rebase some of your pending work onto it?

Should I go for broke pushing all my pervasive disruptions into one longer
delayed version for one kick-the-tyres? (I don't think so.)

What I have done so far is in a branch called track-iters2. Not only are
there far fewer calls to GetLink(), but also every iteration over tracks
was rewritten in an idiom that is less verbose and also type- and
const-correct through some use of C++ templates. I didn't like seeing
C-style casts like ((WaveTrack*)t) and those are all gone. Instead you can
say something like: for (auto t : trackList->Selected<const WaveTrack>) {
... }

I did bring that branch up to date with early 2.2.0 developments and test
it to the extent of putting a breakpoint at every changed place and hitting
it.

But much work would remain, between that and TrackPanel refactoring, to
rebase one onto the other and resolve conflicts. I decided that the
TrackPanel refactor was the more valuable thing that I ought to press on
with first. So I knuckled down to the task of reviewing all my forgotten
two year old code, and that hurdle is thankfully past.

You mention iterations over things in another email. As I see it, our code
doesn't yet do a good enough job of decoupling the persistent entities in
the data (tracks and their contents) from the view entities in the display
(so, as you say, we ought to be freer to make many-to-one correspondences).

So better abstracted iteration over both kinds of entity would be
valuable. And for the latter kind, display, we are making progress right
now.

Please look at TrackPanelCellIterator in head. I made changes to this
class only yesterday. The purpose of this class is iteration over the
disjoint rectangular areas of TrackPanel that have different policies for
drawing themselves and for dispatching events when the pointer is in them.

I want to concentrate the knowledge of just what the screen-partitioning
policy is, into one class, that you might replace in order to define a
different policy. This is an advancement toward that.

PRL

Post by James Crook
--James.

James Crook

2017-06-17 17:34:15 UTC

Post by James Crook
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a later
release?

I asked because of noticing work related to GetLinked() in
VisibleTrackIterator:: and wondering what your plan was.
I'd like to persuade you to do it early on in 2.2.1.

There is a possible case for doing it sooner, as current HEAD, despite
your best efforts in the refactoring, seems rather buggy, and so will
need a lot of testing. There is a possible case that the GetLinked code
refactoring is dangerous too, and so possibly a case to get one lot of
testing covering both refactorings. Counter arguments include that more
changes means harder bug hunting, and overall it would assuredly affect
schedule. I think it is sufficiently risky/big not to do it now.

Nope, there's not pending work of mine that would benefit from rebasing
on it. Main concern is that you don't have to keep rebasing it (with
conflicts) to carry it forward.

Post by Paul Licameli
Should I go for broke pushing all my pervasive disruptions into one longer
delayed version for one kick-the-tyres? (I don't think so.)

I don't think so either.

Post by Paul Licameli
What I have done so far is in a branch called track-iters2. Not only are
there far fewer calls to GetLink(), but also every iteration over tracks
was rewritten in an idiom that is less verbose and also type- and
const-correct through some use of C++ templates. I didn't like seeing
C-style casts like ((WaveTrack*)t) and those are all gone. Instead you can
say something like: for (auto t : trackList->Selected<const WaveTrack>) {
... }
I did bring that branch up to date with early 2.2.0 developments and test
it to the extent of putting a breakpoint at every changed place and hitting
it.
But much work would remain, between that and TrackPanel refactoring, to
rebase one onto the other and resolve conflicts. I decided that the
TrackPanel refactor was the more valuable thing that I ought to press on
with first. So I knuckled down to the task of reviewing all my forgotten
two year old code, and that hurdle is thankfully past.

I'm glad too, as you should not be carrying that refactoring forward
endlessly.

Post by Paul Licameli
You mention iterations over things in another email. As I see it, our code
doesn't yet do a good enough job of decoupling the persistent entities in
the data (tracks and their contents) from the view entities in the display

Post by Paul Licameli
(so, as you say, we ought to be freer to make many-to-one correspondences).
So better abstracted iteration over both kinds of entity would be
valuable. And for the latter kind, display, we are making progress right
now.
Please look at TrackPanelCellIterator in head. I made changes to this
class only yesterday.

Yes. That's partly what prompted my question.

Post by Paul Licameli
The purpose of this class is iteration over the
disjoint rectangular areas of TrackPanel that have different policies for
drawing themselves and for dispatching events when the pointer is in them.
I want to concentrate the knowledge of just what the screen-partitioning
policy is, into one class, that you might replace in order to define a
different policy. This is an advancement toward that.

Cool.

Post by James Crook
--James.

Paul Licameli

2017-06-17 17:47:08 UTC

Post by James Crook
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a later

Post by James Crook
release?

What are you referring to?

Broken keystroke dispatching has been fixed.

Peter has reported crashes on Windows for menu items, still to investigate.

Still, these are "gross" problems that have obvious solutions. Question is
whether there is much both gross and subtle.

You see how I want to allow time to shake bugs out of things like this. To
get the other iteration work even to the point of testing by Gale and Peter
is going to require nontrivial effort of conflict resolution on my part.
So again I'm inclined to say no, let this go until 2.2.1.

PRL

Post by James Crook
and so will need a lot of testing. There is a possible case that the
GetLinked code refactoring is dangerous too, and so possibly a case to get
one lot of testing covering both refactorings. Counter arguments include
that more changes means harder bug hunting, and overall it would assuredly
affect schedule. I think it is sufficiently risky/big not to do it now.
Nope, there's not pending work of mine that would benefit from rebasing on
it. Main concern is that you don't have to keep rebasing it (with
conflicts) to carry it forward.
Should I go for broke pushing all my pervasive disruptions into one longer

Post by James Crook
delayed version for one kick-the-tyres? (I don't think so.)

I don't think so either.
What I have done so far is in a branch called track-iters2. Not only are

Post by James Crook
there far fewer calls to GetLink(), but also every iteration over tracks
was rewritten in an idiom that is less verbose and also type- and
const-correct through some use of C++ templates. I didn't like seeing
C-style casts like ((WaveTrack*)t) and those are all gone. Instead you can
say something like: for (auto t : trackList->Selected<const WaveTrack>) {
... }
I did bring that branch up to date with early 2.2.0 developments and test
it to the extent of putting a breakpoint at every changed place and hitting
it.
But much work would remain, between that and TrackPanel refactoring, to
rebase one onto the other and resolve conflicts. I decided that the
TrackPanel refactor was the more valuable thing that I ought to press on
with first. So I knuckled down to the task of reviewing all my forgotten
two year old code, and that hurdle is thankfully past.

I'm glad too, as you should not be carrying that refactoring forward
endlessly.

Post by James Crook
You mention iterations over things in another email. As I see it, our code
doesn't yet do a good enough job of decoupling the persistent entities in
the data (tracks and their contents) from the view entities in the display

Post by James Crook
(so, as you say, we ought to be freer to make many-to-one
correspondences).
So better abstracted iteration over both kinds of entity would be
valuable. And for the latter kind, display, we are making progress right
now.
Please look at TrackPanelCellIterator in head. I made changes to this
class only yesterday.

Yes. That's partly what prompted my question.

Post by James Crook
The purpose of this class is iteration over the
disjoint rectangular areas of TrackPanel that have different policies for
drawing themselves and for dispatching events when the pointer is in them.
I want to concentrate the knowledge of just what the screen-partitioning
policy is, into one class, that you might replace in order to define a
different policy. This is an advancement toward that.

Cool.
PRL

Post by James Crook
--James.

James Crook

2017-06-17 18:29:49 UTC

Post by James Crook
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a later

Post by James Crook
release?

What are you referring to?
Broken keystroke dispatching has been fixed.
Peter has reported crashes on Windows for menu items, still to investigate.

I hit that one too, for TCP menu.
I also hit a 'sequence error' exception when doing a cut, which
unfortunately I could not make repeatable. I can't find the text
'sequence error' in the code, so I'm guessing I mis rememebered what the
error message dialog said.
I also hit bug http://bugzilla.audacityteam.org/show_bug.cgi?id=1663
which it turns out is actually a bug in 2.1.3, so not new..

So that is 3 significant distinct bugs in a relatively short spell of
use, suggesting (at the time) that the rearrangement has introduced half
a dozen or so.... As 1663 predates the refactoring, I was mistaken in
counting it.

Post by Paul Licameli
Still, these are "gross" problems that have obvious solutions. Question is
whether there is much both gross and subtle.
You see how I want to allow time to shake bugs out of things like this.

Yes.

Post by Paul Licameli
To get the other iteration work even to the point of testing by Gale and Peter
is going to require nontrivial effort of conflict resolution on my part.
So again I'm inclined to say no, let this go until 2.2.1.

Sounds sensible to me too.
--James

Post by James Crook
delayed version for one kick-the-tyres? (I don't think so.)

I don't think so either.
What I have done so far is in a branch called track-iters2. Not only are

I'm glad too, as you should not be carrying that refactoring forward
endlessly.

Yes. That's partly what prompted my question.

Cool.
PRL

Post by James Crook
--James.

Paul Licameli

2017-06-17 18:54:42 UTC

Post by James Crook
Paul, are we going to banish GetLinked() for 2.2.0 or wait until a later

Post by James Crook
release?
My present thinking is no, this would be an overreach for 2.2.0. I

would
rather like to get it ready as a big-bang for the start of 2.2.1. Which
could be stabilized sooner than otherwise, without these changes.
Why do you ask now? Do you want to persuade me otherwise? Do you want to
rebase some of your pending work onto it?
I asked because of noticing work related to GetLinked() in

VisibleTrackIterator:: and wondering what your plan was.
I'd like to persuade you to do it early on in 2.2.1.
There is a possible case for doing it sooner, as current HEAD, despite
your best efforts in the refactoring, seems rather buggy,

What are you referring to?
Broken keystroke dispatching has been fixed.
Peter has reported crashes on Windows for menu items, still to investigate.

You may have hit on a reproduction of
http://bugzilla.audacityteam.org/show_bug.cgi?id=1655

which seems not a consequence of the track panel refactor, though it is one
of my earlier 2.2.0 work.

So again, it seems there are loose ends enough to tidy up without taking on
the track iteration project too.

PRL

Post by James Crook
I also hit bug http://bugzilla.audacityteam.org/show_bug.cgi?id=1663
which it turns out is actually a bug in 2.1.3, so not new..
So that is 3 significant distinct bugs in a relatively short spell of use,
suggesting (at the time) that the rearrangement has introduced half a dozen
or so.... As 1663 predates the refactoring, I was mistaken in counting it.
Still, these are "gross" problems that have obvious solutions. Question is

Post by Paul Licameli
whether there is much both gross and subtle.
You see how I want to allow time to shake bugs out of things like this.

Yes.

Sounds sensible to me too.
--James

Post by Paul Licameli
PRL
and so will need a lot of testing. There is a possible case that the

Post by James Crook
GetLinked code refactoring is dangerous too, and so possibly a case to get
one lot of testing covering both refactorings. Counter arguments include
that more changes means harder bug hunting, and overall it would assuredly
affect schedule. I think it is sufficiently risky/big not to do it now.
Nope, there's not pending work of mine that would benefit from rebasing on
it. Main concern is that you don't have to keep rebasing it (with
conflicts) to carry it forward.
Should I go for broke pushing all my pervasive disruptions into one longer

Post by James Crook
delayed version for one kick-the-tyres? (I don't think so.)
I don't think so either.

What I have done so far is in a branch called track-iters2. Not only are

endlessly.
You mention iterations over things in another email. As I see it, our

Post by James Crook
code
doesn't yet do a good enough job of decoupling the persistent entities in
the data (tracks and their contents) from the view entities in the display
+1

(so, as you say, we ought to be freer to make many-to-one

Post by James Crook
correspondences).
So better abstracted iteration over both kinds of entity would be
valuable. And for the latter kind, display, we are making progress right
now.
Please look at TrackPanelCellIterator in head. I made changes to this
class only yesterday.
Yes. That's partly what prompted my question.

The purpose of this class is iteration over the

Post by James Crook
disjoint rectangular areas of TrackPanel that have different policies for
drawing themselves and for dispatching events when the pointer is in them.
I want to concentrate the knowledge of just what the screen-partitioning
policy is, into one class, that you might replace in order to define a
different policy. This is an advancement toward that.
Cool.

PRL

Post by James Crook
--James.

James Crook

2017-06-17 19:04:39 UTC