32.2.2. Debugger

<< Prev   Next >>

32.2.2.1. TCP/IP debug protocol

32.2.2.1.1. How it works

To debug 1C:Enterprise language code, run the application that executes the code in the debug mode. Debug mode requires the TCP/IP network protocol support enabled on the computer.

If 1C:Enterprise is not launched, select Debug ‑ Start Debugging to start debugging. Designer launches the client application in debug mode.

If debug mode is enabled or debugging is set to begin upon startup in the Designer settings. You can open them by selecting Tools ‑ Options 1C:Enterprise startup tab. You can also launch debugging in the run mode by selecting Tools ‑ 1C:Enterprise. If you want to debug the code executed by a specific user, then in the settings form you can specify the user under which the debug mode is started.

The Debugger and debug items use IP address 127.0.0.1 when searching for each other. To ensure stable operation of the data transport service, it is necessary to determine the correspondence of the address 127.0.0.1 to symbolic name localhost. For this purpose, write the following mapping to the file C:\Windows\system32\drivers\etc\hosts

127.0.0.1 localhost

32.2.2.1.2. Application setup in debug mode

General information

In this section, it is assumed that the Designer is configured for debugging using the TCP/ IP debug protocol. You can set up Designer in the Designer settings dialog box. Later we do not remind to set it up.

Debugging client applications

To set the debug mode, you can use the following startup options:

• In the Designer mode, in the settings form (menu Tools ‑ Options) on 1C:Enterprise startup ‑ Additional tab, select the Enable debugging mode check box and then attach the debug item. You can also select Begin debugging on startup. In this case, connection is established automatically at 1C:Enterprise startup. In this case, the TCP/IP protocol should be used for debugging (the Tools ‑ Settings dialog box, the Debug tab, Debug Protocol property must be set to TCP/IP Debugging).
• Open the infobase in 1C:Enterprise mode with the /debug ‑tcp command-line option (debug mode).
• If the client application is running, set the debug mode in the settings form (open via the Tools ‑ Options menu). For this purpose, the Debug in the current session property should be set to Enabled (TCP/IP protocol). Note that you cannot change this property value after you have applied these settings.

Debugging server code

In the debug mode, the configuration objects are loaded as needed, and not at the system startup as in the normal server operation mode. This speeds up the startup process of 1C:Enterprise when changing the configuration, so it accelerates the development process.

You should also keep in mind that the system performance is lower in the debugging mode than in the normal mode. So, it is not recommended to use the debug mode of the server for real user operations.

Server as an application

If 1C:Enterprise server is running in an application mode (in any OS), stop the server and restart it so that it includes the ‑debug parameter in the command-line parameters.

ragent debug <other command line settings>

If the server runs as a Windows service, you need to do the following:

1. Stop the 1C:Enterprise server.

ragent stop

1. Re-register the server agent as a Windows service so that it includes the ‑debug parameter in the list of the ragent command parameters.

ragent instsrvc debug <other command line settings>

1. Start the 1C:Enterprise server.

ragent start

If you need to transfer the 1C:Enterprise server working as a Linux daemon into the debug mode, you need to do the following:

1. Stop the 1C:Enterprise server.

/etc/init.d/srv1cv83 stop

1. In the srv1cv83 configuration file set the value of SRV1CV8_DEBUG parameter to 1.

SRV1CV8_DEBUG=1

1. Save the configuration file.
2. Start the 1C:Enterprise server.

/etc/init.d/srv1cv83 start

Debugging external connection

To enable debug mode for an external connection, use the settings located in xml file comcntrcfg.xml, which is located in the 1C:Enterprise system configuration files directory. If the file cannot be found, the application runs in the standard mode.

Sample of comcntrcfg.xml file:

<config xmlns="http://v8.1c.ru/v8/comcntrcfg">
<debugconfig debug="true" protocol="tcp" debuggerURL="tcp://localhost:1560"/>
</config>

