I'm giving this another try, with another patch. https://treeherder.mozilla.org/#/jobs?repo=try&revision=2daf38e8178fadd14981ac441a73570fc4025837 This time, rather than trying to anticipate when this bug is going to happen, I detect it after it happened. Rather than trying to figure out when CVCGDisplayLink::setCurrentDisplay() is going to leave an internal pointer uninitialized (nulled), I check for it after the fact. I can't access the null pointer directly. But fortunately, when CVCGDisplayLink::setCurrentDisplay() triggers this bug (thanks to get_current_display_system_state() returning null and CGDisplayIDToOpenGLDisplayMask() returning 0), it also leaves the "current display" internal variable uninitialized (zeroed). This I *can* access, using the documented CVDisplayLinkGetCurrentCGDisplay() method. As best I can tell, the reason my previous patch worked so poorly is that the condition(s) that cause get_current_display_system_state() to return null last only for a very brief time -- so brief that the very next call to get_current_display_system_state() might not return null. The same applies in reverse -- that a given call to get_current_display_system_state() doesn't return null doesn't mean that the next call won't do so. I'm going to wait for my try build and its tests to finish. Then tomorrow I'll ask Stephen Pohl for a review. I'd ask Markus Stange, but I see from bug 1578975 comment #12 I see that he's going on PTO tomorrow.
Bug 1201401 Comment 158 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I'm giving this another try, with another patch. https://treeherder.mozilla.org/#/jobs?repo=try&revision=2daf38e8178fadd14981ac441a73570fc4025837 This time, rather than trying to anticipate when this bug is going to happen, I detect it after it happened. Rather than trying to figure out when CVCGDisplayLink::setCurrentDisplay() is going to leave an internal pointer uninitialized (nulled), I check for it after the fact. I can't access the null pointer directly. But fortunately, when CVCGDisplayLink::setCurrentDisplay() triggers this bug (thanks to get_current_display_system_state() returning null and CGDisplayIDToOpenGLDisplayMask() returning 0), it also leaves the "current display" internal variable uninitialized (zeroed). This I *can* access, using the documented CVDisplayLinkGetCurrentCGDisplay() method. As best I can tell, the reason my previous patch worked so poorly is that the condition(s) that cause get_current_display_system_state() to return null can change very quickly, from one call to the next. Given two consecutive calls to this function, there seems to be about a 50/50 chance that the first will return null and the second not, or vice versa. I'm going to wait for my try build and its tests to finish. Then tomorrow I'll ask Stephen Pohl for a review. I'd ask Markus Stange, but I see from bug 1578975 comment #12 I see that he's going on PTO tomorrow.
I'm giving this another try, with another patch. https://treeherder.mozilla.org/#/jobs?repo=try&revision=2daf38e8178fadd14981ac441a73570fc4025837 This time, rather than trying to anticipate when this bug is going to happen, I detect it after it happened. Rather than trying to figure out when CVCGDisplayLink::setCurrentDisplay() is going to leave an internal pointer uninitialized (nulled), I check for it after the fact. I can't access the null pointer directly. But fortunately, when CVCGDisplayLink::setCurrentDisplay() triggers this bug (thanks to get_current_display_system_state() returning null and CGDisplayIDToOpenGLDisplayMask() returning 0), it also leaves the "current display" internal variable uninitialized (zeroed). This I *can* access, using the documented CVDisplayLinkGetCurrentCGDisplay() method. As best I can tell, the reason my previous patch worked so poorly is that the condition(s) that cause get_current_display_system_state() to return null can change very quickly, from one call to the next. Given two consecutive calls to this function, there seems to be about a 50/50 chance that the first will return null and the second not, or vice versa (that is if the general conditions for this bug prevail, whatever they are). I'm going to wait for my try build and its tests to finish. Then tomorrow I'll ask Stephen Pohl for a review. I'd ask Markus Stange, but I see from bug 1578975 comment #12 I see that he's going on PTO tomorrow.
I'm giving this another try, with another patch. https://treeherder.mozilla.org/#/jobs?repo=try&revision=2daf38e8178fadd14981ac441a73570fc4025837 This time, rather than trying to anticipate when this bug is going to happen, I detect it after it happened. Rather than trying to figure out when CVCGDisplayLink::setCurrentDisplay() is going to leave an internal pointer uninitialized (nulled), I check for it after the fact. I can't access the null pointer directly. But fortunately, when CVCGDisplayLink::setCurrentDisplay() triggers this bug (thanks to get_current_display_system_state() returning null and CGDisplayIDToOpenGLDisplayMask() returning 0), it also leaves the "current display" internal variable uninitialized (zeroed). This I *can* access, using the documented CVDisplayLinkGetCurrentCGDisplay() method. As best I can tell, the reason my previous patch worked so poorly is that the condition(s) that cause get_current_display_system_state() to return null can change very quickly, from one call to the next. Given two consecutive calls to this function, there seems to be about a 50/50 chance that the first will return null and the second not, or vice versa (that is if the general conditions for this bug prevail, whatever they are). I'm going to wait for my try build and its tests to finish. Then tomorrow I'll ask Stephen Pohl for a review. I'd ask Markus Stange, but I see from bug 1578075 comment #12 I see that he's going on PTO tomorrow.
I'm giving this another try, with another patch. https://treeherder.mozilla.org/#/jobs?repo=try&revision=2daf38e8178fadd14981ac441a73570fc4025837 This time, rather than trying to anticipate when this bug is going to happen, I detect it after it happened. Rather than trying to figure out when CVCGDisplayLink::setCurrentDisplay() is going to leave an internal pointer uninitialized (nulled), I check for it after the fact. I can't access the null pointer directly. But fortunately, when CVCGDisplayLink::setCurrentDisplay() triggers this bug (thanks to get_current_display_system_state() returning null and CGDisplayIDToOpenGLDisplayMask() returning 0), it also leaves the "current display" internal variable uninitialized (zeroed). This I *can* access, using the documented CVDisplayLinkGetCurrentCGDisplay() method. As best I can tell, the reason my previous patch worked so poorly is that the condition(s) that cause get_current_display_system_state() to return null can change very quickly, from one call to the next. Given two consecutive calls to this function, there seems to be about a 50/50 chance that the first will return null and the second not, or vice versa (that is if the general conditions for this bug prevail, whatever they are). I'm going to wait for my try build and its tests to finish. Then tomorrow I'll ask Stephen Pohl for a review. I'd ask Markus Stange again, but I see from bug 1578075 comment #12 I see that he's going on PTO tomorrow.