Re: Using vdr-dpg package for bug hunting?

Sun, Dec 01, 2024 at 02:18:02PM +0100, schorpp wrote:
>HA! I've got this bitch of intermittent bug finally:
>
>Program received signal SIGFPE, Arithmetic exception.
>[Switching to Thread 0xad0ffb40 (LWP 27522)]
>0x08136f6a in cFrameDetector::Analyze (this=0x9ade480, Data=<optimized 
>out>, Length=296852) at remux.c:1567
>1567	                       uint32_t Delta = ptsValues[0] / 
>(framesPerPayloadUnit +  parser->IFrameTemporalReferenceOffset());

It would have been useful to include the disassembly of the function.
Maybe alos the output fo the following, if the values are known to the 
debugger:

print ptsValues[0]
print framesPerPayloadUnit
print parser->iFrameTemporalReferenceOffset

I was curious about this. I am able to reproduce SIGFPE on both x86-64 
and i386 when compiling the following C program without optimization:

#include <stdint.h>
#include <stdio.h>
#include <inttypes.h>
int main()
{
   int a = 0, b = -1;
   uint32_t pts = 1U << 31;
   int32_t delta = ((int32_t)pts) / (a + b);
   printf("%" PRIi32 "\n", delta);
   return 0;
}

Initially I had "uint32_t delta" and no type cast, and PRIu32, to 
exactly match the data types that are involved in VDR. That variant 
would produce the incorrect result 0. This of course is a bad 
approximation for the code in VDR, because above it is possible to 
perform all the arithmetics at compilation time. In VDR, the values 
would be determined at runtime.

Curiously, if I compile the above program with GCC 14.2.0 -O2, then it 
will return the incorrect result -2147483648 instead of an approximation 
like 2147483647 (which would be one less than the correct result, which 
cannot be represented in int32_t). If I look at the disassembly, the 
compiler would have performed an incorrect constant folding for "delta".

If I compile the program with -fsanitize=undefined, it will flag an 
error:

runtime error: division of -2147483648 by -1 cannot be represented in type 'int'

For the non-optimized case, for both i386 and x86-64, I see that the 
SIGFPE is being raised by an idiv instruction that is preceded by ctld 
a.k.a. cdq: https://www.felixcloutier.com/x86/cwd:cdq:cqo

>Aussume it is a divide by zero exception?

I don't know if your case involves the idiv instruction, but 
https://www.felixcloutier.com/x86/idiv mentions that #DE may be raised 
both on a division by zero and on overflow.

Can you post the output of "disassemble" and "info registers" for the 
innermost stack frame?

	Marko