GNOME Bugzilla – Bug 568689
SIGEV using ffenc_wmav2
Last modified: 2009-08-10 23:51:55 UTC
---steps: It crashs on a very particular sound (noise + saturation). On both ubuntu intrepid and windows. I can send you the file by email. gst-launch-0.10 filesrc location=julien'sfile.wav ! wavparse ! ffenc_wmav2 ! fakesink sync=1 ---track: at gstffmpegenc.c:776: "subbuf = gst_buffer_join (ffmpegenc->cache, subbuf);" 0:00:00.394646468 21370 0x9f2d858 DEBUG ffmpeg gstffmpegenc.c:711:gst_ffmpegenc_chain_audio:<ffenc_wmav20> Received buffer of time 0:00:17.066666667 and size 4096 (cache: 4096) 0:00:00.395027437 21370 0x9f2d858 DEBUG ffmpeg gstffmpegenc.c:711:gst_ffmpegenc_chain_audio:<ffenc_wmav20> Received buffer of time 0:00:17.089886622 and size 4096 (cache: 0) 0:00:00.395050424 21370 0x9f2d858 DEBUG ffmpeg gstffmpegenc.c:711:gst_ffmpegenc_chain_audio:<ffenc_wmav20> Received buffer of time 0:00:17.113106576 and size 4096 (cache: 4096) 0:00:00.395836829 21370 0x9f2d858 DEBUG ffmpeg gstffmpegenc.c:711:gst_ffmpegenc_chain_audio:<ffenc_wmav20> Received buffer of time 0:00:17.136326531 and size 4096 (cache: 0) 0:00:00.395859710 21370 0x9f2d858 DEBUG ffmpeg gstffmpegenc.c:711:gst_ffmpegenc_chain_audio:<ffenc_wmav20> Received buffer of time 0:00:17.159546486 and size 4096 (cache: 4096) Caught SIGSEGV accessing address 0xd0c007 ---backtrace: Passage du pipeline à la phase PLAYING... New clock: GstSystemClock Program received signal SIGSEGV, Segmentation fault.
+ Trace 211762
Thread 3070856080 (LWP 20831)
I am not sure it comes from wmaenc. from ffmpeg code because: ffmpeg -i juliensfile.wav -f asf -acodec wmav2 -ab 128k out.asf works fine. Tell me how to send you the wav file. Sincerely Julien
line 776 is "ret = gst_pad_push (ffmpegenc->srcpad, outbuf);" (not "subbuf = gst_buffer_join (ffmpegenc->cache, subbuf);" )
Created attachment 127641 [details] Valgrind log Valgrind does not seem to like what the ffmpeg encoder is doing.
Actually, I believed it was a bug in wmaenc.c from ffmpeg code, but the following: ffmpeg -i juliensfile.wav -f asf -acodec wmav2 -ab 128k out.asf seems to work fine. So I cannot reproduce the bug using only "ffmpeg". So maybe gst-ffmpeg is not using the encoder as expected and that why we get a crash with: gst-launch-0.10 filesrc location=julien'sfile.wav ! wavparse ! ffenc_wmav2 ! fakesink sync=0 So what do you think ? gstreamer or ffmpeg bug ? If ffmpeg bug, how can I report it because the minimal test to reproduce is using gstreamer ... ? Mark have you tested with the audio.wav and audio2.wav I sent you ? (because I can see test.wav in your valgrind log) (If other guys want to reproduce the bug, I have to send you the wav file) Cap.
[Yes, I tested with those files, but what's in a name, etc ] It is an ffmpeg bug. More specifically, the bitstream writing that is done in ffmpeg's bitstream.h (used by wmaenc a.o.) performs no buffer overflow checking whatsoever. wmaenc basically varies some parameter(s) trying to squeeze the result into the buffer (too bad if it overruns in the process), and only checks that the last attempt actually fits. It happens to work in the ffmpeg binary because the buffer size used there is a lot bigger than typically used in ffenc_... (though big enough for most material).
Created attachment 127788 [details] [review] Workaround patch * Adjust encoder audio output buffer size to match ffmpeg's [attempting to reduce "... but it works in ffmpeg"] No absolute guarantee though that this will work safely in all cases (nor ffmpeg for that matter), or that it will conceal problems similarly to ffmpeg (as I believe it always uses the same output buffer, where ffenc_... uses a new one each time, so maybe more memory to mess up there, etc)
Mark, any chance we could/should have a patch for upstream ffmpeg ? We should get these issues fixed upstream as much as possible. If we can't come up with a clean upstream fix/patch ... we can fix it in gst-ffmpeg using your provided patch.
Well, opinions may vary here. Most appropriate seems to be to add buffer size checks prior to actual writing in bitstream.h, which would entail some if'ing in inner(most) loop in a variety of flavours (aligned, unaligned, assembly) while trying to preserve writing effects/semantics. That may not be considered clean or highly appreciated upstream (?)
Hi, Or checks then just return an appropriate gst error (and stop the pipeline) instead of "entail some if'ing in inner(most) loop in a variety of flavours(aligned, unaligned, assembly)while trying to preserve writing effects/semantics." in order to avoid a crash.
The if'ing involved would perform checks not to exceed buffer size. However, such checks are not possible at the high level ffmpeg call (performed by gst), and on low (inner loop) ffmpeg level ... well that involves what was mentioned earlier (and is ffmpeg internal, so no gst error can live there).
Please retest with latest git versions, the encoder wrapper was rewritten.
It's fixed now, nice. It was crashing just before this following commit: http://cgit.freedesktop.org/gstreamer/gst-ffmpeg/commit/?id=25b41829b930c2577632cba82654c1fdf618bd8f And this commit resolved the problem.