[vlc-devel] [vlc-commits] picture: factor freeing picture_t
robux4 at ycbcr.xyz
Fri Dec 14 16:45:47 CET 2018
The issue is this line:
It free() the clone. Which is then free() again in the caller of
Maybe it works for you if you don't use codecs using clones...
On 14/12/2018 09:03, Steve Lhomme wrote:
> On 13/12/2018 16:50, Rémi Denis-Courmont wrote:
>> Le torstaina 13. joulukuuta 2018, 11.16.35 EET Steve Lhomme a écrit :
>>> This crashes on Windows. The commits after that don't fix it.
>>> It crashes with software and hardware chromas when freeing the decoded
>> There are only two ways that this changeset can crash: either it's a
>> to-fix double free, or it's some latent/preexisting bug.
> We'll see when there is a fix. I had a look and it didn't look like a
> double free. The free() crashes with a memset() inside, probably to
> write 0xdeadbeef in debug builds. But the memory has proper values
> before the call.
> Also it's not the first free() that crashes but after a few frames are
> The fix may be trivial but it's not trivial to find.
>> Either way, I don't see the need to make a huge deal on vlc-devel.
> This is how we signal the author that a commit has an issue. That's
> why vlc-commit mails have a reply-to going to vlc-devel.
>>> Can you send your patches on the ML when you have big changes like that
>>> that you are not sure about ?
>> I do. And typically, they get ignored for more than a week, if not
> It's still worth a try.
>> Obivously I will not be extending this to patches that I am sure
>> about, like
>> this one.
>> And *this* is not a big change in terms of either subjective concept or
>> objective size.
>>> We all do.
>> Ahaha, very funny.
>>> I assume this was tested before pushing.
>> Of course. This was manually tested and make-checked with sanitizers.
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel