Re: [meta-freescale] Chromium crashes on HTML5 video tag

[Nikolay Dimitrov <picmaster@mail.bg>]

Hi Gary,

On 06/12/2015 03:23 PM, Gary Thomas wrote:
> On 2015-06-12 06:08, Nikolay Dimitrov wrote:
>> Hi Gary,
>>
>> On 06/12/2015 02:42 PM, Gary Thomas wrote:
>>> On 2015-06-12 05:31, Otavio Salvador wrote:
>>>> On Fri, Jun 12, 2015 at 7:46 AM, Nikolay Dimitrov <picmaster@mail.bg>
>>>> wrote:
>>>>> On 06/12/2015 09:51 AM, Nikolay Dimitrov wrote:
>>>>>>
>>>>>> Adding openembedded guys in the loop.
>>>>>>
>>>>>>
>>>>>> On 06/11/2015 11:39 PM, Nikolay Dimitrov wrote:
>>>>>>>
>>>>>>> Hi gang,
>>>>>>>
>>>>>>> Chromium tabs are crashing when they see an HTML5 <video> tag, like
>>>>>>> this one:
>>>>>>>
>>>>>>> <video width="320" height="240" controls>
>>>>>>>     <source src="movie.mp4" type="video/mp4">
>>>>>>> </video>
>>>>>>>
>>>>>>> (Code is from http://www.w3schools.com/html/html5_video.asp)
>>>>>>>
>>>>>>> I'm pretty sure that this worked fine some weeks ago, so it's a
>>>>>>> recent
>>>>>>> regression on Fido, 100% reproducible on imx6q sabresd. At this
>>>>>>> moment
>>>>>>> I still can't point to a specific commit in meta-fsl-arm or
>>>>>>> meta-browser.
>>>>>
>>>>>
>>>>> Commit 30b8d6b3d0d6501c56ef6967a2fa73a3d4bf5fe9 is the last known good
>>>>> commit. After it the component either doesn't compile, libs are
>>>>> missing
>>>>> or video tag isn't working.
>>>>>
>>>>> Looks like it's a "revert time" for the customer builds...
>>>>
>>>> Might be packaging splitting which can have changes. One way to easily
>>>> track this is using buildhistory and compare both packaged outputs.
>>>>
>>>
>>> It looks to me like that revision updated by 2 major versions of
>>> Chrome - more likely there are goblins in there than just a packaging
>>> issue.
>>
>> Not really. Commit 30b8d6b3d0d6501c56ef6967a2fa73a3d4bf5fe9 is working
>> OK, as I described. Issues start from the next commit,
>> 355f6d474462996c3bf07d7a72233b6c81cb2e8a.
>
> Ah, I should have read your comment more thoroughly.  Indeed the next
> commit (355f6d) is quite intrusive - it's easy to see that something
> might have been missed in that split of the recipes.
>
> Is this problem only on i.MX6?  Have you tried it on other ARM targets
> or even PC?

No, I haven't tried it elsewhere. My usual motivation to avoid that is
because there are tons of possible differences (toolchains, libs, cpu
architectures, kernels, patch sets to fix SoC issues) and it's next to
impossible to guarantee that the code and data have precisely the same
layout in memory, and that the code is executed precisely the same way.

But this is my perception, it's entirely OK if others see things in
different perspective :D.

Kind regards,
Nikolay