Mail Archives: djgpp/1996/05/13/06:52:36
On 11 May 1996, John Mamer wrote:
> When I run the program by itself (in a terminal window under windows 3.1), I
> get the following response (after running symify):
>
>
> Exiting due to signal SIGFPE
> Floating Point exception at eip=000292fc
> eax=0032d9cc ebx=00000004 ecx=00331a00 edx=0000006c esi=0000006c edi=00000004
> ebp=0032d9cc esp=0032c614 cs=00af ds=00b7 es=00b7 fs=008f ss=00b7
> Call frame traceback EIP's:
> 0x000292fc __doprnt+1432
> 0x00026a75 _fprintf +105
> 0x00023ea2 _dotab+614, line 1568 of lpxaux.c
> ....(more of my functions here)
It could be that you are trying to print a double variable whose value is
not a valid FP number, like if you'd take a pointer or an uninitialized
memory location and try to print it as if it were a double. Maybe the
program relies on the fact that uninitialized memory is zeroed. In any
case you should debug the program using the stack trace to see what kind
of value are you trying to print. Under GDB the memory layout is
different, so uninitialized variables get other values.
There are a couple of features that you might find handy. First, you can
control the behavior of the FPU using the `_control87' library function.
This will allow you to run the program without generating the exception,
so you could see the value of the variable you are trying to print
(expect to see something pretty ugly, or a NaN). `_control87' is
described in the C library reference.
Second, you can set several bits in the startup flags to control the
contents of uninitialized memory. The bits are also explained in the libc
reference, under `_crt0_startup_flags'. For more info on this, read
section 9.1 of the DJGPP FAQ list (v2/faq200b.zip from the same place you
get DJGPP).
- Raw text -