Audacity

›

audacity-devel

Crash on starting monitoring in Meter Toolbar...

9 Messages

Martyn Shaw-2

Reply Threaded

...after recording in another project window then closing it.

Please send reference to details, not reproduced here at the moment.

Martyn

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
audacity-devel mailing list
audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale (Audacity Team)

Re: Crash on starting monitoring in Meter Toolbar...

Reply Threaded

| From Martyn Shaw <martynshaw99@...>
| Wed, 24 Sep 2008 01:18:21 +0100
| Subject: [Audacity-devel] Crash on starting monitoring in Meter Toolbar...
> ...after recording in another project window then closing it.
>
> Please send reference to details, not reproduced here at the moment.

1 Launch Audacity
2 R to start recording
3 Spacebar to stop recording
4 File > New
5 Task switch back to the first project
6 File > Close and don't save changes
7 In the remaining project window, click the Recording Meter
to start monitoring
8 Produces Visual C++ Runtime Error R6025 - "pure virtual
function call"

Steps 4 and 5 not needed if you have Audacity set in Preferences
not to quit on closing last window.

Gale

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
audacity-devel mailing list
audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Martyn Shaw-2

Re: Crash on starting monitoring in Meter Toolbar...

Reply Threaded

This looks to be well out of my area, maybe Leland can help? A
problem with mListener getting deleted / pointing to the wrong place
when the first window gets closed? 0xfeeefeee looks suspicious to me.
I don't think I can get much further here.

HTH
Martyn

Gale Andrews wrote:

> | From Martyn Shaw <martynshaw99@...>
> | Wed, 24 Sep 2008 01:18:21 +0100
> | Subject: [Audacity-devel] Crash on starting monitoring in Meter Toolbar...
>> ...after recording in another project window then closing it.
>>
>> Please send reference to details, not reproduced here at the moment.
>
> 1 Launch Audacity
> 2 R to start recording
> 3 Spacebar to stop recording
> 4 File > New
> 5 Task switch back to the first project
> 6 File > Close and don't save changes
> 7 In the remaining project window, click the Recording Meter
> to start monitoring
> 8 Produces Visual C++ Runtime Error R6025 - "pure virtual
> function call"
>
> Steps 4 and 5 not needed if you have Audacity set in Preferences
> not to quit on closing last window.
>
>
> Gale
>
>
>
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> audacity-devel mailing list
> audacity-devel@...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
audacity-devel mailing list
audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Dawson Written

Re: Crash on starting monitoring in Meter Toolbar...

Reply Threaded

That is what's happening. Right at line 1643 in src/Project.cpp
(currently rev 1.377), the code, gAudacityProjects.Remove(this), deletes
the AudacityProject (AudioIOListener) object and when clicking on the
recording meter, Meter::StartMonitoring and in turn
AudioIO::StartMonitoring gets the gAudioIO->mListener still pointing to
the deleted object. In the debugger, if I change it to match the value
gActiveProject either after src/Project.cpp:1653 or just around
Meter::StartMonitoring, it will continue without crashing.
Unfortunately, mListener is private and cannot be changed that way in
Project.cpp and at Meter::StartMonitoring, that would probably be to
deep to consistently check the pointers there. This one looks like a
tough nut to crack.

Hope that was new light to shed on this,
Dawson

Martyn Shaw wrote:

