Debug problem when step debug float point instruction that raise an float point exception

Debug problem when step debug float point instruction that raise an float point exception

Post by Sky walke » Wed, 01 Mar 2000 04:00:00



Hi All,

I have a program which use _control87 and signal function to set handle
function for float point exception. The program runs fine if it's not in
debug environment.
However, In Windows 98, If I debug the program in VC IDE, It always
cause an 0x0E exception when I step the line "r = n1 / n2" which cause a
divid zero exception, after that, I must restart Windows 98 to recover
the system. While if I don't step this line and just go through it, the
program runs fine and both the program and VC de* can handle the
float point exception correctlly.

The problem doesn't exist in Windows NT 4.

The 0x0E exception is occurred exactlly when I step over the float point
instruction FDIV in VC de*. According to some documentation, the
float point exception aren't raised until the next float point
instruction after the actual bad instruction. I supposed that kernel
debug interrupt routine may use some float point instruction, hence CPU
will raise an float point exception inside debug interrupt handler, the
nested interrupt may cause VC de* work incorrectly.

At fiste, I suspend that the problem may caused by setjmp/longjmp, but
even if I use structure exception handler to handle float point
exception, the problem still exist.

Is it a VC de* problem or Windows 98 system limitation (because it
doesn't handle debug interrupt gracefully). Could any one kindly help me
regarding this question?

The following is my code.

/* FPRESET.C: This program uses signal to set up a
 * routine for handling floating-point errors.
 */

#include <stdio.h>
#include <signal.h>
#include <setjmp.h>
#include <stdlib.h>
#include <float.h>
#include <math.h>
#include <string.h>

jmp_buf mark;              /* Address for long jump to jump to */
int     fperr;             /* Global error number */

void __cdecl fphandler( int sig, int num );   /* Prototypes */
void fpcheck( void );

void main( void )
{
   double n1, n2, r;
   int jmpret;
   /* Unmask all floating-point exceptions. */
    _control87( 0, _MCW_EM );
   /* Set up floating-point error handler. The compiler
    * will generate a warning because it expects
    * signal-handling functions to take only one argument.
    */
    if( signal( SIGFPE, fphandler ) == SIG_ERR )

   {
      fprintf( stderr, "Couldn't set SIGFPE\n" );
      abort();   }

   /* Save stack environment for return in case of error. First
    * time through, jmpret is 0, so true conditional is executed.
    * If an error occurs, jmpret will be set to -1 and false
    * conditional will be executed.
    */
   jmpret = setjmp( mark );
   if( jmpret == 0 )
   {
      printf( "Test for invalid operation - " );
      printf( "enter two numbers: " );
      scanf( "%lf %lf", &n1, &n2 );
      r = n1 / n2;
      /* This won't be reached if error occurs. */
      printf( "\n\n%4.3g / %4.3g = %4.3g\n", n1, n2, r );

      r = n1 * n2;
      /* This won't be reached if error occurs. */
      printf( "\n\n%4.3g * %4.3g = %4.3g\n", n1, n2, r );
   }
   else
      fpcheck();

Quote:}

/* fphandler handles SIGFPE (floating-point error) interrupt. Note
 * that this prototype accepts two arguments and that the
 * prototype for signal in the run-time library expects a signal
 * handler to have only one argument.
 *
 * The second argument in this signal handler allows processing of
 * _FPE_INVALID, _FPE_OVERFLOW, _FPE_UNDERFLOW, and
 * _FPE_ZERODIVIDE, all of which are Microsoft-specific symbols
 * that augment the information provided by SIGFPE. The compiler
 * will generate a warning, which is harmless and expected.

 */
void fphandler( int sig, int num )
{
   /* Set global for outside check since we don't want
    * to do I/O in the handler.
    */
   fperr = num;
   /* Initialize floating-point package. */
   _fpreset();
   /* Restore calling environment and jump back to setjmp. Return
    * -1 so that setjmp will return false for conditional test.
    */
   longjmp( mark, -1 );

Quote:}

void fpcheck( void )
{
   char fpstr[30];
   switch( fperr )
   {
   case _FPE_INVALID:
       strcpy( fpstr, "Invalid number" );
       break;
   case _FPE_OVERFLOW:
       strcpy( fpstr, "Overflow" );

       break;
   case _FPE_UNDERFLOW:
       strcpy( fpstr, "Underflow" );
       break;
   case _FPE_ZERODIVIDE:
       strcpy( fpstr, "Divide by zero" );
       break;
   default:
       strcpy( fpstr, "Other floating point error" );
       break;
   }
   printf( "Error %d: %s\n", fperr, fpstr );

Quote:}

 
 
 

Debug problem when step debug float point instruction that raise an float point exception

Post by Sky walke » Wed, 01 Mar 2000 04:00:00


Hi All,

I have a program which use _control87 and signal function to set handle
function for float point exception. The program runs fine if it's not in
debug environment.
However, In Windows 98, If I debug the program in VC IDE, It always
cause an 0x0E exception when I step the line "r = n1 / n2" which cause a
divid zero exception, after that, I must restart Windows 98 to recover
the system. While if I don't step this line and just go through it, the
program runs fine and both the program and VC de* can handle the
float point exception correctlly.

The problem doesn't exist in Windows NT.

The 0x0E exception is occurred exactlly when I step over the float point
instruction FDIV in VC de*. According to some documentation, the
float point exception aren't raised until the next float point
instruction after the actual bad instruction. I supposed that kernel
debug interrupt routine may use some float point instruction, hence CPU
will raise an float point exception inside debug interrupt handler, the
nested interrupt may cause VC de* work incorrectly.

At fiste, I suspend that the problem may caused by setjmp/longjmp, but
even if I use structure exception handler to handle float point
exception, the problem still exist.

Is it a VC de* problem or Windows 98 system limitation (because it
doesn't handle debug interrupt gracefully). Could any one kindly help me
regarding this question?

Best regards,

The following is my code.

/* FPRESET.C: This program uses signal to set up a
 * routine for handling floating-point errors.
 */

#include <stdio.h>
#include <signal.h>
#include <setjmp.h>
#include <stdlib.h>
#include <float.h>
#include <math.h>
#include <string.h>

jmp_buf mark;              /* Address for long jump to jump to */
int     fperr;             /* Global error number */

void __cdecl fphandler( int sig, int num );   /* Prototypes */
void fpcheck( void );

void main( void )
{
   double n1, n2, r;
   int jmpret;
   /* Unmask all floating-point exceptions. */
    _control87( 0, _MCW_EM );
   /* Set up floating-point error handler. The compiler
    * will generate a warning because it expects
    * signal-handling functions to take only one argument.
    */
    if( signal( SIGFPE, fphandler ) == SIG_ERR )

   {
      fprintf( stderr, "Couldn't set SIGFPE\n" );
      abort();   }

   /* Save stack environment for return in case of error. First
    * time through, jmpret is 0, so true conditional is executed.
    * If an error occurs, jmpret will be set to -1 and false
    * conditional will be executed.
    */
   jmpret = setjmp( mark );
   if( jmpret == 0 )
   {
      printf( "Test for invalid operation - " );
      printf( "enter two numbers: " );
      scanf( "%lf %lf", &n1, &n2 );
      r = n1 / n2;
      /* This won't be reached if error occurs. */
      printf( "\n\n%4.3g / %4.3g = %4.3g\n", n1, n2, r );

      r = n1 * n2;
      /* This won't be reached if error occurs. */
      printf( "\n\n%4.3g * %4.3g = %4.3g\n", n1, n2, r );
   }
   else
      fpcheck();

Quote:}

/* fphandler handles SIGFPE (floating-point error) interrupt. Note
 * that this prototype accepts two arguments and that the
 * prototype for signal in the run-time library expects a signal
 * handler to have only one argument.
 *
 * The second argument in this signal handler allows processing of
 * _FPE_INVALID, _FPE_OVERFLOW, _FPE_UNDERFLOW, and
 * _FPE_ZERODIVIDE, all of which are Microsoft-specific symbols
 * that augment the information provided by SIGFPE. The compiler
 * will generate a warning, which is harmless and expected.

 */
void fphandler( int sig, int num )
{
   /* Set global for outside check since we don't want
    * to do I/O in the handler.
    */
   fperr = num;
   /* Initialize floating-point package. */
   _fpreset();
   /* Restore calling environment and jump back to setjmp. Return
    * -1 so that setjmp will return false for conditional test.
    */
   longjmp( mark, -1 );

Quote:}

void fpcheck( void )
{
   char fpstr[30];
   switch( fperr )
   {
   case _FPE_INVALID:
       strcpy( fpstr, "Invalid number" );
       break;
   case _FPE_OVERFLOW:
       strcpy( fpstr, "Overflow" );

       break;
   case _FPE_UNDERFLOW:
       strcpy( fpstr, "Underflow" );
       break;
   case _FPE_ZERODIVIDE:
       strcpy( fpstr, "Divide by zero" );
       break;
   default:
       strcpy( fpstr, "Other floating point error" );
       break;
   }
   printf( "Error %d: %s\n", fperr, fpstr );

Quote:}


 
 
 

Debug problem when step debug float point instruction that raise an float point exception

Post by Sky walke » Wed, 01 Mar 2000 04:00:00


Hi All,

I have a program which use _control87 and signal function to set handle
function for float point exception. The program runs fine if it's not in
debug environment.
However, In Windows 98, If I debug the program in VC IDE, It always
cause an 0x0E exception when I step the line "r = n1 / n2" which cause a
divid zero exception, after that, I must restart Windows 98 to recover
the system. While if I don't step this line and just go through it, the
program runs fine and both the program and VC de* can handle the
float point exception correctlly.

The problem doesn't exist in Windows NT.

The 0x0E exception is occurred exactlly when I step over the float point
instruction FDIV in VC de*. According to some documentation, the
float point exception aren't raised until the next float point
instruction after the actual bad instruction. I supposed that kernel
debug interrupt routine may use some float point instruction, hence CPU
will raise an float point exception inside debug interrupt handler, the
nested interrupt may cause VC de* work incorrectly.

At fiste, I suspend that the problem may caused by setjmp/longjmp, but
even if I use structure exception handler to handle float point
exception, the problem still exist.

Is it a VC de* problem or Windows 98 system limitation (because it
doesn't handle debug interrupt gracefully). Could any one kindly help me
regarding this question?

Best regards,

Guangjun Zhou

The following is my code.

/* FPRESET.C: This program uses signal to set up a
 * routine for handling floating-point errors.
 */

#include <stdio.h>
#include <signal.h>
#include <setjmp.h>
#include <stdlib.h>
#include <float.h>
#include <math.h>
#include <string.h>

jmp_buf mark;              /* Address for long jump to jump to */
int     fperr;             /* Global error number */

void __cdecl fphandler( int sig, int num );   /* Prototypes */
void fpcheck( void );

void main( void )
{
   double n1, n2, r;
   int jmpret;
   /* Unmask all floating-point exceptions. */
    _control87( 0, _MCW_EM );
   /* Set up floating-point error handler. The compiler
    * will generate a warning because it expects
    * signal-handling functions to take only one argument.
    */
    if( signal( SIGFPE, fphandler ) == SIG_ERR )

   {
      fprintf( stderr, "Couldn't set SIGFPE\n" );
      abort();   }

   /* Save stack environment for return in case of error. First
    * time through, jmpret is 0, so true conditional is executed.
    * If an error occurs, jmpret will be set to -1 and false
    * conditional will be executed.
    */
   jmpret = setjmp( mark );
   if( jmpret == 0 )
   {
      printf( "Test for invalid operation - " );
      printf( "enter two numbers: " );
      scanf( "%lf %lf", &n1, &n2 );
      r = n1 / n2;
      /* This won't be reached if error occurs. */
      printf( "\n\n%4.3g / %4.3g = %4.3g\n", n1, n2, r );

      r = n1 * n2;
      /* This won't be reached if error occurs. */
      printf( "\n\n%4.3g * %4.3g = %4.3g\n", n1, n2, r );
   }
   else
      fpcheck();

Quote:}

/* fphandler handles SIGFPE (floating-point error) interrupt. Note
 * that this prototype accepts two arguments and that the
 * prototype for signal in the run-time library expects a signal
 * handler to have only one argument.
 *
 * The second argument in this signal handler allows processing of
 * _FPE_INVALID, _FPE_OVERFLOW, _FPE_UNDERFLOW, and
 * _FPE_ZERODIVIDE, all of which are Microsoft-specific symbols
 * that augment the information provided by SIGFPE. The compiler
 * will generate a warning, which is harmless and expected.

 */
void fphandler( int sig, int num )
{
   /* Set global for outside check since we don't want
    * to do I/O in the handler.
    */
   fperr = num;
   /* Initialize floating-point package. */
   _fpreset();
   /* Restore calling environment and jump back to setjmp. Return
    * -1 so that setjmp will return false for conditional test.
    */
   longjmp( mark, -1 );

Quote:}

void fpcheck( void )
{
   char fpstr[30];
   switch( fperr )
   {
   case _FPE_INVALID:
       strcpy( fpstr, "Invalid number" );
       break;
   case _FPE_OVERFLOW:
       strcpy( fpstr, "Overflow" );

       break;
   case _FPE_UNDERFLOW:
       strcpy( fpstr, "Underflow" );
       break;
   case _FPE_ZERODIVIDE:
       strcpy( fpstr, "Divide by zero" );
       break;
   default:
       strcpy( fpstr, "Other floating point error" );
       break;
   }
   printf( "Error %d: %s\n", fperr, fpstr );

Quote:}

 
 
 

Debug problem when step debug float point instruction that raise an float point exception

Post by Slava M. Uso » Wed, 01 Mar 2000 04:00:00


[...]

Quote:>    /* Unmask all floating-point exceptions. */
>     _control87( 0, _MCW_EM );
>    /* Set up floating-point error handler. The compiler
>     * will generate a warning because it expects
>     * signal-handling functions to take only one argument.
>     */
>     if( signal( SIGFPE, fphandler ) == SIG_ERR )

There is a far better way to handle FPU exceptions. Check out the
documentation on _fpieee_flt().

And please don't post HTML messages.

--

Slava

Please send any replies to this newsgroup.
microsoft.public.win32.programmer.kernel

 
 
 

Debug problem when step debug float point instruction that raise an float point exception

Post by Sky walke » Thu, 02 Mar 2000 04:00:00


I have already tried SEH and _fpieee_flt to handle float point
exception, the result is same as signal and setjmp.
I think there is no difference between internal implementation of SEH
and signal and setjmp, the problem may be the Window 98 limitation or a
bug of VC de*.

The 0x0E exception is occurred just when I single step the floating
point instruction FDIV in VC de*.

According to intel documentation, when a floating-point exception is
unmasked and the exception condition occurs, the FPU stops further
execution of the floating-point instruction and signals the exception
event. On the next occurrence of a floating-point instruction or a
WAIT/FWAIT instruction in the instruction stream the processor checks
the ES flag in the FPU status word for pending floating-point
exceptions. If floating-point exceptions are pending, the FPU maskes an
implicit call (traps) to the floating-point exception handler. The
exception handler can then execute recovery procedures for selected or
all floating-point exceptions.

I have tried to trace into kernel code and see what happened when I
single step in VC de*, when single step the floating point
instruction FDIV in VC de*, The debug exception (interrupt vertor
No. 1) will raised just before floating-point exception (interrupt
vertor No. 16), It seems that 0x0E Page Fault is raised when Windows 98
handle the debug exception.

Thanks



> [...]

> >    /* Unmask all floating-point exceptions. */
> >     _control87( 0, _MCW_EM );
> >    /* Set up floating-point error handler. The compiler
> >     * will generate a warning because it expects
> >     * signal-handling functions to take only one argument.
> >     */
> >     if( signal( SIGFPE, fphandler ) == SIG_ERR )

> There is a far better way to handle FPU exceptions. Check out the
> documentation on _fpieee_flt().

> And please don't post HTML messages.

> --

> Slava

> Please send any replies to this newsgroup.
> microsoft.public.win32.programmer.kernel

 
 
 

Debug problem when step debug float point instruction that raise an float point exception

Post by Slava M. Uso » Thu, 02 Mar 2000 04:00:00



Quote:> I have already tried SEH and _fpieee_flt to handle float point
> exception, the result is same as signal and setjmp.
> I think there is no difference between internal implementation of SEH
> and signal and setjmp, the problem may be the Window 98 limitation or a
> bug of VC de*.

Probbaly. I suggested that because handling of FPU exceptions with SEH
looked a whole lot cleaner to me.

Quote:> The 0x0E exception is occurred just when I single step the floating
> point instruction FDIV in VC de*.

> According to intel documentation, when a floating-point exception is
> unmasked and the exception condition occurs, the FPU stops further
> execution of the floating-point instruction and signals the exception
> event. On the next occurrence of a floating-point instruction or a
> WAIT/FWAIT instruction in the instruction stream the processor checks
> the ES flag in the FPU status word for pending floating-point
> exceptions. If floating-point exceptions are pending, the FPU maskes an
> implicit call (traps) to the floating-point exception handler. The
> exception handler can then execute recovery procedures for selected or
> all floating-point exceptions.

There is a twist... there're two modes of FPU exception handling, native,
which is what you described above, and the "MS-DOS* COMPATIBILITY MODE", to
which _The Intel Architecture Software Developer's Manual, Volume 1: Basic
Architecture_ (Order
Number 243190) says:

[begin quote]

This method of reporting floating-point errors and invoking an exception
handler is provided to support the floating-point exception handling
mechanism used in PC systems that are running the MS-DOS or Windows* 95
operating system.

[end quote]

Then it explains that basically the exceptional condition results in
immediate assertion of IRQ13 line and then, by default, PIC routes that to
INT 75H, handler of which, again by default, branches to INT 2 [NMI] and the
NMI handler then determines if that was caused by FPU and branches to FPU
exception handler. Win98 may depart from the defaults, though.

Whatever it does, it seems it does that incorrectly. In particular, it may
be confused that it has a debug trap and an external interrupt pending
simultaneously, and fail to determine that the external interrupt is related
to the debug trap and do a big oops.

I don't know what you can do to get around that, except the obvious "don't
do that".

--

Slava

Please send any replies to this newsgroup.
microsoft.public.win32.programmer.kernel

 
 
 

1. need help for debugging floating point overflow trap

hi,

I've got a c application thats getting terminated by windows 3.1 with a
"floating point overflow" message. Does anyone know how to trap this
prior to the app being blow away by windows?

Running with visual c++ integrated debugger.


Thanks.
                              Lenny Wintfeld

2. Help! Password/Security question.

3. Windows, Floating Point, and the IBM Value Point

4. NJ Assistance needed

5. Returing a float pointer that points to an array of floats

6. Local ISP installs X2

7. vectorizing for SIMD floating point instructions

8. Partition Magic v4---->v5?

9. Fixed-point or floating point for RTS

10. How to catch floating point exceptions (under Watcom C/386)?

11. MSVC : Trapping floating point exceptions !

12. floating point exceptions under windows

13. Windows Floating Point Exception?