[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] MAX_FRAGMENT_INPUT_COMPONENTS seems to return uninitalized memory



I'm running an extract on the raw for the last 30 days filtering out log entry submissions that exhibit this malformed parameter. It probably takes the script around 20 hours to go trough a day, but when the log starts to fill with a few days worth of such entries I have more information.

On Fri, Jul 7, 2017 at 1:29 AM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
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 <kbr@google.com> 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.
>
> -Ken
>
>
> On Thu, Jul 6, 2017 at 3:20 PM, Kai Ninomiya <kainino@google.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.
>>
>> -Kai
>>
>> On Thu, Jul 6, 2017 at 2:51 AM Florian Bösch <pyalot@gmail.com> 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:
>>>
>>>  -1788917824
>>>  -1788916160
>>>  -1786396928
>>>  -1777804032
>>>  -1775925664
>>>  -1771568320
>>>  -1771532704
>>>  -1764617920
>>>  -1758531200
>>>  -1755832928
>>>  -1754378656
>>>  -1749930016
>>>  -1748075776
>>>  -1747997792
>>>  -1737351904
>>>  -1730633088
>>>  -1721286400
>>>  -1719047200
>>>  -1718632576
>>>  -1694800800
>>>  -1670866528
>>>  -1650593120
>>>  -1648639264
>>>  -1622535360
>>>  -1622534016
>>>  -1581364896
>>>  -1572312000
>>>  -1572281472
>>>  -1330485792
>>>  -1299065344
>>>  -1252403712
>>>  151689120
>>>  263489344
>>>  286266272
>>>  300064872
>>>  302099488
>>>  307719328
>>>
>>> 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.
>
>