Closed Bug 795892 Opened 7 years ago Closed 7 years ago

Playing video causes reproducible crash in nsCOMPtr_base::assign_with_AddRef

Categories

(Core :: Audio/Video, defect, critical)

18 Branch
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla18

People

(Reporter: BenWa, Assigned: kinetik)

References

Details

(Keywords: crash, regression, reproducible)

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is 
report bp-691616c5-4123-4688-9f17-41c4f2121001 .
============================================================= 

I also get at least one other signature:
bp-667bdd46-3bc0-430f-8740-a68262121001

STR:
0) On mac at least with the 2012-09-30 nightly.
1) Open page: http://people.mozilla.com/~bgirard/cleopatra/?zippedProfile=profiles/sps-profile-1348512228.12.zip&videoCapture=videos/video-1348512228.11.webm
2) After loading click play on the video element.
Crash Signature: [@ nsCOMPtr_base::assign_with_AddRef | mozilla::net::nsHttpChannel::AsyncOpen] → [@ nsCOMPtr_base::assign_with_AddRef | mozilla::net::nsHttpChannel::AsyncOpen] [@ mozilla::net::HttpBaseChannel::GetNotificationCallbacks ]
Without step 2, I hit bug 789075 on Windows in 15.0.1 and above.
I'm bisecting this now.
Well, that change surfaced the bug, but it's not the cause.  The real cause is pretty dumb:

605       nsCORSListenerProxy* crossSiteListener =
606         new nsCORSListenerProxy(mListener,
607                                 element->NodePrincipal(),
608                                 false);
609       nsresult rv = crossSiteListener->Init(mChannel);

...it's a shame the compiler can't catch this.
Assignee: nobody → kinetik
Status: NEW → ASSIGNED
Attached patch patch v0Splinter Review
Attachment #666850 - Flags: review?(roc)
Version: unspecified → 18 Branch
Oops!  Thanks Matthew for the quick fix.
Thanks :)
I pushed this since I feel pretty bad for making this mistake, and wanted to take some responsibility.  :-)

https://hg.mozilla.org/integration/mozilla-inbound/rev/9a73d985e5e9
Don't feel bad, it wasn't your mistake.  This has been hiding in our code waiting to bite someone for a long time.  Thanks for pushing the fix!
https://hg.mozilla.org/mozilla-central/rev/9a73d985e5e9

Should this have a crashtest?
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
Pardon my question, but the test link in Cleopatra still crashes the browser.  

tested using the latest hourly build with this patch.  crash-report will not be of use because of no-symbols in hourly builds. 

If this was supposed to fix the crash it does not seem to be fixed.
Isn't this a dupe of bug 789075 ? which still remains un-fixed ?
(In reply to comment #11)
> Pardon my question, but the test link in Cleopatra still crashes the browser.  
> 
> tested using the latest hourly build with this patch.  crash-report will not be
> of use because of no-symbols in hourly builds. 
> 
> If this was supposed to fix the crash it does not seem to be fixed.
> Isn't this a dupe of bug 789075 ? which still remains un-fixed ?

You're probably seeing the crash in bug 789075, which is still not fixed.
Blocks: 795750
(In reply to Ryan VanderMeulen from comment #10)
> Should this have a crashtest?

https://hg.mozilla.org/integration/mozilla-inbound/rev/0efeec87af33
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.