First Time Problems

Problems that occur whenever a program statement is executed indicate an error in that statement or in a parameter used by that statement. These errors may often be indicated by the nature of the error. Some common errors are given below.

Trap 000D

This error indicates that the program attempted to access a location in memory that was not within the area allocated to its parent process. Since such access might violate the integrity of other applications or of the operating system itself, OS/2 disallows the access. Note that the pointer may directly reference a memory location, or may be the handle to a resource such as a window, presentation space etc.

The usual cause of such an error is that a pointer passed as a parameter in a function call is incorrect. The pointer may not have been initialized, or may have been set to an incorrect value as a result of a failed allocation request or incorrect pointer arithmetic.

Resolution actions are typically as follows:

  • Check that the function call which allocated the resource referenced by the pointer completed without error, and that a valid pointer was returned.

  • Ensure that any pointer arithmetic carried out on the pointer between allocation and the failing program statement is error-free.

  • If the pointer is stored in an instance data area (that is, a data block normally stored in the window words), ensure that the pointer to the instance data area itself has been correctly read from the window words at the start of processing for the current message.

    The allocation of a Presentation Manager resource may also fail for reasons associated with its parent window. See Failure to Allocate Resources below.

    One additional cause of this error is the application releasing an instance data block too early in the processing of a WM_DESTROY message. If the memory object containing this data block is released, and the application then attempts to release other resources whose handles are contained within the data block, OS/2 will not allow access to the memory. This problem is easily resolved by releasing the instance data block after other resources.

    Trap 000E

    This error indicates that an application under OS/2 Version 2.0 attempted to access an area in memory for which an address range had been allocated, but no storage committed. This error typically occurs when writing data objects into application data areas, since most operating system and Presentation Manager resources are automatically committed upon allocation.

    The usual cause of such an error is that the application failed to include the PAG_COMMIT flag in the DosAllocMem() function call that allocated the resource, or failed to issue a DosSetMem() call when increasing the size of a memory object. The problem may be easily resolved simply by including the PAG_COMMIT flag or including a DosSetMem() call to ensure that sufficient storage is available before writing to a memory object.

    Failure to Allocate Resources

    A common error shows itself when Presentation Manager resources cannot be allocated correctly by an application. This occurs most frequently with resources allocated upon creation of a window, during processing of the WM_CREATE message.

    The cause of the error is a failure, on the part of the application, to complete the default processing of the WM_CREATE message, before carrying out application-specific processing. Part of this default processing involves the allocation of a Presentation Manager control block for the window, allocation of a window handle etc. If this processing is not performed, via a WinDefWindowProc() function call, at the commencement of processing for the WM_CREATE message, function calls which use parameters such as the window handle will fail.

    The problem may be easily resolved by placing a WinDefWindowProc() function call as the first statement in the processing for the WM_CREATE message.

    Stack Space Exceeded

    This error may appear in either of two places:

  • If it appears during a call to an application subroutine, it usually indicates that the space reserved for the application'sstackisinsufficientforthenumberofnestedfunctioncalls ,localvariables ,etc . ,beingusedbytheapplication .

  • If it appears during a call to an operating system or Presentation Manager function, it may indicate the same cause as above, or that the limit of the application's Ring 2 stack, used by system-level code invoked by the application, has been exceeded.

    The application's stack size may be exceeded in situations where the application makes a large number of nested subroutine calls, particularly where extensive recursion is used, and/or where large numbers of local variables are defined. In such cases, the stack may be need to be increased beyond the recommended minimum of 8KB, using the STACKSIZE statement in application's module definition file.

    The Ring 2 stack limit is normally exceeded only in situations where a system-level function attempts to retrieve more items from the stack than were originally placed there. This can occur where an application passes an incorrect parameter to a function; for example, if a parameter is declared by the function as an array of eight elements, but the application passes an array containing only seven elements, an error may occur when the function attempts to retrieve eight elements from the Ring 2 stack for processing.

    While such an error may reveal itself during compilation, certain C typecasting conventions may mask the problem until run time. Where this error occurs during execution, careful checking of parameters is recommended.

    Window Fails to Appear

    This error occurs when an application issues a WinCreateWindow() or WinCreateStdWindow() function call to create a display window, but the window fails to appear on the desktop, even though the function returns a valid window handle. This error may result from either of two causes:

  • The WS_VISIBLE flag may not be set in the frame creation flags for the window.

  • The application may include the FCF_ICON or FCF_ACCELTABLE frame creation flags, but no icon or accelerator table resources are defined with resource identifiers which match the window identifier.

    In both cases, the WinCreateWindow or WinCreateStdWindow() function will return a valid window handle, since the window has been created.

    In the first case, the problem may be rectified by including the WS_VISIBLE flag in the frame creation flags, or by using the WinShowWindow() function to explicitly make the window visible.

    In the second case, resources should be defined in the application's resource script file to match the FCF_ICON and FCF_ACCELTABLE frame creation flags. These resources must have identifiers that match the window identifier given in the WinCreateWindow() or WinCreateStdWindow() calls, since Presentation Manager uses this identifier to load the resources.


    [Back: Problem Diagnosis]
    [Next: Repetitive Action Problems]