Bug #688
openeepg crashes VDR when analyzing a certain transponder on 19.2°E
0%
Description
The eepg plugin crashes VDR when analyzing a German transponder on 19.2°E during the EPG scan.
Crashing can be provoked when switching to this channel:Sky Select,SkySel;SKY:12031:HC34M2O0S0:S19.2E:27500:2815=2:2816=deu@3,2817=deu@3;2819=deu@106:0:0:18:133:4:0
Syslog shows the following at the time of the crash:
Aug 14 14:02:30 vdr-win7 vdr: [6529] PMT scan idle
Aug 14 14:02:30 vdr-win7 vdr: [6529] EEPG: Premiere Extended EPG detected on pid b09.
Aug 14 14:02:31 vdr-win7 kernel: [21840.627821] section handler[6529] general protection ip:483ba6 sp:42c4b810 error:0 in vdr[400000+145000]
This is the gdb output:
Program terminated with signal 11, Segmentation fault.
[New process 6113]
[New process 6116]
[New process 6118]
[New process 6121]
[New process 6119]
[New process 6122]
[New process 6120]
[New process 6112]
[New process 6123]
[New process 6124]
[New process 6125]
[New process 6126]
[New process 6127]
[New process 6128]
[New process 6129]
[New process 6115]
[New process 6130]
[New process 6110]
[New process 6105]
[New process 6109]
[New process 6117]
#0 cFilter::Source (this=0xa007f30116d2010) at filter.c:91
91 return sectionHandler ? sectionHandler->Source() : 0;
(gdb) up
#1 0x00007f3012009ef0 in cFilterEEPG::Process (this=0x43de0151, Pid=<value optimized out>, Tid=<value optimized out>, Data=0x43de010e "Orderline D:0180-5530000 A:01-49168800 (Preis s. Programm-Magazin)", Length=<value optimized out>)
at eepg.c:3657
3657 tChannelID channelID (Source (), nid, tid, sid);
Current language: auto; currently c++
(gdb) up
#2 0x00000000004c74e1 in cSectionHandler::Action (this=0x7f300dd87a70) at sections.c:212
212 fi->Process(pid, tid, buf, len);
(gdb) up
#3 0x00000000004e0765 in cThread::StartThread (Thread=0x7f300dd87a70) at thread.c:257
257 Thread->Action();
(gdb) up
#4 0x00007f301b73afc7 in start_thread () from /lib/libpthread.so.0
(gdb) up
#5 0x00007f301a23164d in clone () from /lib/libc.so.6
(gdb) up
#6 0x0000000000000000 in ?? ()
(gdb) up
Initial frame selected; you cannot go up.
Files
Updated by dimeptr almost 13 years ago
From the gdb output it seems that vdr is crashing when returning the source in filter.c, however I can not reproduce the problem, I have tested both master and experimental branch on VDR 1.7.19. Can you provide your vdr version.
Updated by Jarod over 12 years ago
dimeptr wrote:
From the gdb output it seems that vdr is crashing when returning the source in filter.c, however I can not reproduce the problem, I have tested both master and experimental branch on VDR 1.7.19. Can you provide your vdr version.
I had vdr 1.7.18 running at the time the crash occured. I was not able to reproduce the crash after this particular day. All seems fine now even with vdr 1.7.20.
Updated by dimeptr over 12 years ago
- Status changed from New to Closed
Hi thanks for the update on this issue, I will close it since we can not reproduce it again.
Updated by Jarod over 12 years ago
The problem occured again yesterday. It looks the same as before.
VDR crashed after running for a few minutes, or shortly after switching to the Sky Select channel.
I recorded the entire transponder for 2 minutes. The resulting file is 541MB. Do you have a place to put it?
I am running latest eepg with vdr-1.7.20 now.
Here is the gdb output from yesterday:
#0 cFilter::Source (this=0xa007f81ebb93010) at filter.c:91
91 return sectionHandler ? sectionHandler->Source() : 0;
(gdb) up
#1 0x00007f81f05c0f40 in cFilterEEPG::Process (this=0x43cdc223, Pid=<value optimized out>, Tid=<value optimized out>,
Data=0x43cdc1e0 "Orderline D:0180-5530000 A:01-49168800 (Preis s. Programm-Magazin)", Length=<value optimized out>)
at eepg.c:3657
3657 tChannelID channelID (Source (), nid, tid, sid);
Current language: auto; currently c++
(gdb) up
#2 0x00000000004c9e91 in cSectionHandler::Action (this=0x7f81e403ab50) at sections.c:212
212 fi->Process(pid, tid, buf, len);
(gdb) up
#3 0x00000000004e3695 in cThread::StartThread (Thread=0x7f81e403ab50) at thread.c:257
257 Thread->Action();
(gdb) up
#4 0x00007f81f9d12fc7 in start_thread () from /lib/libpthread.so.0
(gdb) up
#5 0x00007f81f880964d in clone () from /lib/libc.so.6
(gdb) up
#6 0x0000000000000000 in ?? ()
(gdb) up
Initial frame selected; you cannot go up.
Updated by dimeptr over 12 years ago
- Status changed from Closed to Assigned
- Assignee set to dimeptr
I have tried again to reproduce the problem and failed. You can put the file on some of the file sharing sites, however I have no knowledge how to run eepg on it, not sure if replay would do but I can try.
However according to your bt it looks like it crashes inside vdr filter.c when getting the source i.e. the satellite. This info will not be in the recording
Updated by dimeptr over 11 years ago
- Status changed from Assigned to Feedback
is this problem reproducible again?
can this change help?
- tChannelID channelID (Source(), nid, tid, sid);
+ tChannelID channelID (Channel()->Source(), nid, tid, sid);
Updated by villeneuve over 10 years ago
- File g2v_log_01260241.tar.xz g2v_log_01260241.tar.xz added
Hello,
I'm experiencing the same problem since I completely reinstalled my VDR-system, upgrading to a 64-bit kernel and VDR 2.0.4 in the process. I'm using eepg 0.0.6pre. I did not have that problem on the exact same machine prior to reinstalling everything. I was using VDR 1.7.x before, but unfortunately can't remember the eepg-version.
When the crash occurs it gives me something like
[kernel] traps: section handler[24298] general protection ip:4cbf5e sp:7fb01b3ef470 error:0 in vdr[400000+1c6000]
The first and third numbers in that error message change from crash to crash, the other numbers are the same on every crash. The error is always right after these three messages:
EEPG: PMT scan idle_
EEPG: Premiere Extended EPG detected on pid b09.
EEPG: Filter Pid:b09,Tid:a0 added.
Those messages make me believe, that the crashes are caused by eepg.
I could not yet make out a rule for this happening, sometimes it's just every hour, something there's a week between crashes. I had those crashes while purely TV-watching, radio-listening, with and without recordings going on in the background.
Until now, I had the plugin epgtableid0 running. Since my last crash I took it out and will now observe, if VDR crashes again even without epgtableid0.
I would really like to help to find the cause for this, because I love the eepg-plugin!
I attached a log-package, that is automatically generated by Gen2VDR, which is the distribution I'm using.
Please tell me, what additional information and/or logfiles you need!
Updated by dimeptr over 10 years ago
can you enable core dumps on your system and do a stack trace, the log does not help much.
the core dump is enabled with:
ulimit -c unlimited
prior to starting vdr, on the same shell.
after vdr crashes, it will genrate core file on which you can do backtrace with a command similar to this:
gdb path/to/vdr path/to/core
and inside
bt
if you provide this backtrace it will be very helpfull
Updated by villeneuve over 10 years ago
Hi,
since reporting the bug I disabled eepg to see, if that makes any difference and indeed it did, no such crashes without eepg! I'll now re-enable eepg and then provide a core dump as you ordered.