If the debuggerURL attribute is set for the debug item, then Designer should be available at the specified URL when accessing the external connection. Otherwise, the external connection will be suspended and the system will wait for the Designer availability. At the same time, to continue working in the Designer mode, you should attach the required debug item.

Debugging web service, HTTP service, and access via the standard OData interface

To indicate that the service needs to be started in debug mode (only for the file mode of the infobase), use the settings that are located in the default.vrd file, which should be located in the virtual application directory. You need to specify the debug item in this file. If you don't do it, the Web service cannot be debugged.

Sample of the debug item from default.vrd file:

<debug enable="true" protocol="tcp" url="tcp://localhost"/>

If the url attribute is set for the debug item, then Designer should be available at the specified URL when accessing the service. Otherwise, the service will be suspended and the system will wait for the Designer availability. At the same time, to continue working in the Designer mode, you should attach the required debug item.

If you need to debug a service in the server infobase mode, enable the debug mode on the server using the debug command-line option.

Debugging web client

To set the debug mode, you can use the following startup options:

• In the Designer mode, in Tools ‑ Options, click tab 1C:Enterprise startup ‑ Additional, and select the Enable debugging mode check box. Then attach the debug item. You can also select the Begin debugging on startup check box. In this case, connection will be established automatically at 1C:Enterprise startup.
• Open the infobase in the 1C:Enterprise mode by using the debug command-line option (debug mode):

http://localhost/demo?debug=tcp

• Open the infobase in the 1C:Enterprise mode by using the debug command-line options debug and debuggerurl="IP-address":

http://localhost/demo?debug=tcp&debuggerurl="127.0.0.1"

• IP address is the debugger address. If the Debugger located at 127.0.0.1 is launched, it will automatically attach the debug items (the Debugger must be run at the specified address).

To enable the debugging of the server file mode of the infobase, you can use two methods:

• Start debugging directly from the Designer as described above. In this case, debugging of the server file mode on the computer with the web client starts automatically.
• Enable debug mode using default.vrd file. It should be located in the virtual application directory. You need to specify the debug item in this file. If you don't do it, the Web service cannot be debugged.

Sample of the debug item from default.vrd file:

<debug enable="true" protocol="tcp" url="tcp://192.168.0.30"/>

You should also keep in mind that the system performance is lower in the debugging mode than in the normal mode. So it is not recommended to use the debugging mode of the server file mode for real user operations.

When debugging a web client, you need to remember the following:

• You cannot interactively enable the debugging mode.
• Automatic search of debugging objects on remote computers is not supported when debugging a web client for the file mode infobase.
• Designer activation from the web client is not supported during debugging.
• Debugging external reports and data processors is not supported.
• In case of forced termination of the web client from the Debugger, the process of the web browser that started when the web client was started from Designer is terminated. However, if the web client starts in the tab of an already running web browser, then the forced closing of the tab does not occur and a dialog box opens in the debug web client window with information indicating that the web client is terminated at the request of debugger.

Debugging external data processor (report)

To debug an external report (data processor), the following conditions must be met:

1. External data processor (report) is opened in the client application from a specific file mode location.
2. Designer, which serves the debug item with debugged external data processor (report), has access to the external data processor (report) file that is opened by the client application.

If these conditions are not met, debugging the external data processor (report) will be impossible. In particular, debugging of external data processors (reports) located in the infobase are not supported. In this case, it is recommended to extract the external data processor (report) from the infobase for the time of debugging.

32.2.2.1.3. Attaching debug items

To debug a module, the debug item should be attached. To manage an attachment, select Debug ‑ Attachment . The debug item selection dialog will be displayed. The list includes only those debug items, for which the following conditions are met:

• Debugger and the debug item have the same infobase ID:
  • For the file mode of infobase, it is generated at the first access to the database using the client application (including the Designer access). At the next first access the ID will be re-generated. The “first access” is not an absolute first access at the moment of creating the infobase, but the first call after the infobase has no more connections left.
  • For the infobase in the client/server mode, the infobase ID in 1C:Enterprise server cluster is used.
