Would love to know more specifics, but we should take the discussion
of uninitialized memory exposure off of public lists.
On Thu, Jul 6, 2017 at 3:32 PM, Kenneth Russell <firstname.lastname@example.org> wrote:
> Yes, thanks for the heads up. Scanning Chromium's code and running some
> quick tests didn't turn up any obvious bug, so any more details you can
> provide would be helpful.
> On Thu, Jul 6, 2017 at 3:20 PM, Kai Ninomiya <email@example.com> wrote:
>> Florian, thanks for this heads up. Are you able to glean any details from
>> your data - e.g., is it specific to a particular browser, OS, or GPU vendor?
>> Otherwise, finding a reproduction case will be a wild goose chase until we
>> can learn more about the bug.
>> On Thu, Jul 6, 2017 at 2:51 AM Florian Bösch <firstname.lastname@example.org> wrote:
>>> Due to a large number of individual values being returned by the
>>> parameter MAX_FRAGMENT_INPUT_COMPONENTS webglstats updates failed for a few
>>> days. I have a filter mechanism for such erroneous values (which is fairly
>>> extensive for WebGL1, though it seems no longer required there as values
>>> returned there seem mostly well-formed).
>>> However in WebGL2 this parameter seems to return uninitalized memory.
>>> Here is a small sample of values observed:
>>> I have filtered this parameter now and webglstats update should be
>>> progressing as per usual. The underlying implementation error likely still
>>> exists and would warrant WebGL vendors to investigate.