I have some old recordings made on 2005 which does not have info file. This caused vdr 1.7.17 to crash because in tools.c line 1194 there is no check whether the file parameter passed is NULL or not. Real cause for the crash is in the vdrrip plugins which should handle the case where the info file does not exist on setLengthVDR method on movie.c. Anyway, it's propably good idea also to has the NULL check's in vdr's own code. Patches attached for tools.c and recording.c.
#0 0x00007ffff640e8ff in getdelim () from /lib64/libc.so.6 #1 0x00000000004fcd48 in getline (this=0x7fffffffde30, f=0x0) at /usr/include/bits/stdio.h:118 #2 cReadLine::Read (this=0x7fffffffde30, f=0x0) at tools.c:1194 #3 0x00000000004cc383 in cRecordingInfo::Read (this=0xc29bc0, f=0x0) at recording.c:419 #4 0x00007fffef0397a0 in cMovie::setLengthVDR() () from ./PLUGINS/lib/libvdr-vdrrip.so.1.7.17 #5 0x00007fffef03af00 in cMovie::cMovie(char const*, char const*) () from ./PLUGINS/lib/libvdr-vdrrip.so.1.7.17 #6 0x00007fffef0367d7 in cMenuVdrripMovie::cMenuVdrripMovie(char const*, char const*) () from ./PLUGINS/lib/libvdr-vdrrip.so.1.7.17 #7 0x00007fffef03807d in cMenuVdrripEncode::ProcessKey(eKeys) () from ./PLUGINS/lib/libvdr-vdrrip.so.1.7.17
[lamikr@tinka Prisma:_Einstein_ja_kaiken_teoria]$ ls -la 2005-04-21.20:58.50.99.rec/ total 1338080 drwxr-xr-x 2 76 76 4096 2008-05-17 17:48 ./ drwxr-xr-x 3 76 76 4096 2008-05-17 17:46 ../ -rw-r--r-- 1 76 76 1369418800 2008-05-17 17:48 001.vdr -rw-r--r-- 1 76 76 727968 2008-05-17 17:48 index.vdr -rw-r--r-- 1 76 76 4 2008-05-17 17:48 resume.vdr -rw-r--r-- 1 76 76 441 2008-05-17 17:48 summary.vdr
On 03.04.2011 12:23, Mika Laitio wrote:
I have some old recordings made on 2005 which does not have info file. This caused vdr 1.7.17 to crash because in tools.c line 1194 there is no check whether the file parameter passed is NULL or not. Real cause for the crash is in the vdrrip plugins which should handle the case where the info file does not exist on setLengthVDR method on movie.c. Anyway, it's propably good idea also to has the NULL check's in vdr's own code. Patches attached for tools.c and recording.c.
I wonder who is actually calling cRecordingInfo::Read(FILE *f) with a NULL pointer? In VDR's own code all calls to that function are made sure to get a non-NULL pointer:
bool cRecordingInfo::Read(void) { bool Result = false; if (fileName) { FILE *f = fopen(fileName, "r"); if (f) { if (Read(f))
cRecording::cRecording(const char *FileName) { ... FILE *f = fopen(InfoFileName, "r"); if (f) { if (!info->Read(f))
Since it doesn't make any sense to call cRecordingInfo::Read(FILE *f) from outside cRecordingInfo, I made that function private now. This may break some plugin, but that should have called cRecordingInfo::Read(void), anyway.
Klaus
I wonder who is actually calling cRecordingInfo::Read(FILE *f) with
a NULL pointer? In VDR's own code all calls to that function are made sure to get a non-NULL pointer:
Yes, the real reason is in the vdrrip plugin that I cloned from http://projects.vdr-developer.org/git/
It has this kind of code which always assumes that info file always exist.
void cMovie::setLengthVDR() { char *infoFile = NULL; asprintf(&infoFile, "%s%s", Dir, OldRecording ? "/info.vdr" : "/info"); dsyslog ("[vdrrip] reading recording info %s ",infoFile); cRecordingInfo *crec = new cRecordingInfo(Dir); FILE *f = fopen(infoFile, "r"); if (crec->Read(f)) {
I just thought that it would be good to fix that in vdr code also. But I think putting the metod now private will also quarantee NULL pointer check :-)
Mika