4    Development Environment Notes

This chapter contains notes about issues and known problems with the development environment software and, whenever possible, provides solutions or workarounds to those problems.

4.1    Some C Library Functions Have Two Versions

In this release of Digital UNIX, the following C library functions exist in two versions due to conflicts between previous versions of Digital UNIX (to maintain binary compatibility these interfaces remain the default in this version of Digital UNIX as well) and the recent X/Open Single UNIX Specification. The Single UNIX Specification interfaces will be used when the c89 command is used or when the C preprocessor symbol _XOPEN_SOURCE_EXTENDED is defined.

a64l          dbm_forder    getsockname   readv         sigaction
accept        dbm_nextkey   l64a          recvfrom      signal
basename      dbm_store     nftw          recvmsg       sigpause
dbm_delete    dirname       pipe          sendmsg       sigset
dbm_fetch     ftw           putmsg        setpgrp       ttyslot
dbm_firstkey  getpeername   putpmsg       setrlimit

The Single UNIX Specification interfaces are recommended for new designs and implementations. They will ensure portability of code on all UNIX platforms. In most cases the changes in the function will not require changes to the application source code using the function, just a recompilation.

4.2    Missing Debugger Information

When using the -g flag with the C compiler, debug information is not produced for small integer types (8-bit and 16-bit) in old-style function definitions. Correct code is generated, it is only the debugger information that is incomplete. The following example illustrates the types of definitions that will result in the missing information:

"int sub1(a, b, c)"
"int a;"
"short b;"
"char c;"
"{ ... }"

In this example, both b and c are small integer types, and sub1 has an old-style definition. The following example uses the new prototype-style definition, so there is no missing information:

"int sub1(int a, short b, char c)"

 

"{ ... }"

You will notice the missing information when using the where command in dbx as follows:

% cc -g dbx.c
% dbx a.out
(dbx) where
>  0 sub1(a = 1) ["dbx.c":1, 0x1200011c4]
1 main() ["dbx.c":11, 0x120001220]

The missing information can also cause a problem if using the dbx call command, as the debugger interprets sub1 as only having a single parameter:

(dbx) call sub1(5, 6, 7)
too many parameters in call to sub1

It is possible to work around this problem by converting to the ANSI C prototype style function definitions or by avoiding the small integer types as parameters in old-style function definitions. Alternatively, use the -oldc option when compiling.

4.3    DEC Ada Is Not Supported

DEC Ada is not supported in Digital UNIX Version 4.0.

4.4    Init Execution Order Modified

The execution order for init routines in static executables has been modified to more closely match the execution order for init routines in dynamic executables.

4.5    Using pixie on Applications Built with -om

If your application was built with the -om switch, you must use the previous version of pixie for performance analysis work on the application. This version is located in /usr/opt/obsolete/usr/bin/pixie.

The Atom-based tools, including a new version of pixie, cannot currently process executables produced with the -om switch. This is a limitation with the om utility which will be corrected in a future release.

4.6    pixie Command Can Fail to Locate atom Command

The /usr/bin/pixie command fails to invoke the atom command it needs, if the atom command's file is in the last directory in the process environment variable PATH.

The atom command is usually found in the /usr/bin and /bin directories, so when you use the pixie command, make sure that one of these is included in the value of your process's PATH and that it is not the last one.

The default .login and .profile files in /usr/skel (used to create new user accounts by adduser) define values for PATH that allow use of the pixie command in various shells.

The following code is included in the default .login file:

set path=($HOME/bin /usr/bin .)

The following code is included in the default .profile file:

PATH=$HOME/bin:${PATH:-/usr/bin:.}

4.7    c89 Command Conforms to Spec1170

The c89 command now conforms to the Spec1170 requirements for command option spelling. The old command syntax is also supported. See the updated c89 reference page for details.

4.8    Alternate Compiler Suite

The CMPDEVALT400 subset contains an alternate application compiler suite. The README file contained in the subset explains its use.

4.9    DEC C

