Fri, Nov 15, 2024 at 07:43:35PM +0100, schorpp wrote:
bt full / thread apply all bt
#2 0x081330f4 in cRemote::Get (WaitMs=10, UnknownCode=0x0) at remote.c:194
MutexLock = {mutex = 0x822feb0, locked = true}
#3 0x080f225b in cInterface::GetKey (this=0x9ee02c8, Wait=<optimized
out>) at interface.c:41
No locals.
#4 0x080aeda3 in main (argc=0, argv=<optimized out>) at vdr.c:1066
Is this really the only thread? "thread apply all backtrace" should show
the stack traces of all threads. There is also "info threads". This
seems to be the main thread, waiting for input from the remote control.
Strange is the the bug does no more occur using the vdr-dbg exe?
Maybe the vdr-dbg has been built with different options, such as without
some optimizations. It could affect the timing enough, if this is
related to some race condition.
I think that you should ask the maintainer of that repository if the
debug information for your normal "vdr" package are available somewhere.
Alternatively, try to compile vdr yourself, slightly changing the build
script so that the debug information will be included.
It is not that hard to compile VDR. Even my Raspberry Pi 2 can do it in
a few minutes.
Marko
