Closed Bug 778745 Opened 13 years ago Closed 12 years ago

crash occurs when quitting firefox with a video/audio stream running from MediaStream [@ PR_DestroyCondVar]

Categories

(Core :: WebRTC: Audio/Video, defect, P1)

All
Windows 7
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jsmith, Assigned: jsmith)

Details

(Keywords: crash, crashreportid, testcase, Whiteboard: [getUserMedia], [blocking-gum+])

Crash Data

Attachments

(1 file)

Attached file Basic Video Test
This bug was filed from the Socorro interface and is report bp-cd70bd61-ff6d-42a1-9897-7e6032120730 . ============================================================= Steps: 1. Load the attached test case 2. Quit Firefox Expected: The camera should stop being in use. Firefox process should stop running. No crash should occur. Actual: Firefox crashes on shutdown.
Keywords: reproducible
This is a reproducible crash. Don't see why the keyword is removed here.
Keywords: reproducible
(In reply to Jason Smith [:jsmith] from comment #1) > This is a reproducible crash. Don't see why the keyword is removed here. reproducible is when there's no testcase but manual STR.
(In reply to Scoobidiver from comment #2) > (In reply to Jason Smith [:jsmith] from comment #1) > > This is a reproducible crash. Don't see why the keyword is removed here. > reproducible is when there's no testcase but manual STR. I thought reproducible was used when you can reliably reproduce a crash? Technically, you can reproduce this crash with having any use of getUserMedia with a video and quitting firefox. The test case attached just provides an example.
Summary: crash in PR_DestroyCondVar - occurs when quitting firefox with a video stream running from MediaStream → crash in PR_DestroyCondVar - occurs when quitting firefox with a video/audio stream running from MediaStream
Keywords: reproducible
Whiteboard: [getUserMedia], [blocking-gum+]
Blocks: 801551
We will not be able to test this with any framework we have in the tree, but we can make use of Mozmill to get such a test.
Flags: in-testsuite-
Flags: in-qa-testsuite?(hskupin)
Keywords: crashreportid
Something apparently fixed this bug, cause I can't reproduce this anymore. Don't know what did though...
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
No longer blocks: 801551
Clearing testsuite request and closing as WFM, which should be used if no check-in is known.
Flags: in-qa-testsuite?(hskupin)
Resolution: FIXED → WORKSFORME
(In reply to Henrik Skupin (:whimboo) from comment #6) > Clearing testsuite request and closing as WFM, which should be used if no > check-in is known. Ehh....I still might suggest getting a mozmill test case for this anyways if it's possible. This was consistently reproducible before.
If that's the case, sure that we can have it to proof we don't crash.
Flags: in-qa-testsuite?(hskupin)
Looks like I was wrong. I just reproduced this crash intermittently during shutdown while a gum video was running: https://crash-stats.mozilla.com/report/index/bp-07050638-7bf9-4661-8f32-c22db2121231
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Assignee: nobody → rjesup
Priority: -- → P1
roc - I looked at this, and this looks strongly like we're somehow calling delete on a NULL mGraph/MediaStreamGraphImpl from the MediaStreamGraphShutdownRunnable. It's crashing trying to delete the Monitor, which has a CondVar inside of it. How this happens.... Does this sound like a reasonable analysis from this stack trace? I haven't been able to reproduce this myself, though perhaps I haven't tried enough.
Flags: needinfo?(roc)
Summary: crash in PR_DestroyCondVar - occurs when quitting firefox with a video/audio stream running from MediaStream → crash occurs when quitting firefox with a video/audio stream running from MediaStream [@ PR_DestroyCondVar]
Presumably mGraph is not just null, otherwise "delete mGraph" would do nothing. Would be interesting to have the log from a debug build, to see if any assertions fire leading up to the crash.
Flags: needinfo?(roc)
If anyone sees anything like this after some other cleanup patches land today (bug 827007 and bug 826576), please flag it. No proof they're involved, but it's conceivable.
per comment 12, I think this is now fixed. Marking qawanted
Assignee: rjesup → jsmith
Keywords: qawanted
Can't reproduce on 1/29 build.
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Keywords: qawanted
Resolution: --- → WORKSFORME
Nils, can you please check which kind of test would be good here, or even still necessary? Thanks.
Flags: in-qa-testsuite?(hskupin) → in-qa-testsuite?(drno)
I missed the 'shutdown' part here. So in that case Mozmill would be required. Nils, do you think it is worth creating a test?
Flags: needinfo?(drno)
Flags: in-qa-testsuite?(drno)
Flags: in-qa-testsuite?
Please see https://bugzilla.mozilla.org/show_bug.cgi?id=799142#c54 for my request of writing one Mozmill test to cover these scenarios.
Flags: needinfo?(drno)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: