[vlc-devel] [PATCH] prefetch: remove read size, always request maximum

[Rémi Denis-Courmont]

Le 20 avril 2018 14:47:25 GMT+03:00, Thomas Guillem <thomas at gllm.fr> a écrit :
>I'm afraid this commit is quite dangerous.
>
>I'm working on the libsmb2 access now and got this error with this
>prefetch commit:
>
>[00007f54d4000d90] smb2 access error: smb2_read_async failed: Read
>count 16777216 larger than max_read_size 8388608
>
>It's OK, I can fix this particular access, but what about other modules
>?
>
>Should all accesses handle such huge read sizes ? It can be set to 1GB
>from settings. A lot of access plugins will just do a malloc of 1GB
>then...
>
>
>On Wed, Apr 18, 2018, at 10:51, Rémi Denis-Courmont wrote:
>> And? Care to explain how prefetch is not doing the same thing than
>the 
>> UDP thread?
>> 
>> Also, DTV is totally broken for me in 3.0, even though it does not
>use 
>> prefetch at all. And that is leaving aside the 4.0-only infinite loop
>in 
>> cache_block.
>> -- 
>> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez
>excuser 
>> ma brièveté.
>> _______________________________________________
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> https://mailman.videolan.org/listinfo/vlc-devel
>_______________________________________________
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:
>https://mailman.videolan.org/listinfo/vlc-devel

The specified maximum read size is SSIZE_MAX. You always have the option to return less.

If you set the prefetch buffer size to 1 GiB, then it will allocate 1 GiB regardless of what access does. This patch makes no difference to buffer size. You get similar issues with insanely large PTS delay values. And yes, the process may be killed by OOM killer. This is a very generic problem.
-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.