Hi Klaus,
Thanks for debugging this! Please try whether this fixes it:
--- skinlcars.c +++ skinlcars.c @@ -900,6 +900,15 @@ ys03 = ys04 - Gap; ys05 = yb15;
- // The item area (just to have them initialized, actual setting will be done in SetMenuCategory():
- xi00 = 0;
- xi01 = 0;
- xi02 = 0;
- xi03 = 1;
- yi00 = 0;
- yi01 = 1;
- // The color buttons in submenus: xb00 = xa06; xb15 = xa07;
After applying this fix, the only Valgrind warnings I got from VDR were bogus-looking ones: the cRecording::cRecording (based on my reading of the disassembly, gcc's built-in version of strcmp() doing a 32-bit access that goes 2 bytes beyond the end of the string), and a few bogus-looking warnings on ioctl(). 3 of them were complaining about "invalid pointer" 0x0 or 0x1 for DirectFB calls, and the 4th one was this:
==7120== Syscall param ioctl(arg) contains uninitialised byte(s) ==7120== at 0x436AA99: ioctl (syscall-template.S:82) ==7120== by 0x80CB31A: cDvbDevice::SetPid(cDevice::cPidHandle*, int, bool) (dvbdevice.c:1394) ==7120== by 0x80C22B4: cDevice::DelPid(int, cDevice::ePidType) (device.c:544) ==7120== by 0x80C4047: cDevice::Detach(cReceiver*) (device.c:1690) ==7120== by 0x8116605: cReceiver::Detach() (receiver.c:89) ==7120== by 0x42B3E45: (below main) (libc-start.c:228)
CHECK(ioctl(Handle->handle, DMX_STOP));
#define CHECK(s) { if ((s) < 0) LOG_ERROR; } // used for 'ioctl()' calls
Given that Handle->handle is a signed integer (file handle), the Valgrind warning should be for DMX_STOP, which does not look like a pointer to me. Maybe the constant happens to coincide with the address of some memory block (not too hard with only 32 bits of address space). Or perhaps Valgrind is misinterpreting the number of arguments to ioctl().
I switched back to using LCARS, and did not experience any crashes yet after applying the patch, no matter how much I played with the Menu and Recordings buttons. So, the patch seems to work. Thank you!
Marko