On my Raspberry Pi 2, I observed that VDR 2.6.9 (with the rpihddevice
plugin) would hit SIGSEGV due to dereferencing a null pointer:
#0 __GI_strlen () at ../sysdeps/arm/armv6/strlen.S:26
#1 0x76a9b434 in __GI___strdup (s=0x0) at strdup.c:41
#2 0x000ff354 in cRecording::cRecording (this=0x196cab0, FileName=0x0) at recording.c:919
#3 0x00100978 in cRecordings::DelByName (this=this@entry=0x1dd13c <cRecordings::recordings>, FileName=0x0) at recording.c:1699
#4 0x000d92f8 in cMenuRecordings::Delete (this=0x17bf200) at tools.h:188
#5 0x000e755c in cOsdMenu::ProcessKey (this=this@entry=0x1963be8, Key=Key@entry=kYellow) at osdbase.c:535
#6 0x000d640c in cMenuMain::ProcessKey (this=0x1963be8, Key=kYellow) at menu.c:4606
#7 0x000749a0 in main (argc=<optimized out>, argv=<optimized out>) at vdr.c:1419
To reproduce:
1. Start cutting a recording "name" (DVB-T2, H.264 in my case).
2. Delete the original recording.
3. Attempt to delete "%name", which still appears in the menu.
Note: At the time of the crash, an empty subdirectory "%name" will exist.
Because I am not familiar with this part of the code and I don't think
that https://rr-project.org would work in this environment, I did not
try to find the exact root cause or try to develop a fix. I assume that
cCutter would have removed the "%name/2024-08-*.rec" directory as soon
as it noticed that the "name" recording had disappeared. It failed to
remove "%name" or the corresponding Recordings menu entry.
Best regards,
Marko