[vdr] dxr3 plugin crashes

[Malcolm Caldwell <malcolm.caldwell@ntu.edu.au>]

The dxr3 plugin crashes on me several times a day.  Each time it seg
faults in the same place.  It would seem from looking at the code that
there is some problem decoding the pes packets.

Below is my gdb session investigating the problem.

Current directory is /home/malcolm/VDR/
GNU gdb Red Hat Linux (5.1.90CVS-5)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) core core.10213
Core was generated by `vdr -Pdxr3'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libjpeg.so.62...done.
Loaded symbols for /usr/lib/libjpeg.so.62
Reading symbols from /lib/i686/libpthread.so.0...done.
Loaded symbols for /lib/i686/libpthread.so.0
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/lib/libstdc++-libc6.2-2.so.3...done.
Loaded symbols for /usr/lib/libstdc++-libc6.2-2.so.3
Reading symbols from /lib/i686/libm.so.6...done.
Loaded symbols for /lib/i686/libm.so.6
Reading symbols from /lib/i686/libc.so.6...done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from ./PLUGINS/lib/libvdr-dxr3.so.1.1.20...done.
Loaded symbols for ./PLUGINS/lib/libvdr-dxr3.so.1.1.20
#0  0x420829ec in memcpy () from /lib/i686/libc.so.6
(gdb) bt
#0  0x420829ec in memcpy () from /lib/i686/libc.so.6
#1  0x40107fde in Push__15cDxr3SyncBufferPCUciUi10eFrameType (this=0x41208280, 
    pStart=0x41228705 "", length=-13, pts=2752338435, type=ftUnknown)
    at dxr3syncbuffer.c:116
#2  0x40109ff7 in DemuxPes__16cDxr3DemuxDevicePCUci (this=0x41208198, 
    buf=0x41228554 "_234", length=2051) at dxr3demuxdevice.c:261
#3  0x401072b6 in PlayVideo__11cDxr3DevicePCUci (this=0x41208008, 
    buf=0x944f3a0 "", length=2048) at dxr3device.c:206
#4  0x08083432 in PlayVideo__7cPlayerPCUci (this=0x942aaa8, Data=0x944f3a0 "", 
    Length=2048) at player.c:29
#5  0x08091a1c in Action__9cTransfer (this=0x942aa58) at transfer.c:95
#6  0x0808de36 in StartThread__7cThreadP7cThread (Thread=0x942aab4)
    at thread.c:144
#7  0x40047fef in pthread_start_thread () from /lib/i686/libpthread.so.0
(gdb) up
#1  0x40107fde in Push__15cDxr3SyncBufferPCUciUi10eFrameType (this=0x41208280, 
    pStart=0x41228705 "", length=-13, pts=2752338435, type=ftUnknown)
    at dxr3syncbuffer.c:116
(gdb) print pStart
$1 = (uint8_t *) 0x41228705 ""
(gdb) print length
$2 = -13
(gdb) up
#2  0x40109ff7 in DemuxPes__16cDxr3DemuxDevicePCUci (this=0x41208198, 
    buf=0x41228554 "_234", length=2051) at dxr3demuxdevice.c:261
(gdb) print tmp1
$3 = (uint8_t *) 0x41228705 ""
(gdb) print tmp2
$4 = (uint8_t *) 0x412286f8 "\214_n; kh\r\e k\023

So, the code that works out tmp2 is having problems.  Besides fixing the
problem perhaps it is worth while putting a sanity check to skip over
this case?



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