Am 06.12.24 um 20:51 schrieb Marko Mäkelä:
Sun, Dec 01, 2024 at 08:55:45PM +0100, schorpp wrote:
(gdb) print ptsValues[0]
$1 = 3600
(gdb) print framesPerPayloadUnit
$2 = 1
(gdb) print parser->iFrameTemporalReferenceOffset
$3 = -1
Okay, this looks like a straightforward division by zero, which in fact
should have been fixed more than 10 years ago in VDR 2.1.7. Which
version of VDR are you using again?
2.0.6 ^^
commit 57222002b2b48baa9f5c8d0f253184801ba7200a
Author: Klaus Schmidinger <vdr@xxxxxxx>
Date: Sun Apr 13 13:50:04 2014 +0200
Fixed a possible division by zero in frame rate detection
which repository is this? I did not know Klaus is working with github?
I'll see if I can apply this patch manually.
As far as I can tell, this fix is also preventing a division by a
negative number, which would have been another thinkable source of SIGFPE.
In your register output, we have a zero divisor in ecx:
(gdb) info registers
...
ecx 0x0 0
...
(gdb) disassemble
...
0x08136f4d <+1021>: mov 0x80(%esp),%ecx
0x08136f54 <+1028>: xor %edx,%edx
0x08136f56 <+1030>: mov 0x288(%ecx),%esi
0x08136f5c <+1036>: mov %ecx,%eax
0x08136f5e <+1038>: mov 0xc(%eax),%eax
0x08136f61 <+1041>: mov 0x280(%ecx),%ecx
0x08136f67 <+1047>: add 0x8(%esi),%ecx
=> 0x08136f6a <+1050>: div %ecx
There is some loading of registers from the stack, as well as zeroing
out the more significant 32 bits of the dividend (edx). The dividend was
calculated right before the division.
Understood, thanks.
Marko
y
tom
