Re: [Libav-user] Possible fix for rare core-dumps in H264
On 6/21/13, Carl Eugen Hoyos wrote: > Paul B Mahol writes: > >> Are you enjoying yourself? > > You mean compared to you when you (intentionally!) > commit other people's patches? What other people's patches? ___ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user
Re: [Libav-user] Possible fix for rare core-dumps in H264
Mark Stevans writes: > > gdb works fine on Windows (7) > > I spent days trying to debug earlier bugs with > Windows GDB, but couldn't get decent stack > traces -- I tried every possible debugging > flag and symbol format to no avail. That surprises me: I am regularly using gdb to debug on Windows 7 and I do no remember that it ever worked worse than on Linux. Or in other words: It is possible that no backtrace is available (for example because the stack was corrupted) but generally I get all necessary debug information (just as on a Posix system) and I usually get backtrace etc. to be used for FFmpeg bug reports. What did not work for you? Did you maybe use gdb on a stripped ffmpeg.exe? Carl Eugen ___ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user
Re: [Libav-user] Possible fix for rare core-dumps in H264
On 6/21/2013 2:39 AM, Carl Eugen Hoyos wrote: Mark Stevans writes: 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 gdb works fine on Windows (7), it would also allow to produce a useful backtrace (and disassembly and register content) for a recorded stream. (You are probably right that it may not be possible to cut the stream.) Carl Eugen ___ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user I spent days trying to debug earlier bugs with Windows GDB, but couldn't get decent stack traces -- I tried every possible debugging flag and symbol format to no avail. I'm now building FFPlay with Visual Studio, so GDB isn't an option anymore, sorry MLS ___ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user
Re: [Libav-user] Possible fix for rare core-dumps in H264
Paul B Mahol writes: > Are you enjoying yourself? You mean compared to you when you (intentionally!) commit other people's patches? Carl Eugen ___ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user
Re: [Libav-user] Possible fix for rare core-dumps in H264
On 6/21/13, Carl Eugen Hoyos wrote: > Mark Stevans writes: > >> Frankly, I don't understand how patches could be >> ignored on TRAC, yet observed in "ffmpeg-devel". > > I was just describing what experience tells me. > >> But I will send my patch there > > It appears that I was unclear again, sorry about that! > Bug reports are not welcome on ffmpeg-devel, we tried > to explain this on http://ffmpeg.org/contact.html > Since I am not an English native speaker, please allow > me to repeat that suggestions on how to improve the > wording are very welcome! > > Patches are welcome on ffmpeg-devel, and in a case > such as this one, the mail should of course include as > much information as possible, but this information > cannot replace the actual patch made with > git format-patch as explained on > http://ffmpeg.org/developer.html#Submitting-patches-1 Are you enjoying yourself? ___ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user
Re: [Libav-user] Possible fix for rare core-dumps in H264
Mark Stevans writes: > Frankly, I don't understand how patches could be > ignored on TRAC, yet observed in "ffmpeg-devel". I was just describing what experience tells me. > But I will send my patch there It appears that I was unclear again, sorry about that! Bug reports are not welcome on ffmpeg-devel, we tried to explain this on http://ffmpeg.org/contact.html Since I am not an English native speaker, please allow me to repeat that suggestions on how to improve the wording are very welcome! Patches are welcome on ffmpeg-devel, and in a case such as this one, the mail should of course include as much information as possible, but this information cannot replace the actual patch made with git format-patch as explained on http://ffmpeg.org/developer.html#Submitting-patches-1 Carl Eugen ___ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user
Re: [Libav-user] Possible fix for rare core-dumps in H264
Mark Stevans writes: > 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 gdb works fine on Windows (7), it would also allow to produce a useful backtrace (and disassembly and register content) for a recorded stream. (You are probably right that it may not be possible to cut the stream.) Carl Eugen ___ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user
Re: [Libav-user] Possible fix for rare core-dumps in H264
On 6/21/2013 1:36 AM, Carl Eugen Hoyos wrote: Mark Stevans 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 ___ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user
Re: [Libav-user] Possible fix for rare core-dumps in H264
Mark Stevans 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? > 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. 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. 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). Carl Eugen ___ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user
Re: [Libav-user] Possible fix for rare core-dumps in H264
You explained -- just not strongly enough to make me understand. It takes hours of testing to generate a stack trace, but I wrote down the most import part -- the last two frames. And it's very difficult to get a clip for reproduction, as this is a live stream running for hours. To be honest, I think the description is adequate. Anyone that knows the H264 code should be able to determine quickly whether the report is valid or not Mark On 6/21/2013 1:17 AM, Carl Eugen Hoyos wrote: Carl Eugen Hoyos writes: Mark Stevans ...> writes: When playing unreliable H264 streams with FFPlay, I seem to get core-dumps randomly every few hours. This sounds important, please provide the necessary information as explained on http://ffmpeg.org/bugreports.html I apparently forgot to explain that it makes no sense to open a ticket if you can neither provide the necessary information as explained on http://ffmpeg.org/bugreports.html nor a sample. A sample would be useful (the size limitation mentioned in above page is irrelevant in this case), you may also only upload a sample, a developer will probably look at it (every crash is important). If you want comments on your patch, use git format-patch and send the commit to ffmpeg-devel where patches are discussed. I apparently forgot to explain that it makes no sense to post patches on the bug tracker, they are usually ignored there. Sorry, Carl Eugen ___ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user ___ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user
Re: [Libav-user] Possible fix for rare core-dumps in H264
Carl Eugen Hoyos writes: > Mark Stevans ...> writes: > > > When playing unreliable H264 streams with FFPlay, I > > seem to get core-dumps randomly every few hours. > > This sounds important, please provide the necessary > information as explained on > http://ffmpeg.org/bugreports.html I apparently forgot to explain that it makes no sense to open a ticket if you can neither provide the necessary information as explained on http://ffmpeg.org/bugreports.html nor a sample. > A sample would be useful (the size limitation > mentioned in above page is irrelevant in this case), > you may also only upload a sample, a developer will > probably look at it (every crash is important). > If you want comments on your patch, use > git format-patch and send the commit to ffmpeg-devel > where patches are discussed. I apparently forgot to explain that it makes no sense to post patches on the bug tracker, they are usually ignored there. Sorry, Carl Eugen ___ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user
Re: [Libav-user] Possible fix for rare core-dumps in H264
Mark Stevans writes: > When playing unreliable H264 streams with FFPlay, I > seem to get core-dumps randomly every few hours. This sounds important, please provide the necessary information as explained on http://ffmpeg.org/bugreports.html A sample would be useful (the size limitation mentioned in above page is irrelevant in this case), you may also only upload a sample, a developer will probably look at it (every crash is important). If you want comments on your patch, use git format-patch and send the commit to ffmpeg-devel where patches are discussed. Carl Eugen ___ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user
