Closed Bug 839599 Opened 12 years ago Closed 12 years ago

Creating an instance of mozRTCPeerConnection() fails and leaves a zombie process behind

Categories

(Core :: WebRTC, defect)

Product:
Core
Component:
WebRTC
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 842749

People

(Reporter: whimboo, Unassigned)

References

(
URL
)

Details

(Whiteboard: [WebRTC][blocking-webrtc-])

So while I was trying to investigate bug 837026 and bug 833557 on my new Win7 64bit box I hit a new problem which might be similar. It sounds a lot like bug 837026 but that one we never hit on Windows. So lets handle it separately. Steps: 1. Enable peer connections via about:config 2. Start a usual Firefox Nightly build 3. Open http://mozilla.github.com/webrtc-landing/pc_test.html 4. Click on the start button After step 4 you will never see the demo working. Also there is no failure visible in the error console. The code in the demo seems to hang in the creation of the new mozRTCPeerConnection instance. When you close the browser it will visually disappear but a zombie process is left behind. So you will not be able to reuse the same profile until you have killed the process via the task manager. This seems fairly critical to me. I just wonder how many people could be affected by this issue, and if that's limited to Win7 64bit?
I can see this in Nightly, Aurora, and the latest Firefox 19.0 beta. So nothing points to a regression here.
So as given by Phil we do not run tests on Win7 64 on buildbot. That would explain why we do not have failing tests reported on tbpl. So I feel that this bug is most likely the same as bug 837026. Can we keep it separate so we are not getting spammed with all those tinderbox comments? I would mark a dependency.
Blocks: 837026
Works fine on my Win 7 64-bit machine on a nightly build.
Perhaps related to the particular camera or audio driver?
Whiteboard: [WebRTC][blocking-webrtc?] → [WebRTC][blocking-webrtc-]
Randell, there is no gUM involved here. So how can the drivers of audio and video can cause trouble? Steps: 1. Start nightly build and enable peer connections 2. Open Error Console 3. Execute: 'new mozRTCPeerConnection()' 4. Quit Firefox
Does [blocking-webrtc-] mean that nobody involved with WebRTC will take a look at this issue? Are we confident this won't impact a good portion of users? If this is in fact a driver issue, we should still understand it and consider noting it as a known issue in the release notes.
(In reply to Alex Keybl [:akeybl] from comment #6) > Does [blocking-webrtc-] mean that nobody involved with WebRTC will take a > look at this issue? Are we confident this won't impact a good portion of > users? blocking-webrtc- implies we won't stop ship on this bug for the first release of WebRTC on desktop. Typically it means lower priority in comparison to blockers, although there might be engineers that might work on the bug. Nobody has managed to confirm this issue on a different machine, so we haven't confirmed that this will impact a large amount of users. > > If this is in fact a driver issue, we should still understand it and > consider noting it as a known issue in the release notes. True. I think that's something I might want to bring up in the WebRTC weekly meeting about how we're noting known issues, including driver-specific issues.
tracking-firefox21: ? → ---
Note - I did try testing this per comment 3 on my machine and couldn't reproduce with my webcams I've got (one integrated and one USB). So we know it isn't a global issue.
(In reply to Henrik Skupin (:whimboo) [away 02/09 - 02/017] from comment #5) > Randell, there is no gUM involved here. So how can the drivers of audio and > video can cause trouble? > > Steps: > 1. Start nightly build and enable peer connections > 2. Open Error Console > 3. Execute: 'new mozRTCPeerConnection()' > 4. Quit Firefox That doesn't match the report earlier: > Steps: > 1. Enable peer connections via about:config > 2. Start a usual Firefox Nightly build > 3. Open http://mozilla.github.com/webrtc-landing/pc_test.html > 4. Click on the start button pc_test.html uses GUM, fake streams, PeerConnections, ICE, etc - it's a full call to yourself. Which is the actual failure case? Is this Win7 64bit with a normal 32-bit nightly/etc? (I assume) or is it a 64-bit mozilla (which is not currently fully supported on windows)? I (and many others) test WebRTC/gUM on Win7 64-bit every day. I assume the Win/WinDbg mochitests run on Win7 x64, since that seems the norm. If it *doesn't* involve GUM: please run with NSPR_LOG_MODULES=signaling:5,mtransport:5 Assuming it *does* involve gUM: Can you report the machine, camera and mic devices, and drivers for each? And check for updates? Can you run with NSPR_LOG_MODULES mediamanager:5, and maybe mediamanager:5,getusermedia:5,webrtc_trace:65535 and set WEBRTC_TRACE_FILE to some file (it's saved separately from NSPR logging)
(In reply to Alex Keybl [:akeybl] from comment #6) > Does [blocking-webrtc-] mean that nobody involved with WebRTC will take a > look at this issue? Are we confident this won't impact a good portion of > users? As mentioned, that means we don't believe this rises to be a release issue. "blocking-webrtc+" issues are ones we'd consider blocking a release to production (at least at the moment; often they're given + or - based on the initial report before analysis; later information may change that assessment). This is an internal group classification method; blocking- bugs get worked on and fixed all the time, but generally they're lower priority than blocking+ bugs. Given many of us use WebRTC on Win7 x64 every day, we don't believe it's a general problem, and at this point there's insufficient evidence that anyone else has been or would be affected by it. Once we have more info, we can analyze and re-assess. > If this is in fact a driver issue, we should still understand it and > consider noting it as a known issue in the release notes. If you mean hardware driver, we certainly will release-note any known HW driver issues; we expect to have some but have not yet found any definite ones that we haven't solved in the software.
(In reply to Randell Jesup [:jesup] from comment #9) > > Steps: > > 1. Start nightly build and enable peer connections > > 2. Open Error Console > > 3. Execute: 'new mozRTCPeerConnection()' > > 4. Quit Firefox > > That doesn't match the report earlier: What do you mean? It's just the minimized testcase compared to comment 0 and it reproduces the problem all the time. I know that Tim also has a Lenovo laptop, so it would be great if we could get feedback from him if he can see the same. > Is this Win7 64bit with a normal 32-bit nightly/etc? (I assume) or is it a That's correct. It's a 32bit build of Firefox. > I (and many others) test WebRTC/gUM on Win7 64-bit every day. I assume the > Win/WinDbg mochitests run on Win7 x64, since that seems the norm. No, we don't run any tests on a 64bit platform on buildbot. So we don't have any results from that location. > If it *doesn't* involve GUM: > > please run with NSPR_LOG_MODULES=signaling:5,mtransport:5 I will try that. > Can you report the machine, camera and mic devices, and drivers for each? > And check for updates? It's a Lenovo X230 (http://www.lenovo.com/products/us/laptop/thinkpad/x-series/x230/) with the latest drivers installed as supplied by Lenovo. > Can you run with NSPR_LOG_MODULES mediamanager:5, and maybe > mediamanager:5,getusermedia:5,webrtc_trace:65535 and set WEBRTC_TRACE_FILE > to some file (it's saved separately from NSPR logging) I will do.
Flags: needinfo?(ttaubert)
(In reply to Henrik Skupin (:whimboo) from comment #11) > I know that Tim also has a Lenovo laptop, so it would be great if we could > get feedback from him if he can see the same. I run Ubuntu on my X220 but this bug is about Windows, right? I could at best test this on my W520 with Win 7.
Flags: needinfo?(ttaubert)
(In reply to Tim Taubert [:ttaubert] from comment #12) > I run Ubuntu on my X220 but this bug is about Windows, right? I could at > best test this on my W520 with Win 7. Oh, yes that would be great if it is a 64bit Win7. Thanks Tim!
I tried to reproduce the problem again but without luck. Looks like that one of the restart fixed it. I will keep an eye on it if I can find the way how to make it happen.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
This is probably Bug 842749.
Resolution: INCOMPLETE → DUPLICATE
You need to log in before you can comment on or make changes to this bug.