The default C compiler on Digital UNIX has changed to Digital's DEC C compiler. The previous default C compiler, is still a supported viable option and can be accessed by specifying -oldc on the cc command line.

Much work has been done to minimize the differences between DEC C and the previous compiler. Both compilers have full binary compatibility with each other. This release note provides a list of differences that may be helpful for you to know as you begin to use DEC C in Digital UNIX version 4.0.

• DEC C offers many features that were not available with the previous compiler. See the cc(1) and c89(1) reference pages and the Programmer's Guide for details.

• Latent errors in your source code may be exposed with this new compiler. Several types of these that we have observed include:

  • When accessing unaligned short data types through pointers, you will get an unaligned access fault with DEC C and not with the previous compiler.

  • The stack frames generated by DEC C are packed much tighter than those of the previous compiler. Consequently, any code that overwrites stack data is much more likely to corrupt the next stack variable with DEC C than with the previous compiler.

  • The use of uninitialized variables that worked with the previous compiler are not guaranteed to work with DEC C.

  • If data structures are not properly aligned on their natural boundaries, runtime unaligned access faults will more likely result when compiled with DEC C.

  • Compiling undefined C programming constructs may produce different behaviour with DEC C. In C, some constructs are undefined by ANSI standards and their behaviour may differ when complied on DEC C instead of ACC.

• Parameter cleaning, which the previous compiler did by default in all modes, is not done by default in -std1 mode with DEC C. For more information, see -ansi_args in the cc(1) reference page.

• DEC C assumes the ANSI C aliasing rules are adhered to in the -std and -std1 modes, and as a result, allows the optimizer to perform more optimizations. The previous compiler did not perform these optimizations.

  If your program does access the same data through pointers of a different type (for example, by a pointer to int and a pointer to float), then you must not allow the compiler to assume ANSI C aliasing rules. Otherwise, incorrect code might be generated. See the cc(1) reference page for details.

• DEC C does not support the -j command line switch. Equivalent functions are provided by either the -ifo or the -O<n> switches, where <n> is a number.

• By default, when no optimization level is specified, DEC C does perform a few more optimizations than the previous compiler did. See the cc(1) reference page for details.

• If your link line did not require linking with libc in the past, it may be required now as DEC C utilizes _Ots support routines found in libc. Prior to this release, these support routines were in libots.

• DEC C defines the __DECC macro whenever it is used to compile C programs.

• The maximum length for external names allowed by DEC C is 1024 characters. The previous compiler allowed longer external names.

4.9.1    Remove the DEC C -migrate Switch

If you are currently using DEC C with the -migrate switch, Digital encourages you to remove this option and use the default cc.

Removal is recommended because:

• The optimization switches have different mappings. See the cc(1) reference page for more information.

• You no longer need to explicitly link with the libots library. The libots routines used by DEC C now reside in libc.

If you call ld directly in the command string, replace the switch -lots with -lc.

4.9.2    Object File Address Reference Limit

There is a restriction with the DEC C compiler in that a single object file cannot contain more than 4093 external address references. The compiler will issue the following error message when compiling a module that exceeds this limit:

GP-relative section overflows limit of 32752 bytes

To workaround this problem break your module into smaller compilation units or use the -oldc compiler option.

4.10    DEC C -ifo Switch

When using the -ifo switch in DEC C, symbol information for external variables may be incorrect. For example:

% cat simple.c

 

int global_array[100][4];

 

main()
{
int local_array[100][4];
}

 

% cc -O1 -g2 -ifo simple.c
% dbx a.out
(dbx) whatis global_array
int global_array;
(dbx) whatis local_array
local_array[100][4] of int ;

Note that the global array is reported as int and the local array is a two dimensional array of ints. Both should report the same thing.

If this program is executed without -ifo, the results are as expected. The problem is in the generation of the symbol table, not the debugger.

4.11    XTI and TLI Libraries Are Thread-Safe

The libraries libxti.a, libtli.a, libxti.so, and libtli.so now support multithreaded applications. New xti.h (for XTI) and tiuser.h (for TLI) are available to be included by applications. Binary backwards compatibility has been preserved and unithreaded applications built with previous include files will still run.

4.12    DECladebug Product Name Change (Ladebug)

Note that the product name DECladebug has changed to Ladebug.

The release notes for Ladebug are in the subset OSFLDBDOC400 in the Digital UNIX V4.0 Operating System Volume 1 CD-ROM and can only be accessed when Ladebug is installed. After installation the release notes can be found in:

usr/doc/ladebug/ladebug-relnotes.txt

4.13    Analysis Tool with Object Modification (ATOM)

The following notes apply to the Analysis Tool with Object Modification utility atom.

4.13.1    Profiling Signal Handlers and fork with Multithreaded hiprof

A multithreaded program instrumented with the default hiprof command, atom appl_prog-tool hiprof -env threads will sometimes deadlock (enter an infinite polling and sleeping loop). This can happen if the program calls the signal, sigaction or fork function or if it was compiled with a cc -speculate ... command (which introduces signal handlers).

You can avoid this problem by adding the -toolargs=-calltime or the -toolargs='-calltime -threads' option to the command line.

For programs that call fork function, instrumenting libc.so is always recommended. You should also add the -all or -incobj libc.so option. Instrumenting libc.so also minimizes the risk of deadlock with the default command, hiprof.

If the default hiprof command must be used for a multithreaded program that calls the signal or sigaction and if libc.so must be profiled, add -exc __sigtramp -exc __Esigtramp to the -toolargs option used to exclude the signal handling procedures and any other procedures they call.

Alternatively, or when the program is compiled with a cc -speculate ... command, do not instrument libc.so by omitting -all or adding -excobj libc.so.

Similarly, if the application's signal handlers call many other procedures directly or indirectly (for example, in libc.so), the whole library can be excluded instead of excluding a long list of individual procedures.

4.13.2    Third Degree and hiprof Errors with Multi-threaded Applications

The Atom hiprof tool may not work correctly with threaded applications. The problem may cause threaded applications instrumented with the hiprof tool to get a segmentation fault and dump core.

You can avoid this problem by passing the -exc __sigemptyset switch with the atom hiprof command; for example:

%  atom -tool hiprof -env threads -toolargs="-exc __sigemptyset" myapp

This switch causes the sigemptyset routine to be excluded from the profile, but avoids the segmentation fault.

The Atom third tool (Third Degree) also may not work correctly with threaded applications. The problem may cause threaded applications instrumented with Third Degree to get a segmentation fault and dump core.

You can avoid this problem by including the ignore __sigemptyset entry in your .third file. This entry causes the sigemptyset routine to be excluded from Third Degree's error checking, but avoids the segmentation fault.

4.13.3    Atom third Tool (Third Degree) May Not Work Correctly with C++

The Atom third tool may not work correctly with C++ applications that use the tasking library (libtask.so or libtask.a). The problem causes Atom to issue a number of the following warnings:

atom: Warning: Object 't' has invalid instruction at 0xhexaddress,
treating as data.

These are followed by the following Third Degree assertion failure:

Assertion failed: pc==InstPC(inst)

You avoid the problem by linking your application with the -call_shared switch and passing the -excobj libtask.so switch to Atom. For example:

%  atom -tool third -excobj libtask.so myapp

This switch excludes the tasking library from Third Degree's error checking, but avoids the assertion failure.

4.13.4    Atom Error with Dynamically Linked Fortran Applications

If a dynamically linked Fortran application is instrumented with -all or -incobj libc.so, you may get a loader error similar to the following when running the instrumented application:

pid:myapp.pixie: /sbin/loader: Fatal Error: Multiple instances of
shared object libc.so loaded as both /usr/shlib/libc_r.so and
./libc.so.myapp.pixie

You can avoid this problem by doing one of the following:

• If you have the ability to rebuild your application, you can relink it using the -non_shared switch. This produces an application that does not use shared libraries, thereby avoiding the problem.

