Analyzing problem conditions

The DSOM error codes mentioned below can be obtained directly by the application from the "minor" field of the exception data returned in a system exception, or from an error report message when SOMDDEBUG is set to a positive integer value (see the previous topic, "Error reporting").

Symptom: When running regimpl, a "PERSIST_STORE" or "NO_IMPLEMENT" exception is returned. The DSOM error code is SOMDERROR_IO or SOMDERROR_NoImplDatabase.

• This may indicate that the Implementation Repository files are not found or cannot be accessed. Verify that SOMDDIR is set correctly, to a directory that has granted read/write permission to the DSOM user. (It is best if the directory name is fully qualified.) If the SOMDDIR variable is not set, verify that the default directory ($SOMBASE/etc/dsom on AIX, and %SOMBASE%\etc\dsom on OS/2 or Windows) has been set up with the correct permissions. Ensure that the the files contained in the directory all have read/write permission granted to the DSOM user.

Symptom: When starting somdd, an "INITIALIZE" exception is returned with error code SOMDAlreadyRunning.

• This indicates that there is already an instance of somdd running. If the current instance of somdd does not seem to be responding properly, delete all instances of somdd and restart a new copy of somdd.

Symptom: When starting up a server program, an exception is returned with a DSOM error code of SOMDERROR_ServerAlreadyExists.

• This may indicate that a server process that is already running has already registered itself with the DSOM daemon, somdd, using the implementation ID of the desired server program.

Symptom: On OS/2, an operating system error occurs indicating a "stack overflow" condition soon after a the first call to a class DLL. Rebuilding the DLL with a larger stack size does not help.

• This sometimes occurs when a DLL uses, but does not initialize, the run time for OS/2. To perform the proper initialization, a function named "_DLL_InitTerm" must be included in the DLL, and it must invoke the C Set/2 initialization function, "_CRT_Init." The _DLL_InitTerm function is invoked automatically when the DLL is loaded.

  An example _DLL_InitTerm function is included in the DSOM sample code shipped with the SOMobjects Developer Toolkit for OS/2, in the file "initterm.c".

Symptom: When running a DSOM application that uses EMan, an error message is displayed asking that the SOMSOCKETS be set.

• This may indicate a need to specify the Sockets subclass to be used with the application. Current choices are TCPIPSockets for TCP/IP (and TCPIPSockets32 on OS/2), NBSockets for NetBios and IPXSockets for Netware IPX/SPX. Note:Each SOMobjects package will contain an appropriate subset of Sockets subclasses. Workstation DSOM includes TCPIPSockets (and TCPIPSockets32 onOS/2 ) for TCP/IP. Workgroup DSOM also includes NBSockets for NetBios and IPXSockets for Netware.

Symptom: A remote method invocation fails and an "INTF_REPOS" exception is returned. The DSOM error code is SOMDERROR_BadDescriptor or SOMDERROR_ClassNotlnIR.

• This may indicate that the interface describing the method or the method itself cannot be found in the Interface Repository. Verify that SOMIR is set correctly, and that the IR contains all interfaces used by your application.

  If the default SOM IR (supplied with the SOMobjects Toolkit and Runtimes) is not used by the application, the user's IR must include the interface definitions for the appropriate Sockets class, server class (derived from SOMDServer), and the definitions of the standard DSOM exceptions (found in file "stexcep.idl") that may be returned by a method call.

Symptom: A SOMDERROR_ClassNotFound error is returned by a client either when creating a remote object using somdNewObject, or when finding a server object using somdFindAnyServerByClass. (The methods are defined on the SOMDObjectMgr class.)

• This occurs when the class name specified in calls to somdNewObject or somdFindAnyServerByClass cannot be found in the Implementation Repository. Make sure that the class name has been associated with at least one of the server implementations.

Symptom: A SOMDERROR_ClassNotlnlR error is returned by a server when creating a new object using somdNewObject, somdCreateObj, or somdGetClassObj.

