[linuxtv-softmpeg] Good news + stack corruption?

["Colin Paton" <ac2crp@blueyonder.co.uk>]

Hi,

I decided it would be easier to get video playback working in order to get
the hardware decoder working. I turned on all debugging, took the machine
downstairs to plug into the TV, and voila! Playback of VDR files works!
Cool! I guess that the recent timing fixes must have got things going -
thanks Michael!

However, I have noticed crashes, all of which have so far exhibited the
following symptoms. The core file I get shows the following when run through
gdb:

#0 0x42047f19 in vfprintf () from /lib/i686/libc.so.6

#1 0x4205237f in fprintf () from /lib/i686/libc.so.6

#2 0x405507f5 in dfb_sig_action () from /usr/local/lib/libdirectfb-0.9.so.21

#3 0x4004e516 in __pthread_sighandler_rt () from /lib/i686/libpthread.so.0

#4 <signal handler called>

#5 0x40048f02 in pthread_mutex_lock () from /lib/i686/libpthread.so.0

#6 0x4004b572 in flockfile () from /lib/i686/libpthread.so.0

#7 0x420628e8 in fflush () from /lib/i686/libc.so.6

#8 0x405508f7 in dfb_sig_action () from /usr/local/lib/libdirectfb-0.9.so.21

#9 0x4004e516 in __pthread_sighandler_rt () from /lib/i686/libpthread.so.0

#10 <signal handler called>

#11 0x40048f02 in pthread_mutex_lock () from /lib/i686/libpthread.so.0

#12 0x4004b572 in flockfile () from /lib/i686/libpthread.so.0

#13 0x420628e8 in fflush () from /lib/i686/libc.so.6

#14 0x405508f7 in dfb_sig_action () from
/usr/local/lib/libdirectfb-0.9.so.21

#15 0x4004e516 in __pthread_sighandler_rt () from /lib/i686/libpthread.so.0

---Type <return> to continue, or q <return> to quit---

(The crash is presumably caused by the stack overflowing, as the stack dump
recurses - I've only shown part above)

I tried to catch the signal that was causing the error by running vdr within
gdb, and get a different error:

{-} [ 921: 109.291] SoftMPEG/audio_handle_pes_data/Audio PES: current audio
buf has 36864 samples

{-} [ 921: 109.291] SoftMPEG/audio_handle_pes_data/Audio PES: moving 0 bytes
to front

audio_handle_pes_data - delay 0

video_handle_pes_data - delay 0

video_handle_pes_data - delay 0

video_handle_pes_data - delay 0

video_handle_pes_data - delay 0

video_handle_pes_data - delay 0

handle_pes_data - delay 0

[softmpeg] PlayVideo: 1618 bytes

Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread 65545 (LWP 912)]

0x40048f02 in pthread_mutex_lock () from /lib/i686/libpthread.so.0

(gdb) backtrace

#0 0x40048f02 in pthread_mutex_lock () from /lib/i686/libpthread.so.0

#1 0x4004b572 in flockfile () from /lib/i686/libpthread.so.0

#2 0x42063988 in fwrite () from /lib/i686/libc.so.6

#3 0x4057ce21 in avsync_thread (data=0x81174f0) at softmpeg.c:143

#4 0x40048941 in pthread_start_thread () from /lib/i686/libpthread.so.0

#5 0x40048a45 in pthread_start_thread_event () from
/lib/i686/libpthread.so.0

(gdb)

The stack dump looks to be garbage (the sync thread calling fwrite???)
However, the 'moving 0 bytes to front' message before the crash looks
strange. Should this happen normally?

I don't think that the problem is due to a corrupted file, as it happened at
different parts of the same file. I initially thought that perhaps one of
the video buffers might have overflowed - I might try putting some bounds
checking in at some point to see if that makes any difference.

Has anyone else noticed a similar crash? I noticed that a crash would occur
during live video previously if I left the box on all day - this appeared in
the SetField call to directFB, which again looked like some kind of stack
corruption.

Has anyone noticed anything similar?

It's definitely beginning to work well - thanks Michael!

Regards,

Colin







-- 
Info:  To unsubscribe send a mail to ecartis@linuxtv.org with 
"unsubscribe linuxtv-softmpeg" as subject.