Re: Using vdr-dpg package for bug hunting?

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