• The application must have the debug option enabled (for the server ‑ the debug check box, for the client application ‑ the corresponding command line parameter, or the property of the client application settings dialog box, or a correctly configured configuration file).

Debug items can be attached throughout the time interval of the session, within which a specific background job, Web service, or external connection is running. This interval can be very short, and in this case you can configure the debug items automatic connection.

Usually the list contains one line that refers to the configuration running in the 1C:Enterprise mode. If several 1C:Enterprise applications are running with this configuration, the list may contain several lines.

If the Search for debug items on remote computer check box is selected, enter a computer name or a network address in the box to the right of the check box or select it from the list of previously entered names. The debug items found on the remote computer will be added to the available debug items list. The list of attached debug items contains the items already attached to the Debugger.

When you click Attach, the selected debug item is attached to the Debugger. In the attachment window, this is displayed by the transfer of the debug item from the list of available debug items to the list of attached debug items.

To exclude a debug item, you need to specify it in the list of attached items and click Detach. For a detached debug item, debugging is no longer performed. In particular, this means that the breakpoints set in detached debug items do not function during walkthrough of them. In the attachment window, this is displayed by moving the debug item from the list of attached items to the list of available items. You can re-attach to it.

To close the debug item, click Finish. To stop at the execution point, click Stop.

To open a range setup dialog box, click Options. Specify the port range to search for debug items. The search is performed on the current computer or on the specified computer.

The Debugger field of the dialog box contains the current Debugger settings. You can use them, for example, in a command line during the client application startup as the /debuggerurl command-line option parameter or in an XML file containing debug settings for external connection or Web service.

To set auto-attachment for debug items on the 1C:Enterprise server running in the debug mode, use the Automatic attachment dialog box and select the required debug item types.

The specified settings for automatic connection are valid only for the client/server infobase, except for Background jobs, which can be used to automatically connect background jobs, both in the client/server and in the file modes of infobase. If it is necessary to debug various services (WEB-, HTTP‑ and OData-) in the file mode of infobase, then debugging should be configured in the publishing dialog box on the web server.

Auto-connection of a background job run by the client application or a web server extension is indirectly managed in this dialog box. Background jobs can only be debugged if certain conditions are met:

• For thin or thick client:
  • Allow debugging in the client application.
  • Allow auto-connection to background jobs in the auto-connection settings dialog box.
• For web server:
  • Allow debugging for the infobase in the publication file (default.vrd).
  • Allow auto-connection to background jobs in the auto-connection settings dialog box.

32.2.2.1.4. Additional port range settings

If all ports for connection within the standard range are occupied, you can specify additional range. This range can be specified in debugcfg.xml file located in the configuration files directory, on the computer where the Designer and debugged client application are located, or where an external connection is established. If a port range is changed on the computer with the debugged application, these ports should be set for the Designer where debugging takes place (if the debugged application and the Designer are located on different computers). If the file is not found, ports from the standard range (1560-1591) are used for communication. Debug items on the server use the same ports as the server processes: rmngr and rphost. Additional port ranges for debug items on the server are not required.

Example:

<config xmlns="http://v8.1c.ru/v8/debugcfg">
<debugports range="1540:1550"/>
</config>

32.2.2.2. HTTP debug protocol

32.2.2.2.1. How it works

To debug 1C:Enterprise language code, run the application that executes the code in the debug mode. Debug mode requires TCP/IP network protocol support enabled on the computer and HTTP protocol operation is not blocked (various proxy servers, firewalls, and other).

When using the HTTP debug protocol, a special debug server (dbgs) is used for debugging. Debug server acts as the debugging process coordinator:

• Stores lists of debug items available for use and lists of attached debug items.
• Translates debug control commands to debug item commands (stop, continue execution, and other).
• Stores a list of users who can debug. It also stores the user rights to perform some actions during debugging.

