Am 19.11.24 um 08:21 schrieb Marko Mäkelä:
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?
No, some break in to show that debug symbols are available now.
"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.
I know, thanks.
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.
Maybe.
If gdb is attached to the vdr process the bug does not occur, if it is
not attached the SIGFPE occours intermittently on first recording start,
it does not occour on subsequent recording starts.
I'll set ulimit -c unlimit in runvdr script to get a core dump for gdb
if available for SIGFPE.
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.
*** 2.0.6-6yavdr1~woprr 0
100 /var/lib/dpkg/status
These are my installed self compiled vdr debug and release debian
packages from source packages of
2.0.6-6yavdr1 0
995 http://ppa.launchpad.net/yavdr/stable-vdr/ubuntu/
precise/main i386 Packages
Marko
y
tom
