[Libav-user] Possible fix for rare core-dumps in H264

[Mark Stevans]

On 6/21/2013 1:36 AM, Carl Eugen Hoyos wrote:
> Mark Stevans <mark39518 at ...> writes:
>
>> It takes hours of testing to generate a stack trace
>
> I am not sure I understand: The additional effort
> should be far below five minutes, could you
> elaborate?

Ah, I wasn't clear yet again: when I said "core-dump", I don't mean an 
actual core-dump on disk.  I'm running under Windows 7 here, debugging 
with WinDbg....

I have to run FFPlay for anywhere up to 12 hours to get an Access 
Violation under the debugger, at which point it's easy to include a 
stack trace.  But if I didn't copy out any of my complete stack traces 
from earlier crashes, I would have to get the bug to happen again....

>> And it's very difficult to get a clip for reproduction,
>> as this is a live stream running for hours.
>
> rtmpdump should allow to record a sample.

"rtmpdump" can indeed record a sample of the stream.  But if it takes 
six hours to happen to land on a place that evokes the crash, that's 100 
KB/s times six hours, or 2.1 GB of stream.  I *could* try to partition 
it down, just taking the last few MB, hoping that that, in isolation, 
would cause the crash, but it doesn't sound like I could replicate it 
reliably.

> Allow me to explain that it is extremely unlikely
> that a developer will work on a ticket that does
> not nearly contain enough information to allow
> fixing it, as you may have seen there is a large
> number of open and reproducible tickets.

Contain not nearly enough information to allow fixing it?  Not to be 
argumentative, but I provided a patch.  How much more information is 
required?  This is not a hard bug to understand, to be frank: if you're 
decoding and hit a directive that tells you to look at the previous 
row's data, but you're on the first row, just ignore it.  Obviously, 
that should never happen in a normal stream, but with bad data, anything 
is possible.

> Posting your patch on ffmpeg-devel could be an
> alternative (as said, there is a very long history
> of patches that are ignored on trac, this is why
> the New Ticket page says "Patches should be
> submitted to the ffmpeg-devel mailing list and not
> this bug tracker." - if you believe this sentence
> can be improved, please tell us).

Frankly, I don't understand how patches could be ignored on TRAC, yet 
observed in "ffmpeg-devel".  But I will send my patch there, 
nevertheless.  Thanks again for your help....

MLS