The general debugging procedure using a debug server can be represented as follows:

There is no direct information transfer between the Debugger and debug items. All interaction is organized through the debug server. A message queue is organized on the debug server, through which the debugger and debug items transmit information to each other.

Both the debugger and debug items interact with the debug server using the HTTP protocol. It does not matter where the debug item is located.

Interaction with the debug server is initiated by the debugger and debug items. During operation, two connections are established between the debug server and each process party (debug items and debugger). One connection is used by the debug item to report its status to debug server (a breakpoint is reached, step is completed, and other). Another connection is used by the debug item or debugger to find out whether the information appears for it on the debug server. And if it is there, to receive this information.

Thus, there is a one-way interaction. Information is transmitted all the time from the debug server to the debugger and to the debug items. It should be understood that if the debug item is not running in debug mode, ‑the debug server will not be able to establish a connection with it. In particular, this means that it is impossible to debug the code on the 1C:Enterprise server if the server is not running in debug mode.

The debug server can handle debugging of an arbitrary number of debug items from different infobases. Debugger and debug items on the debug server are compared on the basis of the infobase name. These names are different and depend on the use case of the infobase:

• Client/server mode. The infobase name is used as defined in the 1C:Enterprise server cluster.
• File mode. Predefined name DefAlias is used, you cannot change it. So, in case of a file infobase, the debug server should be used for concurrent work only with the debugger and debug items from one file infobase. Upon the file infobase Designer startup, the debug server for the used infobase automatically starts, too. When you start the client application from the Designer, it is passed the address of the debug server running for this infobase. Thus, when two Designers work with two file infobases, two debug servers will be used, each for its own infobase. At the same time, when launching a client application not from the Designer, you must manually specify the correct debug server address in the command line of the client application (if debugging is needed).

In Designer, you can customize the infobase name used by the Debugger to register on the debug server. This feature is used in cases when one infobase is open in the Designer, but debugging is required for debug items from another server infobase with a known name on a known debug server.

Let us consider what happens when a breakpoint is encountered when using a debug server. After the debug server received a message stating that a particular debug item stopped at a breakpoint, it sends a message stating that all connected debug items should stop. Each debug item executes this command before starting the execution of the next “own” code line in 1C:Enterprise language. Attached debug items stop asynchronously. The debug items of the current session (these are the client application and the server servicing this client application) stop synchronously, and it is generally impossible to determine when other debug items stop. After the command is executed in the debugger, for example, take a step, the debug server informs all attached debug items that they can continue to perform their work. At the same time, the specified command is executed in the active debug item, and the “take a step” operation can be represented (with some approximation) as launching the debug item with setting a breakpoint on the next line. Once the active debug item has completed the requested operation, it reports this to the debug server and the process repeats.

Two important facts follow from this description:

1. It is impossible to simultaneously debug various debug items related to the same infobase (client/server mode) or the same debug server (file mode).
2. With a single step in the current debug item, it is impossible to predict (in general case) where the stop will occur in the other attached debug items. As part of this statement, it could be considered that the client and server debug items related to the same session number act as one debug item.

You can specify users who can use the debug server and infobases that can be used for debugging. You can do this when the debug server is used as an external debug server for remote infobases. In this case, a configuration file with the following information is passed to the debug server via the command-line parameters:

• List of infobases where debugging is possible.
• List of users (for each infobase) who can connect to the debug server.
• Permissions of each user. That is, what a user can do during application debugging.

When a new user is connected, the debug server requires the user to specify a username and password as specified in the list of users from the configuration file. Designer executes this query when connecting to the debug server. If the user is authorized in the debug server, they can debug within the permissions specified in the configuration file. Other debug server operations are unchanged.

32.2.2.2.2. Application setup in debug mode

General information

In this section, it is assumed that the Designer is configured for debugging using the TCP/ IP debug protocol. You can set up Designer in the Designer settings dialog box. Later we do not remind to set it up.

Debugging when starting from Designer

In order for the client application to start up from the Designer immediately in debug mode, you must start the client application using the Debug ‑ Start Debugging command. In this case, the client application will be launched in debug mode, and all necessary components will also be launched with the correct settings or command line settings. This will start the client application that is selected in the Designer settings.

If you need to start a specific application in debug mode without changing the default settings, you can start it using the Debug ‑ Start Debugging command. The menu lists client applications that can be launched in debug mode.

Starting a mobile application debug from Designer is supported only for devices running Android OS. In this case, the device must be attached to the personal computer that is running Designer using a USB cable and in the start settings of the mobile application, Android Debug Bridge to start the mobile application must be configured. Debugging a mobile application on an iOS device is only possible when the application is launched manually on the mobile device.

Enable debugging in a running client application

In case you need to debug an already running client application without debug mode enabled, you should perform the following steps:

1. Go to Service and settings ‑ Settings and click Parameters. The dialog box to set up the client application parameters opens.
2. Set the Debug in current session property to Debug in current session.
3. In the Debug server property, specify the address of the debug server being used.
4. Click OK. After you enable debugging in the current session, you cannot disable it or change the debug protocol.

Enable debugging in a running client application is not supported when using a web client.

Debugging server code

In the debug mode, the configuration objects are loaded as needed, and not at the system startup as in the normal server operation mode. This speeds up the startup process of 1C:Enterprise when changing the configuration, so it accelerates the development process.

You should also keep in mind that the system performance is lower in the debugging mode than in the normal mode. So, it is not recommended to use the debug mode of the server for real user operations.

Server as an application

If 1C:Enterprise server is running in an application mode (in any OS), stop the server and restart it so that it includes the /debug parameter in the command-line parameters.

ragent / debug ‑http <other command line settings>

If necessary, you should also specify the values of the /debugServerAddr,/debugServerPort, and /debugServerPwd parameters in the server startup command line.

Server as a Windows service

If the server runs as a Windows service, you need to do the following:

1. Stop the 1C:Enterprise server.

ragent /stop

1. Re-register the server agent as a Windows service so that it includes the /debug parameter in the list of the ragent command parameters.

ragent /instsrvc /debug ‑http <other command line settings>

If necessary, you should also specify the values of the /debugServerAddr, /debugServerPort, and /debugServerPwd parameters in the server registration command line.

1. Start the 1C:Enterprise server.

ragent /start

If 1C:Enterprise server is running in an application mode (in any OS), stop the server and restart it so that it includes the /debug parameter in the command-line parameters.

ragent /daemon /debug ‑http <other command-line parameters>

If necessary, you should also specify the values of the /debugServerAddr,/debugServerPort, and /debugServerPwd parameters in the server startup command line.

Debugging external connection

To enable debug mode for an external connection, use the settings located in xml file comcntrcfg.xml, which is located in the 1C:Enterprise system configuration files directory. If the file cannot be found, the application runs in the standard mode.

Sample of comcntrcfg.xml file:

<config xmlns="http://v8.1c.ru/v8/comcntrcfg">
<debugconfig debug="true" protocol="http" debuggerURL="http://pc name:1561"/>
</config>

If the debuggerURL attribute is specified for the debug item, then the debug server should be available at the specified address when the external connection is used. Otherwise, the external connection will work in ordinary mode and it will not be possible to debug it.

Debugging web service, HTTP service and access via the standard OData interface

To indicate that the service needs to be started in debug mode (only for the file mode of the infobase), use the settings that are located in the default.vrd file, which should be located in the virtual application directory. You need to specify the debug item in this file. If you don't do it, the Web service cannot be debugged.

Sample of the debug item from default.vrd file:

<debug enable="true" protocol="http" url="http://pc name:1561"/>

If the debuggerURL attribute is specified for the debug item, then the debug server should be available at the specified address when using the service. If at the moment of launching the application, the debug server will be unavailable, debugging will be impossible, and the platform will work as usual.