> This looks to be well out of my area, maybe Leland can help? A
> problem with mListener getting deleted / pointing to the wrong place
> when the first window gets closed? 0xfeeefeee looks suspicious to me.
> I don't think I can get much further here.
>
> HTH
> Martyn
>
> Gale Andrews wrote:
>> | From Martyn Shaw <martynshaw99@...>
>> | Wed, 24 Sep 2008 01:18:21 +0100
>> | Subject: [Audacity-devel] Crash on starting monitoring in Meter Toolbar...
>>> ...after recording in another project window then closing it.
>>>
>>> Please send reference to details, not reproduced here at the moment.
>> 1 Launch Audacity
>> 2 R to start recording
>> 3 Spacebar to stop recording
>> 4 File > New
>> 5 Task switch back to the first project
>> 6 File > Close and don't save changes
>> 7 In the remaining project window, click the Recording Meter
>> to start monitoring
>> 8 Produces Visual C++ Runtime Error R6025 - "pure virtual
>> function call"
>>
>> Steps 4 and 5 not needed if you have Audacity set in Preferences
>> not to quit on closing last window.
>>
>>
>> Gale
>>
>>
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> audacity-devel mailing list
>> audacity-devel@...
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> audacity-devel mailing list
> audacity-devel@...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

Martyn Shaw-2

Re: Crash on starting monitoring in Meter Toolbar...

Reply Threaded

Hi there Dawson

Useful thoughts there Dawson. If you can make it through this post,
it may help us to fix this (or maybe not! ;-) ).

I had another look and what you say is true. Perhaps the following
will just show my ignorance of OOP, or perhaps it will help. Maybe we
are heading towards a fix.

AudioIO::AudioIO() sets mListener = NULL; which makes it OK to start
the meters in the first Project, since StartMonitoring calls
StartPortAudioStream which has if(mListener) before the line that
causes the crash, causing it to miss that line.

When you start the second project, it comes with it's own
AudioIOListener which isn't initialised (and I think that's the
problem, but please read on) and for some reason it's pointing to the
one in the first project, so the crash line runs successfully, even
though it's referring to the wrong project (???). Feel free to pick
me up here on 'general ignorance' but it looks like it's 'working by
accident' here.

When you start and stop recording in the first project, mListener get
set correctly by AudioIO::StartStream, (li886 mListener = listener;),
but in the second project mListener is still following that (again for
reasons I don't understand).

Then you delete the first project(including the mListener, leaving the
second project's mListener pointing at garbage.

The only other thing that sets mListener in the second project would
be a call to StartStream, and that doesn't happen when you start the
meters (AudioIO::StartMonitoring calls StartPortAudioStream), so kaboom!

So I figured that we need to initialise AudioIOListener* in 'class
AudioIO' in AudioIO.h but that just causes me an error I don't
understand 'only static const integral data members can be initialized
within a class'.

Does this help? Can you see what we have to do to fix this?

TTFN
Martyn

Dawson Written wrote:

> That is what's happening. Right at line 1643 in src/Project.cpp
> (currently rev 1.377), the code, gAudacityProjects.Remove(this), deletes
> the AudacityProject (AudioIOListener) object and when clicking on the
> recording meter, Meter::StartMonitoring and in turn
> AudioIO::StartMonitoring gets the gAudioIO->mListener still pointing to
> the deleted object. In the debugger, if I change it to match the value
> gActiveProject either after src/Project.cpp:1653 or just around
> Meter::StartMonitoring, it will continue without crashing.
> Unfortunately, mListener is private and cannot be changed that way in
> Project.cpp and at Meter::StartMonitoring, that would probably be to
> deep to consistently check the pointers there. This one looks like a
> tough nut to crack.
>
> Hope that was new light to shed on this,
> Dawson
>
> Martyn Shaw wrote:
>> This looks to be well out of my area, maybe Leland can help? A
>> problem with mListener getting deleted / pointing to the wrong place
>> when the first window gets closed? 0xfeeefeee looks suspicious to me.
>> I don't think I can get much further here.
>>
>> HTH
>> Martyn
>>
>> Gale Andrews wrote:
>>> | From Martyn Shaw <martynshaw99@...> | Wed, 24 Sep 2008
>>> 01:18:21 +0100
>>> | Subject: [Audacity-devel] Crash on starting monitoring in Meter
>>> Toolbar...
>>>> ...after recording in another project window then closing it.
>>>>
>>>> Please send reference to details, not reproduced here at the moment.
>>> 1 Launch Audacity
>>> 2 R to start recording 3 Spacebar to stop recording 4 File > New
>>> 5 Task switch back to the first project
>>> 6 File > Close and don't save changes
>>> 7 In the remaining project window, click the Recording Meter
>>> to start monitoring 8 Produces Visual C++ Runtime Error R6025 -
>>> "pure virtual function call"
>>>
>>> Steps 4 and 5 not needed if you have Audacity set in Preferences not
>>> to quit on closing last window.
>>>
>>>
>>> Gale
>>>
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------------------------
>>>
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win
>>> great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> audacity-devel mailing list
>>> audacity-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> audacity-devel mailing list
>> audacity-devel@...
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

Dawson Written

Re: Crash on starting monitoring in Meter Toolbar...

Reply Threaded

Martyn Shaw wrote:
> Hi there Dawson
>
> Useful thoughts there Dawson. If you can make it through this post, it
> may help us to fix this (or maybe not! ;-) ).
>
> I had another look and what you say is true. Perhaps the following will
> just show my ignorance of OOP, or perhaps it will help. Maybe we are
> heading towards a fix.

The ignorance would be mine.... I am pretty much a C programmer trying
to get a grip on C++ and OOP. Believe me, you are way ahead of me.

>
> AudioIO::AudioIO() sets mListener = NULL; which makes it OK to start the
> meters in the first Project, since StartMonitoring calls
> StartPortAudioStream which has if(mListener) before the line that causes
> the crash, causing it to miss that line.
>
> When you start the second project, it comes with it's own
> AudioIOListener which isn't initialised (and I think that's the problem,
> but please read on) and for some reason it's pointing to the one in the
> first project, so the crash line runs successfully, even though it's
> referring to the wrong project (???). Feel free to pick me up here on
> 'general ignorance' but it looks like it's 'working by accident' here.
>

