 |
» |
|
|
|
|  | |
The HP-UX system writes out a file containing a core image
of a terminated process when certain signals are received (see signal(5) for
the list of reasons). The most common causes are memory violations,
illegal instructions, floating point exceptions, bus errors, and
user-generated quit signals. The core image file is called core and is written in the process's working directory (provided
it is allowed by normal access controls). A process with an effective
user ID different from its real user ID does not produce a core image. Summary
of Change | |
What’s
New for Customers Migrating from HP-UX 11i v1 September 2005?The core(4) manpage
requires the CORE_KERNEL segment of the
application core file contain a null-terminated kernel version string.
This was incorrectly implemented in HP-UX 11i v2 and earlier releases
by placing the utsname struct in that segment. Utsname
struct does contain the OS version string but not as
its first element. Applications accessing the first (and what should
be the only) string in the segment instead get the name of the OS, “HP-UX.” HP
has fixed that by putting the true version string, and only that,
in the CORE_KERNEL segment. As a work-around
for applications which reversed engineered the core file format
and depend on utsname being in it, HP has added a new segment, CORE_UTSNAME,
containing the expanded utsname struct. What’s
New for Customers Migrating from HP-UX 11i v2 June 2006? The core(4) manpage
requires the CORE_KERNEL segment of the
application core file contain a null-terminated kernel version string.
This was incorrectly implemented in HP-UX 11i v2 and earlier releases
by placing the utsname struct in that segment. Utsname
struct does contain the OS version string but not as
its first element. Applications accessing the first (and what should
be the only) string in the segment instead get the name of the OS, “HP-UX.” HP
has fixed that by putting the true version string, and only that,
in the CORE_KERNEL segment. As a work-around
for applications which reversed engineered the core file format
and depend on utsname being in it, HP has added a new segment, CORE_UTSNAME,
containing the expanded utsname struct. In the HP-UX September 2004 release, the above change was
introduced but governed by the private kernel tunable core_large_utsname_on. The default for this tunable was OFF which
meant the old core file format was generated. Only if a customer
explicitly turned this tunable ON did they
get the new format as described above. This private tunable was
publicized to customers as part of the then optional Interface Expansion functionality. What has changed between HP-UX September 2004 (or HP-UX June
2006) and HP-UX 11i v3 is that the tunable has been removed and
the new core file format is now the default (and only) format. Impact | |
Applications which read the core file, generally debuggers,
and which are ill-behaved are potentially impacted in two ways.
The first is that applications which expected and used a utsname struct in the CORE_KERNEL segment will
no longer find it there. The impact on the application could range
from inability to display some system related data in its output
to an abort of the application. The second is that applications
might be (poorly) coded to abort if they encounter a core file with
a segment type they were not expecting. Ill-behaved applications with one or both of these issues
will have to modify their implementation to function correctly with
this change. End-user customers using such applications will need to get
a corrected application from their supplier or switch to a different
application. Compatibility | |
There are no incompatibilities but there is the possibility
that a very restricted set of ill-behaved applications might be
impacted as described in the “Impact” section. Performance | |
There is no known impact on performance. Documentation | |
For further information, see the core(4) manpage (note, however,
that there is no change to this manpage). Obsolescence | |
Not applicable. |
Printable version