If you need to debug a service in the server infobase mode, enable the debug mode on the server using the /debug command-line option.

Debugging web client

If the web client is started not from Designer, then to debug the client, the following actions should be performed:

1. Determine the address of the debug server with which the debugger will interact.
2. Open the infobase in 1C:Enterprise mode, indicating the need for debugging:

http://localhost/demo?debug=http,attach&debuggerURL="addr"

addr value is acquired on the previous step.

1. In this case, the debugging of the server application code will be unavailable.

To enable the debugging of the server file mode of the infobase, you can use two methods:

• Start debugging right from Designer.
• Enable debug mode using default.vrd file. It should be located in the virtual application directory. You need to specify the debug item in this file. If you don't do it, the Web service cannot be debugged.

Sample of the debug item from default.vrd file:

<debug enable="true" protocol="http" url="http://pc name:1561"/>

You should also keep in mind that the system performance is lower in the debugging mode than in the normal mode. So, it is not recommended to use the debugging mode of the server file mode for real user operations.

When debugging a web client, you need to remember the following:

• You cannot interactively enable the debugging mode.
• Automatic search of debugging objects on remote computers is not supported when debugging a web client for the file mode infobase.
• Designer activation from the web client is not supported during debugging.
• Debugging external reports and data processors is not supported.
• In case of forced termination of the web client from the Debugger, the process of the web browser that started when the web client was started from Designer is terminated. However, if the web client starts in the tab of an already running web browser, then the forced closing of the tab does not occur and a dialog box opens in the debug web client window with information indicating that the web client is terminated at the request of debugger.

Debugging external data processor (report)

To debug an external report (data processor), the following conditions must be met:

1. External data processor (report) is opened in the client application from a specific file mode location.
2. Designer, which serves the debug item with debugged external data processor (report), has access to the external data processor (report) file that is opened by the client application.

If these conditions are not met, debugging the external data processor (report) will be impossible. In particular, debugging of external data processors (reports) located in the infobase are not supported. In this case, it is recommended to extract the external data processor (report) from the infobase for the time of debugging.

Debugging mobile application

To start debugging from Designer, only the developer platform can be used.

Starting a mobile application debug from Designer is supported only for devices running Android OS. In this case, the device must be attached to the personal computer that is running Designer using a USB cable and in the start settings of the mobile application, Android Debug Bridge to start the mobile application must be configured. In this case, the address of Designer, where the debugging starts from, is used as the debug server address.

Debugging permission flag and the debugger address specified in the infobase property of the same name are ignored.

To start debugging from Designer, only the developer platform can be used.

The first start of the mobile application is performed on the mobile device manually. When started for the first time, the mobile application uses the properties of the infobase to determine the status of debugging. If the Restart from Designer property is set in the infobase settings, then the debug state upon restart will be determined by how this restart was initiated in Designer. The mobile application will be restarted in debug mode if the restart is initiated from Designer using the Start Debug command. In other cases, the restarted mobile application will not be available for debugging.

Debugging permission flag and the debugger address specified in the infobase property of the same name are ignored (except for the first start of mobile application).

To start debugging from Designer, only the assembled mobile application can be used.

The mobile application can be started only on the mobile device itself. Debug status is determined by the settings of the used infobase.

To configure the debugging control settings, open the list of infobases, find the required base in the list and perform the following actions in the properties of this infobase:

• Enable the Debug enabled radio button.
• Set the debug server address in the Debug address field. Receive the address of the debug server in Designer, in the Debug server property of the Debugger settings dialog box. It is available when executing the following command: Main menu ‑ Debug ‑ Attachment ‑Settings.

You should keep in mind that the debug settings specified in the infobase properties can be ignored in some operation modes (described above in this section).

Debugging offline mobile application

No debugging of all components of an offline mobile application can be performed. You can either debug those running on the mobile device or interacting with the main server. When you debug the standalone application part, attach the following debug items: client (mobile application) and server (mobile application). Whenever primary application components are debugged, make sure the following debug items are enabled: mobile client and server.