• If you must use shared libraries but do not need to instrument libc.so, you can avoid the problem by passing the -excobj libc.so -excobj libc_r.so switches to Atom. For example:

  %  atom -tool pixie -all -excobj libc.so -excobj libc_r.so myapp
  

  Note, this workaround does not work if you use the Third Degree tool, because Third Degree needs to instrument libc.so.

• If you need to instrument libc.so (or if you are using the Third Degree tool), you can avoid the problem by passing the -incobj libc_r.so switch to Atom to ensure that both libc.so and libc_r.so are instrumented. After running Atom, remove the instrumented version of libc_r.so. Then, replace the instrumented libc_r.so library with a hard link to the instrumented version of libc.so. Then run the instrumented application. The following example demonstrates the workaround using the pixie tool.

  %  atom -tool pixie -incobj libc.so -incobj libc_r.so myapp
  %  rm libc_r.so.myapp.pixie
  %  ln libc.so.myapp.pixie libc_r.so.myapp.pixie
  %  setenv LD_LIBRARY_PATH .
  %  ./myapp.pixie
  

4.14    Change to Static Libraries and Kernel Objects

To save disk space, all the static system libraries and kernel objects are shipped as archive files that contain compressed object files. System tools that manipulate objects and archives understand the new format. Therefore, in most cases, you do not have to make any changes.

Any non-Digital tools that rely on the ability to read those objects without going through the supported ar interface will fail. You can use the ar -R command to decompress the objects contained in an archive.

4.15    DEC C++ Class Library Fixes

The following notes apply to DEC C++.

4.15.1    File Positioning for Bidirectional fstreams Has Been Corrected

A file positioning problem for bidirectional fstreams has been corrected. Previously, if your application switched from reading an fstream to writing an fstream (with or without an intervening seek operation) the necessary synchronization of the external file position with the get pointer was often skipped. This resulted in the written data being placed incorrectly within the file.

4.15.2    real Function Has Been Corrected

The real function within the stopwatch class was incorrectly returning the CPU time. Now it returns the clock time as documented.

4.15.3    flush Function Has Been Corrected

The flush function within the ostream class was incorrectly calling the overflow function. Now the flush function calls the sync function as documented.

4.15.4    LANG Environment Variable No Longer Cleared

During the destruction of a Message object, the value of the LANG environment variable is no longer cleared.

4.15.5    Extraction Operator Converting Hexadecimal Values Has Been Corrected

The extraction (>>) function within the istrstream class now works correctly when the conversion base format is hex and when hexadecimal values, which begin with 0 (zero) but not prefixed with 0x, are read.

4.15.6    Segmentation Fault at Image Exit Has Been Corrected

A segmentation fault no longer occurs during image exit for applications that call the sync_with_stdio function. Previously, a call to the sync_with_stdio function would free memory that was again freed at image exit. This problem sometimes generated a segmentation fault.

4.16    General Programming

The following notes apply to general programming.

4.16.1    New Interfaces to the C Runtime Library

Certain C runtime library functions have new interfaces when compiled with _POSIX_C_SOURCE set to a value greater than or equal to 199506L. This is the default setting in the relevant include files if you do not set _POSIX_C_SOURCE to any other value. The relevant library functions are:

asctime_r()	getpwuid_r()
ctime_r()	gmtime_r()
getgrgid_r()	localtime_r()
getgrnam_r()	rand_r()
getlogin_r()	readdir_r()
getpwnam_r()	ttyname_r()

To access the old version, define the preprocessor symbol _POSIX_C_SOURCE to the appropriate value. See Section 4.16.3.1. Existing binary code will continue to reference the old, binary compatible interfaces.

4.16.2    prof Command Information Messages

The prof command suppresses informational heading messages in cases where a full profiling report will not be generated.

For example, when the -merge switch is used to consolidate profiling data files, no report will be generated. The informational messages from prof will be suppressed. These informational messages give a time and date stamp, and display the prof command line.

4.16.3    Realtime

The following notes apply to realtime programming.

4.16.3.1    SA_SIGINFO Not Visible Under Certain Namespace Conditions

The symbol SA_SIGINFO, defined in sys/signal.h, is not visible under certain namespace conditions when _POSIX_C_SOURCE is explicitly defined in the application or on the compile line.

