PM10350: Ada program encounters SEGV, no core file is generated

APAR status

• Closed as program error.

Error description

• The SIGSEGV behavior of an Apex program is different for differe
  nt platforms:
  
  The sparc Solaris runtime system behavior depends on the Storage
  _Signal_Enabled flag in the configuration table.   This can be s
  et in V_Usr_Conf or using pragma Main.  The default is True, whi
  ch means that the Apex runtime installs a signal handler that al
  ways converts SIGSEGV to an Ada exception. The runtime only inst
  alls a handler for SIGSEGV if Storage_Signal_Enabled is True, so
   the default treatment will be preserved. In other words, if the
  re is no user or third party signal handler attached, a core fil
  e will be generated.
  
  The Apex runtime for i386 Linux behaves like sparc Solaris if th
  e Storage_Signal_Enabled flag is True. If the flag is False, the
   runtime still catches SIGSEGV, since Linux uses it for overflow
   and bounds check.  However, if Storage_Signal_Enabled is False
  and the runtime handler determines that it's neither of those it
   restores the default treatment for SIGSEGV and returns.
  
  The ix86 Solaris (also called 'S32') runtime is based on those f
  or sparc Solaris and i386 Linux, but different than either. The
  SIGSEGV behavior of S32 is similar to Linux, except that it lack
  s the bail out to the default treatment if the SIGSEGV is not co
  nverted to an Ada exception.  If the SIGSEGV was not engendered
  by a bounds error or by an explicit 'raise Storage_Error' it pan
  ics.  Storage_Signal_Enabled has no effect on the treatment of S
  IGSEGV.
  
  Possible Workarounds:
  The only real workaround that would allow consistent behavior ac
  ross all platforms would be to plug in your own signal handler f
  or SIGSEGV. For the Linux and S32 platforms, the user handler wo
  uld need to test for the conditions that the Ada runtime needs t
  o handle, and chain to the Ada runtime's handler so that normal
  Ada semantics would be satisfied. Otherwise, your handler would
  chain to SIG_DFL to produce the default OS behavior (core dump).
   This workaround is probably impractical, because the amount of
  work to implement it is roughly the same as the work to implemen
  t the permanent fix.
  
  A simplistic workaround would be to use another signal, such as
  SIGABRT, instead of SIGSEGV for your testing. If you have some k
  ind of requirement to use SIGSEGV, this workaround would not be
  useful.
  
  A somewhat dirtier version of the first workaround would be to p
  lug the SIG_DFL handler into SIGSEGV. That would cause a core du
  mp for any SIGSEGV, but would break Ada semantics on Linux and S
  32, because failing a bounds check would generate a core dump in
  stead of an Ada exception.
  

Local fix

Problem summary

• SIGSEGV not handled poperly on Solaris x86
  

Problem conclusion

• The Apex Solaris X86 runtime
  handler for SIGSEGV
  has been corrected
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  ADA DEV EE UNIX

• Fixed component ID

  5724G1501

Applicable component levels

• R42S PSN

     UP