Closed Bug 819275 Opened 9 years ago Closed 9 years ago

[Audio] The Usage of nsRefPtr for AudioChannelService is Wrong

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-basecamp:+, firefox18 fixed, firefox19 fixed, firefox20 fixed, b2g18 fixed)

RESOLVED FIXED
B2G C2 (20nov-10dec)
blocking-basecamp +
Tracking Status
firefox18 --- fixed
firefox19 --- fixed
firefox20 --- fixed
b2g18 --- fixed

People

(Reporter: mchen, Assigned: mchen)

References

Details

Attachments

(1 file, 3 obsolete files)

AudioChannelAgent tried to use a global nsRefPtr called Foo for AudioChannelService. In each constructors of AudioChannelAgent, the global Foo get AudioChannelService once. And global Foo will be assigned nullptr at each deconstructor. So once 10 instances of AudioChannelAgent are created (actually Foo's ref is only 2, one from AudioChannelService and one from global Foo), the second leave one will clear global Foo. Then following instances will be died while using it.
Attached patch Patch v1 (obsolete) — Splinter Review
Attached patch Patch v1 (obsolete) — Splinter Review
Attachment #689636 - Attachment is obsolete: true
Comment on attachment 689648 [details] [diff] [review]
Patch v1

Dear Robert,

Sorry for this mistake. And fix it right away.
Attachment #689648 - Flags: review?(roc)
The side effect from Bug 815069 and it should be fixed.
blocking-basecamp: --- → ?
Comment on attachment 689648 [details] [diff] [review]
Patch v1

Review of attachment 689648 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/audiochannel/AudioChannelAgent.cpp
@@ +63,5 @@
>  
>  /* boolean startPlaying (); */
>  NS_IMETHODIMP AudioChannelAgent::StartPlaying(bool *_retval)
>  {
> +  nsRefPtr<AudioChannelService> service = AudioChannelService::GetAudioChannelService();

You actually don't need to use refptrs here. We can assume/ensure that the service does not go away while an AudioChannelAgent method is running. GetAudioChannelService can return a raw AudioChannelService* pointer and we can use that type for our local variables.
Attached patch Patch v2 (obsolete) — Splinter Review
Attachment #689648 - Attachment is obsolete: true
Attachment #689648 - Flags: review?(roc)
Attachment #689651 - Flags: review?(roc)
Thanks for this quickly review and response. Follow the comment on the patch.
Attachment #689651 - Attachment is obsolete: true
Attachment #689659 - Flags: review+
Dear Robert,

Thanks.

Dear Jonas,

Please help to judge the bb?. Very thanks for your help.
Flags: needinfo?(jonas)
blocking-basecamp: ? → +
Flags: needinfo?(jonas)
Keywords: checkin-needed
Blocks: 819500
Blocks: 819823
Duplicate of this bug: 819864
https://hg.mozilla.org/mozilla-central/rev/2224b34281aa
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Duplicate of this bug: 820068
Duplicate of this bug: 820069
Whiteboard: [status-b2g18:fixed]
Whiteboard: [status-b2g18:fixed]
Hi Marco,

I am guessing this issue might be related to Bug 821222.

In Bug 821222, the way to reproduce it will cause the audio element set to a new source many times, can you please see if this patch should solve Bug 821222 or it's another issue? thanks.
FYI, please don't use |static nsRefPtr| instances.  They create static constructors / destructors, which make Firefox start up slower.

Instead, use |static StaticRefPtr|.
(In reply to Justin Lebar [:jlebar] from comment #18)
> FYI, please don't use |static nsRefPtr| instances.  They create static
> constructors / destructors, which make Firefox start up slower.
> 
> Instead, use |static StaticRefPtr|.

Hi Justin,

Thanks for your information here.
You need to log in before you can comment on or make changes to this bug.