The SA_SIGINFO symbol will be visible if you do not explicitly define _POSIX_C_SOURCE. For most applications, unistd.h provides the standards definitions needed, including _POSIX_C_SOURCE. As a general rule, avoid explicitly defining standards macros in your application or on the compile line. If you do explicitly define _POSIX_C_SOURCE then beSA_SIGINFOwill visible if you also explicitly define _OSF_SOURCE

4.16.3.2    POSIX 1003.1b Synchronized I/O and File Truncation

POSIX 1003.1b synchronized I/O using file status flags does not apply to file truncation. When file status flags are used to control I/O synchronization, no synchronization occurs for file truncation operations.

The fsync() or fdatasync() function can be used to explicitly synchronize truncation operations.

4.16.3.3    fcntl() and F_GETFL with O_DSYNC File Status.

A problem occurs when fcntl() is called with the F_GETFL request, and the file operated on has the O_DSYNC file status flag set. The return mask incorrectly indicates O_SYNC instead of O_DSYNC.

4.16.3.4    Realtime Problems with Asynchronous I/O and Streaming Devices

When using asynchronous I/O (AIO) with streaming devices, such as tape drives, make sure that you post AIO requests in small numbers; otherwise, the devices will be unable to detect errors, particularly end-of-media errors, in time to prevent further AIO requests to the device. In the case of end-of-media errors, excessive AIO requests can result in the tape running off of its reel. Having two AIO requests outstanding on the device should provide an adequate balance between efficiency and responsiveness to critical device errors.

4.16.4    DECthreads (pthreads)

The following notes apply to DECthreads.

4.16.4.1    The cc Command Supports the -pthread Option

The -pthread option has been added to the cc command. This option will provide the IEEE Std 1003.1C-1995, POSIX System Application Program Interface environment for developers of multithreaded and threadsafe code.

For compatibility the -threads option remains and provides a P1003.4a Draft 4 environment (P1003.1C was previously named P1003.4a). The -threads option should not be used in applications utilizing the 1003.1c-1995 environment.

4.16.4.2    Libraries libc and libc_r are Merged

The threadsafe functions in libc_r.so and libc_r.a have been merged into libc.so and libc.a. It is no longer necessary to link with libc_r, and this library has now been replaced with a link to libc for binary and makefile compatibility. See Section 4.16.4.1 for information on how to compile and link multithreaded and threadsafe code.

To determine the thread safety of individual libc functions, consult the appropriate reference page. The number of thread safe functions has been considerably increased in Version 4.0. In many cases the original API of functions for which there is a *_r variant are now also threadsafe. In these cases the *_r API is also retained for compatibility, and documented as obsolete.

4.16.4.3    DECthreads Exception Handling

DECthreads Exception Handling now relies on the DEC C exception handling capabilities. Threaded applications must now link with libexc. Note that if you are compiling your threaded application as Digital recommends (using the -thread or -pthreads switch) this change will not affect the building of your application.

If you are using the DECthreads Exception Package with POSIX 1003.1c threads interface, you must include pthread_exception.h in your source file. This does not apply to applications which use the CMA or draft 4 POSIX threads interfaces.

4.16.4.4    DECThreads Signal Model Incompatibilities in Threaded Applications

Full support of the POSIX 1003.1c signal model may cause a binary compatability problem for applications using threads. This is not an API change but a change in runtime behavior. A thread that was never interrupted before may now be interrupted.

4.16.4.5    dbx and DECthreads

You cannot use dbx to debug threads (pthreads) in this release. Use the Ladebug debugger to debug threaded applications.

4.16.4.6    Threaded Application Coding Errors

This release contains substantial changes to threads that will likely expose programming errors in existing applications that use DECthreads. Such errors include, but are not limited to, the following:

• Attempting to unlock a mutex that is not locked

• Use of uninitialized variables

• Improper use of data structures (for example, using a pthread_attr_t instead of a pthread_mutexattr_t in a call to pthread_mutexattr_create)