To switch in between these modes, use an infobase setting parameter on the mobile device.

Actions performed before debugging is started are similar to those typical of mobile application or application debugging on a personal computer.

32.2.2.2.3. Attaching debug items

To debug a module, the debug item should be attached. To manage an attachment, select Debug ‑ Attachment . The debug item selection dialog will be displayed. The Available debug items list contains debug items registered on the debug server used for the infobase specified in the settings of this Debugger (Designer).

The following is excluded from the Available debug items list:

1. Attached debug items (displayed in the Attached debug items list).
2. The debug items that do not match the filter set at the top right part of the window. Filter is intended only for the visual limitation of the list. Debug items that do not match the filter are still available for use and, after turning off the filter, will instantly appear in the available debug items list.

When you click Attach, the selected debug item is attached to the Debugger. In the attachment window, this is displayed by the transfer of the debug item from the list of available debug items to the list of attached debug items.

To exclude a debug item, you need to specify it in the list of attached items and click Detach. In the attachment window, this is displayed by moving the debug item from the list of attached items to the list of available items. You can re-attach to it. Moreover, breakpoints set in detached debug items will not “work” when passing through them.

To close the debug item, click Finish. To stop at the execution point, click Stop.

To open a dialog box with information about the debug server being used, click Settings. In the opened dialog box, the debug server address and the name of the infobase will be displayed.

To automatically attach debug items to the current debugger, you can use the Auto attach dialog box and configure the required filters in it.

On the left part of the dialog box (Types of debug items), you can specify which types of debug items will automatically attach to the current debugger straight after registration on the used debug server. You can select several types of debug items. If the type of debug item is marked as the Background Job, this means that as soon as the 1C:Enterprise server, which is running in debug mode, starts the background job, it will automatically be attached to the current debugger.

On the right part of the dialog box, you can specify an additional filter of debug items (Filters of debug items). The additional filter of debug items, in addition to specifying types of debug items, also includes the filter by users, as well as by the values of separators.

A debug item will be automatically attached to Debugger if it matches one of the enabled filters. This debug item matches the filter by item type, runs on behalf of the specified or one of the specified users, and the separators are set to the specified values.

The filter that is configured in the Automatic attachment of Debug Items on the debug server dialog box, combines a filter by debug type and by debug item filters "by OR". So the debug item will be automatically attached if it matches one of the set debug types OR matches one of the enabled filters.

The values set in this dialog box start working immediately and until the next change of settings.

A common list is used to filter available debug items. A list of debug item filters can be exported to a file and imported from a file.

32.2.2.2.4. Debug server

General information

Debug server (dbgs) is an application that acts as an intermediary between the debugger and various debug items.

The debug server can be started in several ways:

• From Designer, when debugging an application in file mode.
• From server cluster, if debugging mode is enabled for the cluster.
• From application developer, if it is necessary to implement complex debugging scenarios. In this case, you can also register the debug server as an operating system service (for Windows OS) or start it as a “demon” (for Linux OS).

In case the debug server is started by other components of the 1C:Enterprise, all the necessary settings of the debug server are automatically configured by these components.

If you need to run the debug server manually, use the command-line parameters.

Getting the debugger address

To retrieve the address of debug server for interacting with the Designer debugger, you need to perform the following steps:

1. Open the dialog for attaching debug items Main menu ‑ Debug ‑ Attach.
2. Click Settings.
3. Copy information from the Debug Server: line.

Test the debug server performance

The debug server performance can be tested as follows:

1. Retrieve the address of the debug server, for example, in Designer.
2. Enter the obtained address in the address bar of any web browser.
3. The debug server is functioning normally if the web browser displays the following information:

1C:Enterprise 8.3 Debug Server (8.3.7.1140) © '1C' 1996 2022 - it works!

<< Prev   Next >>