Conference turris::digital_unix

9879.0. "Customer Questions" by MIASYS::SAVASTANO () Mon May 19 1997 15:03

May 19, 1997

  The following is from a customers porting consultant.  Any
suggestions would be helpful.

  Rick

========================================================================
     ...
     However, I am still finding some areas of undesirable behavior with
     inexact numbers. For example, casting an inexact floating point
     number into an integer returns 0 even under the ieee mode. On sun
     and other platforms, casting infinity to int will get you INT_MAX.

  There is a new issue I am facing now with the 4.0B machine though.
  It is quite unstable. It has crashed 5 times in the past week. And I
  even found a repeatable way to panic the machine. When I run gdb
  (yes, I know it could be a cygnus problem), the machine crashes
  in kernel code. I don't know how a process in user address space could
  trigger such repeatable failures of the kernel. If it means anything,
  here is the  error message I get on the console:

    trap: invalid memory write access from kernel mode
        faulting virtual address: 0xffffffffffff8da5
        pc of faulting instruction: 0xfffffc003fe08da0
        ra contents at time of fault: 0xfffffc000051671c
        sp contents at time of fault: 0xffffffffa8ffb0a8

  Is this a known problem? Is there a fix for this? Any help would be
  appreciated.

  Without the ability to run a debugger, I am currently forced to
  develop on the more stable 3.2 machine in spite of the linker problems
  there.

============================================================================

    Hi Rick
    
    Well first, the base note describes two separate problems, so it might
    have helped to post two separate notes with more descriptive titles.
    That way, you might attract readers' attention.
    
    Anyway, the problems ...
    
    (1) undesirable behavior with inexact numbers
    
    Can this consultant provide you with a _short_ reproducer, i.e. a few
    lines of code to illustrate the behaviour he's seen?  Can you reproduce
    the behaviour yourself?
    
    (2) trap: invalid memory write access from kernel mode
    
    The information he's provided is insufficient to determine the cause of
    the crash.  A stack trace of the crashing CPU would be useful.
    
    Ask him to send you the /var/adm/crash/crash-data.N file.
    Then mail it to the CANASTA mail account (I don't remember the address
    off-hand but several notes here refer to it).
    Or see if you can work out the cause yourself.  Or log a call with the
    CSC.
    
    If he can crash the system with an application, you might want to try
    it yourself, but please don't post the "crasher" in any public places!
    
    
    So in conclusion, the consultant should provide a lot more information
    if he expects Digital to address his problems.
    
    Hope this helps
    
    	leon

    The gdb induced crash is known and fixed in the latest V4.0b
    patch kit.