You are right and I know what you mean. When I was stepping through the
code, I could cast the pointer in gAudioIO back to an AudacityApp one
and it matched the one that was deleted. Of course, even code that
checks for NULL could only let that pointer pass through as if it is
valid. When I assigned the value of the new AudacityApp pointer casted
to an AudioIOListener one, the program continued. It would seem at that
point where the AudacityApp gets deleted, a call to a method could
invalidate it as a valid AudioIOListener and another call could be made
to make the replacing one an active AudioIOListener. Otherwise, classes
would have to have others as friends, or exceptions would have to be
thrown and caught.

> When you start and stop recording in the first project, mListener get
> set correctly by AudioIO::StartStream, (li886 mListener = listener;),
> but in the second project mListener is still following that (again for
> reasons I don't understand).
>
Something to look into.

> Then you delete the first project(including the mListener, leaving the
> second project's mListener pointing at garbage.
>
> The only other thing that sets mListener in the second project would be
> a call to StartStream, and that doesn't happen when you start the meters
> (AudioIO::StartMonitoring calls StartPortAudioStream), so kaboom!
>
Yep, same here.

> So I figured that we need to initialise AudioIOListener* in 'class
> AudioIO' in AudioIO.h but that just causes me an error I don't
> understand 'only static const integral data members can be initialized
> within a class'.
>

This was one of those things a while back that threw me, too.

It's because you need to initialize the pointer on an object-by-object
basis, through AudioIO's constructor.

The compiler was thinking you wanted it to be constant for, not any
object, but for the class itself and the only way that would work is if
it was static. It would be the same value for all objects. As a matter
of fact, you can use the static constants even before you even create
your first object of the class. It is like an ordinary constant, but
it's in the namespace of the class.
You would use it like this: avalue = ClassName::ConstValue;
This is probably not what you wanted in this case.

> Does this help? Can you see what we have to do to fix this?
You confirmed some of my fears. When I said this will be a tough nut to
crack, I was thinking of the scenario you just described. I wasn't sure
whether to or not call any methods to prepare the pointer when switching
to it or if methods would need to be called on the old one to release it
resources. But if you were just switching back and forth, you wouldn't
want to get totally rid of it. If a user did quit a project and didn't
want to save it, would calling the methods unfortunately commit the
changes or not. I'm not sure what would be harmful or harmless at this
point. Hope that made sense. I would definitely need some more time
with the code, that's for sure! This is a P1 issue, with a capital P.
But I feel you are onto something and in the right direction for fixing
this.

Wish I could be more help,
Dawson

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
audacity-devel mailing list
audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Martyn Shaw-2

Re: Crash on starting monitoring in Meter Toolbar...

Reply Threaded

I have an idea here (see below), but I've looked at the history of
this and I'm nervous about making changes to code that others have
more expertise in. I'm going to wait a few days for their input
before making any changes (and I have visitors this weekend).

Dawson Written wrote:

> Martyn Shaw wrote:
>> Hi there Dawson
>>
>> Useful thoughts there Dawson. If you can make it through this post,
>> it may help us to fix this (or maybe not! ;-) ).
>>
>> I had another look and what you say is true. Perhaps the following
>> will just show my ignorance of OOP, or perhaps it will help. Maybe we
>> are heading towards a fix.
>
> The ignorance would be mine.... I am pretty much a C programmer trying
> to get a grip on C++ and OOP. Believe me, you are way ahead of me.
>
>>
>> AudioIO::AudioIO() sets mListener = NULL; which makes it OK to start
>> the meters in the first Project, since StartMonitoring calls
>> StartPortAudioStream which has if(mListener) before the line that
>> causes the crash, causing it to miss that line.
>>
>> When you start the second project, it comes with it's own
>> AudioIOListener which isn't initialised (and I think that's the
>> problem, but please read on) and for some reason it's pointing to the
>> one in the first project, so the crash line runs successfully, even
>> though it's referring to the wrong project (???). Feel free to pick
>> me up here on 'general ignorance' but it looks like it's 'working by
>> accident' here.
>>
> You are right and I know what you mean. When I was stepping through the
> code, I could cast the pointer in gAudioIO back to an AudacityApp one
> and it matched the one that was deleted. Of course, even code that
> checks for NULL could only let that pointer pass through as if it is
> valid. When I assigned the value of the new AudacityApp pointer casted
> to an AudioIOListener one, the program continued.

