Re: Using vdr-dpg package for bug hunting?

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 <[email protected]>
> 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