Remote Debugging

In remote debugging, the Uniface Debugger and the application being debugged communicate with each other over a network. They can be running on the same machine or on different machines, and the network protocol can be TCP or TLS.

As partners in the debugging session, the Debugger and application must have compatible configurations, so that one acts as the network server and the other as the network client, and they must use the same network protocol and port number on the host machine.

To specify these options, use the /deb command line switch when starting the Debugger and the application. Either partner can be started first, but their configurations must match. For more information, see /deb.

Server Debug

Uniface provides a pre-configured environment for remote debugging over TCP. It is used for debugging web applications, but you can also attach a shared or exclusive Uniface Server for debugging client/server applications.

The Server Debug shortcut starts the Debugger as a TCP server for remote debugging, using the additional command line switch:

/deb=localhost+PortNumber:create

where PortNumber is the TCP listening port configured during installation.

You can connect a shared or exclusive server to this Debugger by defining a UST for the Uniface Server, which includes the following switch in its startup parameters:

/deb=localhost+PortNumber:wait.

For example:

;urouter.asn

[SERVERS]
MySrv = "D:\Uniface\common\bin\userver.exe" /adm="D:\Uniface\uniface\adm" /deb=localhost+13002:wait /asn=MySrv.asn				

Note: When the /deb switch does not specify a network connector, TCP is used by default.

This functionality is used in the pre-configured environment for debugging web applications. For more information, see Debugging a Web Application.

Troubleshooting

Problems with remote debugging can be the result of errors in configuring the network connector or debugging partners. For example, either partner can be started first, with the other partner starting later. If there is a mismatch in the configuration, it is possible for both applications to be running, but neither is visible to the user, and no error messages appear in the log files. Both application and Debugger are waiting for their partner to connect, but because of the mismatch, that will never happen.

When an error occurs in the create command, a network error is reported and the creator will exit.

When an error occurs in creating the network connection, the wait side loops endlessly waiting for a successful attempt. Neither application is visible and no errors are written to the log file of the wait side. When using nowait, that side will continue and become visible but will not be attached to the network server (Debugger or application).

To troubleshoot such problems:

  • Set $IOPRINT to a value greater than zero to see network connector errors during startup.
  • Check the log file to see if an error has been reported and the application has ended.
  • Check whether the Debugger and application are running. Always start from a situation where neither process is running. You can use operating system tools or commands, such as the Task Manager on Windows or the ps command on Unix.
  • Try using the nowait command. If the application starts but cannot be debugged, then examine the /deb string for errors.
  • Try to identify the mismatch:
    • Verify that the host name used can be successfully used in a ping command.
    • Ensure that the specified TLS profile definitions match for the client and the server.
    • Ensure that there is no ambiguity as a result of omitting the TLS Profile or the Command. For example, if no TLS Profile is specified and the Commandis misspelled, the command will be seen as a TLS profile. This may result in a mismatch between the partners.