OK, so why don't we just initialise the AudioIOListener with a call in
AudacityProject *CreateNewAudacityProject(wxWindow * parentWindow) thus:
@@ -374,6 +374,9 @@
if(bMaximized)
p->Maximize(true);

+ //Initialise the Listener
+ gAudioIO->SetListener(p);
+
//Set the new project as active:
SetActiveProject(p);

and in AudioIO.cpp have

void AudioIO::SetListener(AudioIOListener* listener)
{
mListener = listener;
}

(and appropriate in AudioIO.h) so that we avoid all the problems? It
seems to work here. Or have I missed something? Should there ever be
a case where we have a project with mListener set to NULL?

If this is OK, I guess we don't need
mListener = listener;
in AudioIO::StartStream and various
if (mListener
clauses elsewhere?

HTH
Martyn

It would seem at that

> point where the AudacityApp gets deleted, a call to a method could
> invalidate it as a valid AudioIOListener and another call could be made
> to make the replacing one an active AudioIOListener. Otherwise, classes
> would have to have others as friends, or exceptions would have to be
> thrown and caught.
>
>
>> When you start and stop recording in the first project, mListener get
>> set correctly by AudioIO::StartStream, (li886 mListener = listener;),
>> but in the second project mListener is still following that (again for
>> reasons I don't understand).
>>
> Something to look into.
>
>> Then you delete the first project(including the mListener, leaving the
>> second project's mListener pointing at garbage.
>>
>> The only other thing that sets mListener in the second project would
>> be a call to StartStream, and that doesn't happen when you start the
>> meters (AudioIO::StartMonitoring calls StartPortAudioStream), so kaboom!
>>
> Yep, same here.
>
>> So I figured that we need to initialise AudioIOListener* in 'class
>> AudioIO' in AudioIO.h but that just causes me an error I don't
>> understand 'only static const integral data members can be initialized
>> within a class'.
>>
>
> This was one of those things a while back that threw me, too.
>
> It's because you need to initialize the pointer on an object-by-object
> basis, through AudioIO's constructor.
>
> The compiler was thinking you wanted it to be constant for, not any
> object, but for the class itself and the only way that would work is if
> it was static. It would be the same value for all objects. As a matter
> of fact, you can use the static constants even before you even create
> your first object of the class. It is like an ordinary constant, but
> it's in the namespace of the class.
> You would use it like this: avalue = ClassName::ConstValue;
> This is probably not what you wanted in this case.
>
>> Does this help? Can you see what we have to do to fix this?
> You confirmed some of my fears. When I said this will be a tough nut to
> crack, I was thinking of the scenario you just described. I wasn't sure
> whether to or not call any methods to prepare the pointer when switching
> to it or if methods would need to be called on the old one to release it
> resources. But if you were just switching back and forth, you wouldn't
> want to get totally rid of it. If a user did quit a project and didn't
> want to save it, would calling the methods unfortunately commit the
> changes or not. I'm not sure what would be harmful or harmless at this
> point. Hope that made sense. I would definitely need some more time
> with the code, that's for sure! This is a P1 issue, with a capital P.
> But I feel you are onto something and in the right direction for fixing
> this.
>
> Wish I could be more help,
> Dawson
>

Martyn Shaw-2

Re: Crash on starting monitoring in Meter Toolbar...

Reply Threaded

I take it that no response on this thread means that nobody has had
time to look into this, rather than 'this is a great idea Martyn, just
commit it' (and I did find it a bit hard-core). So I don't intend to
commit this soon (ie before the next release). I'll keep it on file
and commit it afterwards and then we'll see.

TTFN
Martyn

Martyn Shaw wrote:

> I have an idea here (see below), but I've looked at the history of this
> and I'm nervous about making changes to code that others have more
> expertise in. I'm going to wait a few days for their input before
> making any changes (and I have visitors this weekend).
>
> Dawson Written wrote:
>> Martyn Shaw wrote:
>>> Hi there Dawson
>>>
>>> Useful thoughts there Dawson. If you can make it through this post,
>>> it may help us to fix this (or maybe not! ;-) ).
>>>
>>> I had another look and what you say is true. Perhaps the following
>>> will just show my ignorance of OOP, or perhaps it will help. Maybe
>>> we are heading towards a fix.
>>
>> The ignorance would be mine.... I am pretty much a C programmer trying
>> to get a grip on C++ and OOP. Believe me, you are way ahead of me.
>>
>>>
>>> AudioIO::AudioIO() sets mListener = NULL; which makes it OK to start
>>> the meters in the first Project, since StartMonitoring calls
>>> StartPortAudioStream which has if(mListener) before the line that
>>> causes the crash, causing it to miss that line.
>>>
>>> When you start the second project, it comes with it's own
>>> AudioIOListener which isn't initialised (and I think that's the
>>> problem, but please read on) and for some reason it's pointing to the
>>> one in the first project, so the crash line runs successfully, even
>>> though it's referring to the wrong project (???). Feel free to pick
>>> me up here on 'general ignorance' but it looks like it's 'working by
>>> accident' here.
>>>
>> You are right and I know what you mean. When I was stepping through
>> the code, I could cast the pointer in gAudioIO back to an AudacityApp
>> one and it matched the one that was deleted. Of course, even code
>> that checks for NULL could only let that pointer pass through as if it
>> is valid. When I assigned the value of the new AudacityApp pointer
>> casted to an AudioIOListener one, the program continued.
>
> OK, so why don't we just initialise the AudioIOListener with a call in
> AudacityProject *CreateNewAudacityProject(wxWindow * parentWindow) thus:
> @@ -374,6 +374,9 @@
> if(bMaximized)
> p->Maximize(true);
>
> + //Initialise the Listener
> + gAudioIO->SetListener(p);
> +
> //Set the new project as active:
> SetActiveProject(p);
>
> and in AudioIO.cpp have
>
> void AudioIO::SetListener(AudioIOListener* listener)
> {
> mListener = listener;
> }
>
> (and appropriate in AudioIO.h) so that we avoid all the problems? It
> seems to work here. Or have I missed something? Should there ever be a
> case where we have a project with mListener set to NULL?
>
> If this is OK, I guess we don't need
> mListener = listener;
> in AudioIO::StartStream and various
> if (mListener
> clauses elsewhere?
>
> HTH
> Martyn
>
> It would seem at that
>> point where the AudacityApp gets deleted, a call to a method could
>> invalidate it as a valid AudioIOListener and another call could be
>> made to make the replacing one an active AudioIOListener. Otherwise,
>> classes would have to have others as friends, or exceptions would have
>> to be thrown and caught.
>>
>>
>>> When you start and stop recording in the first project, mListener get
>>> set correctly by AudioIO::StartStream, (li886 mListener = listener;),
>>> but in the second project mListener is still following that (again
>>> for reasons I don't understand).
>>>
>> Something to look into.
>>
>>> Then you delete the first project(including the mListener, leaving
>>> the second project's mListener pointing at garbage.
>>>
>>> The only other thing that sets mListener in the second project would
>>> be a call to StartStream, and that doesn't happen when you start the
>>> meters (AudioIO::StartMonitoring calls StartPortAudioStream), so kaboom!
>>>
>> Yep, same here.
>>
>>> So I figured that we need to initialise AudioIOListener* in 'class
>>> AudioIO' in AudioIO.h but that just causes me an error I don't
>>> understand 'only static const integral data members can be
>>> initialized within a class'.
>>>
>>
>> This was one of those things a while back that threw me, too.
>>
>> It's because you need to initialize the pointer on an object-by-object
>> basis, through AudioIO's constructor.
>>
>> The compiler was thinking you wanted it to be constant for, not any
>> object, but for the class itself and the only way that would work is
>> if it was static. It would be the same value for all objects. As a
>> matter of fact, you can use the static constants even before you even
>> create your first object of the class. It is like an ordinary
>> constant, but it's in the namespace of the class.
>> You would use it like this: avalue = ClassName::ConstValue;
>> This is probably not what you wanted in this case.
>>
>>> Does this help? Can you see what we have to do to fix this?
>> You confirmed some of my fears. When I said this will be a tough nut
>> to crack, I was thinking of the scenario you just described. I wasn't
>> sure whether to or not call any methods to prepare the pointer when
>> switching to it or if methods would need to be called on the old one
>> to release it resources. But if you were just switching back and
>> forth, you wouldn't want to get totally rid of it. If a user did quit
>> a project and didn't want to save it, would calling the methods
>> unfortunately commit the changes or not. I'm not sure what would be
>> harmful or harmless at this point. Hope that made sense. I would
>> definitely need some more time with the code, that's for sure! This
>> is a P1 issue, with a capital P. But I feel you are onto something and
>> in the right direction for fixing this.
>>
>> Wish I could be more help,
>> Dawson
>>
>

Gale (Audacity Team)

Re: Crash on starting monitoring in Meter Toolbar...

Reply Threaded

Martyn Shaw-2 wrote:

I take it that no response on this thread means that nobody has had
time to look into this, rather than 'this is a great idea Martyn, just
commit it' (and I did find it a bit hard-core). So I don't intend to
commit this soon (ie before the next release). I'll keep it on file
and commit it afterwards and then we'll see.

Martyn,

Your change "Initialise the mListener of each project as it's created" fixes this
for me on Win XP, and I have not come across any unwanted side effects so
far. So I'll call this "fixed" in a few days unless someone comes across
problems on another platform.

Thanks

Gale