• This error may result if the DLL for the class cannot be found. Verify hat:

  • the interface of the object can be found in the IR;

  • the class name is spelled correctly and is appropriately scoped (for example, the "Printer" class in the "PrintServer" module must have the identifier "PrintServer:: Printer").
  
  This error can also result when the shared library is statically linked to the server program, but the <className>NewClass procedures have not been called to initialize the classes.

  Symptom: When invoking a method returns a proxy for a remote object in the client, a SOMDERROR_NoParentClass error occurs.

  • This error may result when the class libraries used to build the proxy class are statically linked to the program, but the <className>NewClass procedure have not been called to initialize the classes.

  Symptom: Following a method call, the SOM run-time error message, "A target object failed basic validity checks during method resolution" is displayed.

  • Usually this means that the method call was invoked using a bad object pointer, or the object has been corrupted.

  Symptom: A remote object has an attribute or instance variable that is, or contains, a pointer to a value in memory (for example, a string, a sequence, an "any"). The attribute or instance variable value is set by the client with one method call. When the attribute or instance variable is queried in a subsequent method call, the value referenced by the pointer is "garbage".

  • This may occur because DSOM makes a copy of argument values in a client call, for use in the remote call. The argument values are valid for the duration of that call. When the remote call is completed, the copies of the argument values are freed.

    In a DSOM application, a class should not assume ownership of memory passed to it in a method parameter unless the IDL description of the method includes the SOM IDL modifier object_owns_parameters. Otherwise, if a parameter value is meant to persist between method invocations, then the object is responsible for making a copy of the parameter value.

  Symptom: A method defines a (char *) parameter that is used to pass a string input value to an object. The object attempts to print the string value, but it appears to be "garbage".

  • DSOM will support method arguments that are of type "pointer-to-X" (pointer types are a SOM extension), by dereference the pointer in the call, and copying the base value. The pointer-to-value is reconstructed on the server before the actual method call is made.

    While (char *) is commonly used to refer to NULL-terminated strings in C programs, (char *) could also be a pointer to a single character or to an array of characters. Thus, DSOM interprets the argument type literally as a pointer-to-one-character.

    To correctly pass strings or array arguments, the appropriate CORBA type should be used (for example, "string" or "char foo[4 ]").

  Symptom: A segmentation violation occurs when passing an "any" argument to a method call, where the "any" value is a string, array, or object reference. Note: The NamedValues used in DII calls use "any" fields for the argument values.

  • This error may occur because the "_value" field of the "any" structure does not contain the address of a pointer to the target string, array, or object reference, as it should. (A common mistake is to set the "_value" field to the address of the string, array, or object reference itself.)

  Symptom: When a server program or a server object makes a call to get_id or to get_SOM_object on a SOMDObject, a "BAD_OPERATION" exception is returned with an error code of SOMDERROR_WrongRefType.

  • This error may occur when the operation get_id is called on a SOMDObject that does not have any user-supplied ReferenceData (that is, the SOMDObject is a proxy, is nil, or is a simple "SOM ref" created by create_SOM_ref). Likewise, this error may occur when the operation get_SOM_object is called on a SOMDObject that was not created by the create_SOM_ref method.

  Symptom: A segmentation fault occurs when a SOMD_Uninit call is executed.

  • This error could occur if the application has already freed any of the DSOM run-time objects that were allocated by the SOMD_Init call, including SOMD_ObjectMgr, SOMD_ImplRepObject and SOMD_ORBObject.

  Symptom: Unexplained program crashes.

  • Verify that all DSOM environment variables are set, as described in the earlier section "Configuring DSOM Applications". Verify that all class libraries are in directories specified in LIBPATH for AIX and OS/2, or specified in PATH for Windows. Verify that the contents of the Interface Repository, specified by SOMIR, are correct. Verify that the contents of the Implementation Repository, specified by SOMDDIR, are correct. Verify that somdd is running. Set SOMDDEBUG to 1 to obtain additional DSOM error messages.

  Symptom: When starting somdd, an "INITIALIZE" error is returned with error code SOMDERROR_NoSocketsClass.

  • If SOMSOCKETS is set, verify that the IR contains the appropriate Sockets interface definition.

  ---

  [Back: Checking the DSOM setup]
  [Next: Limitations]