[vdr] Re: VDR 1.3.6: Strange SEGFAULT in libsi/si.h

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Sascha Volkenandt wrote:
> 
> Hi everybody,
> 
> today I'm having a strange segfault about once every hour. Of course I've
> tried that with plain vanilla 1.3.6 after it happened a few times with my
> patched version. I've never seen something like this before, but today it
> happens repeatedly and the backtrace is always the same:
> 
> #0  0x0809040c in
> SI::StructureLoop<SI::EIT::Event>::hasNext(SI::Loop::Iterator&)
> (this=0xbf1f000a, it=@0x0) at si.h:306
> #1  0x0808f0cf in cEIT (this=0xbf1fe9ac, Schedules=0x814ca20, Source=35008,
>     Tid=96 '`', Data=0xbf1feaac "`úqmp× h\0047") at eit.c:50
> #2  0x080902dc in cEitFilter::Process(unsigned short, unsigned char, unsigned
> char const*, int) (this=0xbf1fe9ac, Pid=10, Tid=96 '`',
>     Data=0xbf1feaac "`úqmp× h\0047", Length=2676) at eit.c:270
> #3  0x080bc63d in cSectionHandler::Action() (this=0x8a88d80) at sections.c:199
> #4  0x080c0ce8 in cThread::StartThread(cThread*) (Thread=0x8a88d80)
>     at thread.c:189
> #5  0x40045c60 in pthread_start_thread () from /lib/libpthread.so.0
> 
> When looking at the code I'm especially wondering how "it", a REFERENCE, could
> ever be zero (it is not passed from a pointer in #1). When compiling vdr
> without -O2, looking at "it" in #1 clearly confirms that it is an object and
> NOT zero.
> 
> The content of the this-pointer in #0 was:
> $2 = {<Loop> = {<VariableLengthPart> = {<Object> = {<Parsable> = {
>           _vptr.Parsable = 0x0, parsed = false}, data = {data_ = 0x0,
>           off = 0}}, length = 0}, <No data fields>}, <No data fields>}
> 
> The content of the this-pointer in #1 was:
> $4 = {<EIT> = {<NumberedSection> = {<CRCSection> = {<Section> = {<Object> =
> {<Parsable> = {_vptr.Parsable = 0x80d8948, parsed = true}, data = {
>               data_ = 0x8c65ab8,
>               off = 0}}, <No data fields>}, <No data fields>}, <No data
> fields>}, eventLoop = {<Loop> = {<VariableLengthPart> = {<Object> =
> {<Parsable> = {
>               _vptr.Parsable = 0x80d8960, parsed = false}, data = {
>               data_ = 0x8c65ab8, off = 14}},
>           length = 2658}, <No data fields>}, <No data fields>},
>     s = 0xbf1feaac}, <No data fields>}
> 
> The last things that happened before the crash (according to syslog):
> Apr  2 20:25:05 video vdr[31819]: changing transponder data of channel 1207
> from S19.2E:12070:h:27500:3 to S19.2E:12460:h:27500:3
> Apr  2 20:25:05 video vdr[31819]: changing transponder data of channel 1606
> from S19.2E:12070:h:27500:3 to S19.2E:12460:h:27500:3
> Apr  2 20:25:05 video vdr[31819]: changing transponder data of channel 1607
> from S19.2E:12070:h:27500:3 to S19.2E:12460:h:27500:3
> Apr  2 20:25:38 video vdr[31819]: channel 28 (QVC GERMANY) event 10:00
> 'Goldstücke' status 4
> Apr  2 20:25:38 video vdr[31819]: channel 21 (Bloomberg TV Germany) event
> 10:20 'Bloomberg Forum' status 4
> Apr  2 20:25:38 video vdr[31819]: channel 11 (VIVA PLUS) event 10:00 'WOM
> Music Shop' status 4
> 
> All channels that are not or interest are behind no. 1000
> 
> And I'm using VDR 1.3.6 (which worked fine until yesterday, today those
> crashes happened), kernel 2.4.20, DVB 08-11-2003 on SuSE 8.2, everything
> untouched for months now (meaning I didn't modify anything yesterday or
> today).

Does this still happen in VDR 1.3.7?

Since I never had it in 1.3.6 and don't have it in the current version,
I'm wondering if this is still a problem.

Klaus


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