I don't have a lot of specifics on precisely what causes this yet, other than it happens while using WebRTC code and primarily when using the code I'm testing here for my article on MDN. Whether it's specific to this code or is WebRTC in general I don't know. The article with links to its code is here: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Signaling_and_video_calling Over time, as I use WebRTC, I start to get strange artifacts on the screen. These tend to be blocks a few pixels (or dozens of pixels) high and full width of the screen. They are erased by as window pass across them, but not by the mouse cursor, and they do not show up in screen shots. They pretty clearly contain random memory because sometimes they have recognizable bits of graphic cruft (bits of text or images or icons) or just garbage in them. Sometimes they are static pixels and sometimes they flicker and flash and change over time (presumably when the memory is being altered right in the frame buffer or something along those lines). This doesn't take long to start to happen -- just a couple of minutes is enough for the initial signs to show, and sometimes the Window Server dies very fast, and other times it takes an hour or even several hours. Usually it's more like 45-120 minutes. The project is just doing basic 2-way audio and video; no data channel. Hardware info and screen photos (old school!) to follow but the machine is going downhill and I want this filed.
Here's a video I captured of the flickering artifacts. This is a fairly large one but doesn't have bits of recognizable stuff in it like sometimes happens: https://dl.dropboxusercontent.com/u/364035/FlickeryTrash-WebRTC-Bug1237854.mov
Hardware info about my Mac, since it may be relevant: Hardware Overview: Model Name: Mac mini Model Identifier: Macmini6,2 Processor Name: Intel Core i7 Processor Speed: 2.6 GHz Number of Processors: 1 Total Number of Cores: 4 L2 Cache (per Core): 256 KB L3 Cache: 6 MB Memory: 16 GB Boot ROM Version: MM61.0106.B0A SMC Version (system): 2.8f1 Serial Number (system): C07LJ02NDY3H Hardware UUID: 146BD748-3589-58A4-9C1D-A2836B455044 Intel HD Graphics 4000: Chipset Model: Intel HD Graphics 4000 Type: GPU Bus: Built-In VRAM (Dynamic, Max): 1536 MB Vendor: Intel (0x8086) Device ID: 0x0166 Revision ID: 0x0009
I have to say this looks like a hardware or driver bug - I'm tempted to say hardware; i.e. something specific to your machine - another mac mini with the same software load would not show it. If it's possible to find someone with the same HW (mac mini of same vintage) to run the test that would help a ton. None of the webrtc devs I know of have a mac mini. Perhaps drno will know. I'll try letting it run on my macbook pro
backlog: --- → webrtc/webaudio+
Priority: -- → P2
I'm not aware of any developer using a Mac mini either. But we have for sure a couple in use in the QA lab for different purposes. I'll try to have a look if any of them matches this hardware model. What OS version do you run on yours Eric?
(In reply to Nils Ohlmeier [:drno] from comment #6) > I'm not aware of any developer using a Mac mini either. But we have for sure > a couple in use in the QA lab for different purposes. I'll try to have a > look if any of them matches this hardware model. > > What OS version do you run on yours Eric? Currently on Mac OS X 10.11.3 Beta 1. This issue was happening on 10.11.2 (release) as well; I installed the beta to see if maybe there was a bug fixed in the OS, but the problem was not affected. The problem does seem to grow increasingly worse the more connects/disconnects I do, but it may be about time elapsed in combination or who knows.
I located a Macmini 6,1 in the QA lab which currently does seem to be in use at all. It has at least the same build in graphics card. And most of the spec seems to match your Mac mini. Now the big question is: as we no longer have a central QA group whom to ask if I can use that machine?
So I booted the Mac mini in the QA lab up. It runs 10.8. I went to the demo page at the end of your MDN article. Sheppy do you know if the problem is triggered by a specific version of Firefox (I'm using 45 right now), and do you know if a long lasting call triggers it, or do I have start and stop multiple calls to trigger it?
(In reply to Nils Ohlmeier [:drno] from comment #9) > So I booted the Mac mini in the QA lab up. It runs 10.8. I went to the demo > page at the end of your MDN article. Sheppy do you know if the problem is > triggered by a specific version of Firefox (I'm using 45 right now), and do > you know if a long lasting call triggers it, or do I have start and stop > multiple calls to trigger it? Usually it takes a series of calls, generally short ones do the job (my tests were rarely more than a minute long). I have had the problem occur on multiple versions of Firefox including 42 through 44. I have also had it happen on 45, I'm pretty sure.
So I ran a multi-hour test call followed by several short test calls between two tabs on 44 on the above mentioned Mac mini in the QA lab. No artifacts what so ever :-(
Makes me wonder if it's an OS X 10.11 related thing then. Hm...
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.