• Improper data access synchronization

• Use of an undocumented or unsupported routine

4.16.4.7    Missing Thread Routines

The following routines:

• pthread_bind_to_cpu_np

• cma_thread_bind_to_cpu

are not provided in this release. If you use an application that requires one of these routines, it is recommended that you not migrate to Digital UNIX V4.0.

Note that applications using pthread_bind_to_cpu_np are using the draft 4 POSIX interface which is scheduled for retirement. These applications should be migrated as soon as possible to the POSIX 1003.1c compliant interface. (See the retirement notice in this volume for pthreads draft 4).

4.16.4.8    DECthreads Static Libraries

The following static libraries for DECthreads have not been provided in this release:

• libpthread.a

• libpthreads.a

The libraries will be provided in a future release.

4.16.4.9    DECthreads System Cancellation Points

Threaded applications that require system cancellation points must use the POSIX 1003.1c DECthreads interface. Cancellation points are not supported for the CMA or draft POSIX DECthreads interfaces. See the Guide to DECthreads Appendix A for the list of supported cancellation points.

4.16.4.10    DECthreads and Forking

In this release, the metering capabilities of DECthreads may not be reliable in a process which forks.

4.16.4.11    DECthreads and Realtime

In previous releases of Digital UNIX, thread scheduling attributes were system wide. In this release, all thread policies and priorities are now local to the process. Thread priorities between processes cannot be controlled. No artificial limit now exists on thread priorities: the full priority range is now accessible by every thread. See the IEEE POSIX 1003.1c standard or Appendix A of the Guide to DECthreads for further discussion of contention scopes.

4.16.4.12    DECthreads and Alpha Firmware Revisions

Use the current minimum firmware revisions for Digital UNIX 4.0 to get the best DECthreads performance. The correct firmware revisions for your processor are identified in the Digital UNIX Installation Guide.

4.16.4.13    DECthreads and Signal Handling

Signal handling in the POSIX 1003.1c (pthread) interface of DECthreads is substantially different than signal handling is for the draft 4 POSIX and the CMA interfaces of DECthreads. When migrating your application from the draft 4 POSIX or CMA interfaces to the POSIX 1003.1c interface, please see the IEEE POSIX 1003.1c standard or Appendix A in the Guide to DECthreads for a discussion of signal handling in threaded applications.

4.16.5    Changes in Kernel Debugging Using dbx

To reduce the size of the operating system, some kernel symbol table information useful for debugging with the dbx debugger has been removed. This information is mostly the type information for variables inside the kernel. (This feature was implemented in DEC OSF/1 Version 3.0.)

For example, assume you have the following variable declaration:

struct vnodeops procfs_vnodeops;

The dbx debugger might not know that the procfs_vnodeops variable is of the struct vnodeops type. Instead, the dbx debugger will regard it as an int, as follows:

(dbx) print procfs_vnodeops
0x12345678
(dbx) whatis procfs_vnodeops
int procfs_vnodeops;

To resolve this problem, explicitly cast the variable to the correct type. Using the previous variable declaration, issue either of the following dbx commands:

(dbx) print *(struct vnodeops *)&procfs_vnodeops

 

(dbx) px &procfs_vnodeops
0xfffffc0000660540
(dbx) print (struct vnodeops)0xfffffc0000660540

If the variable is a pointer to a type, cast the pointer and dereference it without the & operator. For example:

(dbx) print *(struct vnodeops *)procfs_vnodeops

Type information can usually be obtained from files in the /usr/include/sys directory. To avoid repetitive casting, use dbx aliases interactively or store them in a .dbxinit file. For example, the following alias yields the results shown:

(dbx) alias procfs_vnodeops "print *(struct vnodeops *)&procfs_vnodeops"

 

