Ich habe es mal mit ElectricFence probiert und da gibt es mit dem EPG2VDR-Plugin beliebig reproduzierbar nach Sekunden einen Abbruch.
ElectricFence Exiting: mprotect() failed: Speicherzugriffsfehler (Speicherabzug geschrieben)
Das passiert auch mit dem EPG2VDR-Plugin allein.
Und auch nur mit dem EPG2VDR-Plugin, nicht mit osdtelext und control.
Allerdings kann ich den VDR mit ElectricFence nicht mehr von der Konsole bedienen, konnte osdtelext also nicht näher testen. (Bei EPG2VDR komme ich gar nicht so weit.)
Wer es auch versuchen will, ElectricFence gibt es bei Debian als Paket und es ist recht einfach:
EF_ALLOW_MALLOC_0=1 LD_PRELOAD=/usr/lib/libefence.so ./vdr -Pepg2vdr ......
Der Fehler ist immer cSchedule, allerdings an unterschiedlichen Stellen, hier mal ein Beispiel:
Thread 6 (Thread 0x7fe230684700 (LWP 80738)):
#0 0x00007fe23bed79af in __GI___poll (fds=0x7fe230683bc0, nfds=1, timeout=150) at ../sysdeps/unix/sysv/linux/poll.c:29
#1 0x00005646b1445f19 in cPoller::Poll (this=this@entry=0x7fe230683bc0, TimeoutMs=<optimized out>) at tools.c:1566
#2 0x00005646b1409dca in cKbdRemote::ReadKey (this=this@entry=0x7fe22a130f48) at remote.c:310
#3 0x00005646b1409e65 in cKbdRemote::ReadKeySequence (this=this@entry=0x7fe22a130f48) at remote.c:326
#4 0x00005646b140a084 in cKbdRemote::Action (this=0x7fe22a130f48) at remote.c:392
#5 0x00005646b1439be1 in cThread::StartThread (Thread=0x7fe22a130f68) at thread.c:293
#6 0x00007fe23c40aea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7 0x00007fe23bee3a6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 5 (Thread 0x7fe22ee81700 (LWP 80731)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x7fe22ee7fd40, clockid=786955472, expected=0, futex_word=0x7fe22ee7fdd0) at ../sysdeps/nptl/futex-internal.h:323
#1 __pthread_cond_wait_common (abstime=0x7fe22ee7fd40, clockid=786955472, mutex=0x7fe22ee7fd80, cond=0x7fe22ee7fda8) at pthread_cond_wait.c:520
#2 __pthread_cond_timedwait (cond=cond@entry=0x7fe22ee7fda8, mutex=mutex@entry=0x7fe22ee7fd80, abstime=abstime@entry=0x7fe22ee7fd40) at pthread_cond_wait.c:656
#3 0x00005646b143938f in cCondWait::Wait (this=this@entry=0x7fe22ee7fd80, TimeoutMs=786955584, TimeoutMs@entry=100) at thread.c:86
#4 0x00005646b14393e8 in cCondWait::SleepMs (TimeoutMs=TimeoutMs@entry=100) at thread.c:75
#5 0x00005646b1412362 in cSectionHandler::Action (this=0x7fe2311bde60) at sections.c:185
#6 0x00005646b1439be1 in cThread::StartThread (Thread=0x7fe2311bde60) at thread.c:293
#7 0x00007fe23c40aea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#8 0x00007fe23bee3a6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 4 (Thread 0x7fe22f682700 (LWP 80730)):
#0 0x00007fe23bed79af in __GI___poll (fds=fds@entry=0x7fe22f680e18, nfds=nfds@entry=1, timeout=timeout@entry=50) at ../sysdeps/unix/sysv/linux/poll.c:29
#1 0x00005646b13a99e6 in cDvbCiAdapter::Read (MaxLength=4096, Buffer=0x7fe22f680e44 "", this=0x7fe23119bf10) at dvbci.c:52
#2 cDvbCiAdapter::Read (this=0x7fe23119bf10, Buffer=0x7fe22f680e44 "", MaxLength=4096) at dvbci.c:46
#3 0x00005646b138d057 in cCiAdapter::Action (this=0x7fe23119bf10) at ci.c:2158
#4 0x00005646b1439be1 in cThread::StartThread (Thread=0x7fe23119bf10) at thread.c:293
#5 0x00007fe23c40aea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#6 0x00007fe23bee3a6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 3 (Thread 0x7fe23bd21780 (LWP 80724)):
#0 futex_abstimed_wait (private=0, abstime=0x0, clockid=0, expected=3, futex_word=<optimized out>) at ../sysdeps/nptl/futex-internal.h:287
#1 __pthread_rwlock_rdlock_full (abstime=0x0, clockid=0, rwlock=0x5646b14c4c30 <cChannels::channels+48>, rwlock@entry=0x0) at pthread_rwlock_common.c:460
#2 __GI___pthread_rwlock_rdlock (rwlock=rwlock@entry=0x5646b14c4c30 <cChannels::channels+48>) at pthread_rwlock_rdlock.c:27
#3 0x00005646b14399ef in cRwLock::Lock (this=this@entry=0x5646b14c4c30 <cChannels::channels+48>, Write=Write@entry=false, TimeoutMs=TimeoutMs@entry=0) at thread.c:190
#4 0x00005646b143bf62 in cStateLock::Lock (this=this@entry=0x5646b14c4c20 <cChannels::channels+32>, StateKey=..., Write=Write@entry=false, TimeoutMs=0) at thread.c:732
#5 0x00005646b14479a6 in cListBase::Lock (this=this@entry=0x5646b14c4c00 <cChannels::channels>, StateKey=..., Write=Write@entry=false, TimeoutMs=<optimized out>) at tools.c:2206
#6 0x00005646b13831c7 in cChannels::GetChannelsRead (StateKey=..., TimeoutMs=<optimized out>) at channels.c:858
#7 0x00005646b1448835 in cChannels_Lock::cChannels_Lock (this=0x7ffe7222de50, Write=<optimized out>) at channels.h:262
#8 0x00005646b137d312 in main (argc=<optimized out>, argv=<optimized out>) at vdr.c:916
Thread 2 (Thread 0x7fe22e680700 (LWP 80734)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x7fe22e67fdb0, clockid=778566976, expected=0, futex_word=0x7fe230a0bfe8) at ../sysdeps/nptl/futex-internal.h:323
#1 __pthread_cond_wait_common (abstime=0x7fe22e67fdb0, clockid=778566976, mutex=0x7fe230a0bf60, cond=0x7fe230a0bfc0) at pthread_cond_wait.c:520
#2 __pthread_cond_timedwait (cond=cond@entry=0x7fe230a0bfc0, mutex=mutex@entry=0x7fe230a0bf60, abstime=abstime@entry=0x7fe22e67fdb0) at pthread_cond_wait.c:656
#3 0x00005646b1439553 in cCondVar::TimedWait (this=this@entry=0x7fe230a0bfc0, Mutex=..., TimeoutMs=TimeoutMs@entry=1000) at thread.c:142
#4 0x00005646b13a4ad8 in cDvbTuner::Action (this=0x7fe230a0b838) at dvbdevice.c:1767
#5 0x00005646b1439be1 in cThread::StartThread (Thread=0x7fe230a0b838) at thread.c:293
#6 0x00007fe23c40aea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7 0x00007fe23bee3a6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 1 (Thread 0x7fe22fe83700 (LWP 80729)):
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-vec.S:133
#1 0x00007fe23c4f453f in EF_Printv () from /usr/lib/libefence.so
#2 0x00007fe23c4f4705 in EF_Exitv () from /usr/lib/libefence.so
#3 0x00007fe23c4f47ac in EF_Exit () from /usr/lib/libefence.so
#4 0x00007fe23c4f36d5 in ?? () from /usr/lib/libefence.so
#5 0x00007fe23c4f3e0e in memalign () from /usr/lib/libefence.so
#6 0x00007fe23c1c00b5 in operator new(unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7 0x00005646b1447f84 in cHashBase::Add (this=this@entry=0x7fe228dddfc0, Object=Object@entry=0x7fe227f54f88, Id=27443) at tools.c:2416
#8 0x00005646b13bac7d in cSchedule::HashEvent (this=this@entry=0x7fe228dddf00, Event=Event@entry=0x7fe227f54f88) at epg.h:101
#9 0x00005646b13bacf8 in cSchedule::AddEvent (this=this@entry=0x7fe228dddf00, Event=Event@entry=0x7fe227f54f88) at epg.c:945
#10 0x00005646b13bb18f in cEvent::Read (f=0x7fe231455e28, Schedule=0x7fe228dddf00, Line=@0x7fe22fe82d8c: 7412) at epg.c:563
#11 0x00005646b13bc779 in cSchedule::Read (f=0x7fe231455e28, Schedules=0x5646b14c6980 <cSchedules::schedules>) at epg.c:1194
#12 0x00005646b13bc80c in cSchedules::Read (f=0x7fe231455e28) at epg.c:1347
#13 0x00005646b1439be1 in cThread::StartThread (Thread=0x7ffe7222deb0) at thread.c:293
#14 0x00007fe23c40aea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#15 0x00007fe23bee3a6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Alles anzeigen
Vom EPG2VDR-Plugin sehe ich hier keinen Thread.
Das könnte auf den EPG-Handler hindeuten, der wird AFAIK von VDR ausgeführt.
Das EPG2VDR-Plugin habe ich lediglich mit -Pepg2vdr gestartet.
Es ist völlig unkonfiguriert und eine Daenbank habe ich auch nicht am laufen.
Es gibt beim Start auch ein paar Fehlermeldungen:
vdr: epg2vdr: Info: Calling mysql_library_init()
vdr: [16521] CAM 1: no module present
vdr: [16521] CAM 2: no module present
vdr: epg2vdr: Set locale to 'de_DE.UTF-8'
vdr: epg2vdr: detected UTF-8
vdr: [16515] ERROR (tools.c,513): /var/cache/vdr/epgimages: Keine Berechtigung
vdr: epg2vdr: could not access or create Directory /var/cache/vdr/epgimages/images
vdr: epg2vdr: Error: Can' open file '../video0/plugins/epg2vdr//epg.dat', error was 'Datei oder Verzeichni
vdr: epg2vdr: Fatal: Dictionary not loaded, aborting!
vdr: epg2vdr: Initialization failed, start of plugin aborted!
kernel: [ 8210.393297] epg data reader[16520]: segfault at 0 ip 00007f71f725c9f6 sp 00007f71eb25dac8 error
Alles anzeigen
Einen Speicherzugriffsfehler sollte das aber eigentlich auf keine Fall nicht auslösen.
Dann bin ich auf was merkwürdiges gestoßen:
//***************************************************************************
// Define tEventID again, to create a compiler error case it was defines different
//***************************************************************************
typedef u_int32_t tEventID; // on error vdr >= 2.3.1 and patch is not applied!!
In der README steht aber:
- Patch the VDR. Patches found in patches/ since vdr 1.7.27.
For Versions after 1.7.31 you need only the epghandler-segment-transfer.patch
Sinve VDR 2.1.1 no patch is needed!
Unter /patches liegen auch Patches für vdr-2.2.0 und 2.3.0.
Was stimmt denn nun ?
Und der eine Patch für VDR-2.3.0 fummelt ausgerechnet am Schedules- und ChannelsStatekey herum.