(dbx) procfs_vnodeops
struct {
       vn_lookup = 0xfffffc000027f0c0
       vn_create = 0xfffffc000027f0a0
       vn_mknod = 0xfffffc000027f0a0

You might find the following two aliases helpful:

alias pst(x,y) "print *(struct x *)y"
alias pvst(x,y) "print *(struct x *)&y"

The first alias prints the structure of an address or pointer; the second alias prints a variable of a specified structure. For example:

(dbx) pst(thread,0xfffffc00002cacb8)
struct {
       links = struct {
                    next = 0xd3431d90a21e0018
                    prev = 0x23de0040a75e0000

.
.
.



(dbx) pvst(vnodeops,procfs_vnodeops)
struct {
       vn_lookup = 0xfffffc000027f0c0
       vn_create = 0xfffffc000027f0a0
       vn_mknod = 0xfffffc000027f0a0

.
.
.

4.16.6    Warnings from sysconfig About Loadable Subsystem Attribute Tables

When a loadable subsystem is loaded and there are no sysconfigtab entries in the loadable subsystem's attribute table, the sysconfig utility might issue warnings in the xconsole window. To work around this problem, make sure that the loadable subsystem's sysconfigtab table contains the same number of attributes as the loadable subsystem's attribute table. Then, if an attribute appears in the xconsole it will correctly indicate that an entry could not be properly loaded or parsed.

4.16.7    Device Driver Example Files

Previously, Digital has supplied the none.c example driver in the /usr/examples/devdriver area. In this release, the none.c and none100 kit examples have been replaced by the ed100 driver example now in /usr/examples/devdriver. The file ed100 is a directory that contains the driver source and the associated files required to configure the driver in Digital UNIX Version 4.0. Please refer to the Guide to Writing Device Drivers: Advanced Tutorial for more information about writing device drivers.

4.17    Functions and System Calls

The following notes apply to functions and system calls.

4.17.1    Changes in pipe System Call Behavior

In DEC OSF/1 Version 3.0, the behavior for interrupted read and write calls on a pipe was changed to be POSIX compliant. When a read or write on a pipe is interrupted by a signal and no bytes have been transferred, the read system call and write system call returns -1 with errno set to [EINTR]. In previous releases, the read system call either restarted or returned [EINTR], depending on the setting of the SA_RESTART flag for the interrupting signal. Applications must be prepared to handle the [EINTR] return value or block any expected signals for the duration of the read or write operation. See pipe(2), read(2), and write(2) for more information.

4.17.2    shmat() Fails With Invalid Argument (EINVAL)

Existing applications that use large shared memory segments (>= 8MB) may fail during a shmat system call. This is because, by default, the system allocates shared page tables when a segment size >= 8MB is specified in shmget and therefore requires that attach addresses are aligned at 8MB. If an application uses an unaligned address to attach to such a segment and does not specify SHM_RND, the attach operation will fail and EINVAL is returned.

This behaviour can be modified using the sysconfig utility on a running system as follows:

#  sysconfig -q ipc ssm-threshold
ipc:
ssm-threshold = 8388608
#  sysconfig -r ipc ssm-threshold=0

ssm-threshold: reconfigured
sysconfig -q ipc ssm-threshold
ipc:
ssm-threshold

If this behaviour is to be preserved across a reboot then edit the /etc/sysconfitab file to add the following:

ipc:
ssm-threshold = 0

To make use of shared page tables the application must be modified to use 8MB aligned attach addresses.

Applications that use a large shared region (such as databases) are likely to use more than one segment to form a contiguous shared region. This could be due to either of the following conditions:

• the configured segment size is small

• the configured segment size is at the largest SystemV shared segment of 2GB (Gigabytes).

For this to work correctly the segments must be attached to contiguous virtual addresses. Typically this is done by attaching the next segment at the address formed by adding the size of the segment to the start address. If a segment size is not a multiple of 8MB then, the attach address will be unaligned and it will fail if SSM is enabled.

Application vendors typically use the shm-max value to determine the size of a segment and configure an aligned size for shm-max. This is all that needs to be done to continue using SSM. The recommended optimum size is 2GB - 8MB = 2139095040 (0x7f800000).

To reconfigure shm-max, edit the /etc/sysconfigtab file, and add the following

ipc:
    shm-max=0x7f800000

Then reboot your system.