Debugging/de - Revision history

Manni: /* Threadpool Activity */

2024-07-19T12:16:41Z

‎Threadpool Activity

Manni: /* Probleme nach der Verbindung */

2024-07-19T12:15:29Z

‎Probleme nach der Verbindung

Manni: /* HTTP Activity */

2016-04-26T01:40:07Z

‎HTTP Activity

Manni: /* Specific areas */

2016-04-26T01:27:57Z

‎Specific areas

Manni: /* Internal tools */

2016-04-26T01:18:15Z

‎Internal tools

Manni at 01:14, 26 April 2016

2016-04-26T01:14:27Z

Manni: /* Thread Dumps */

2016-04-26T01:10:00Z

‎Thread Dumps

Manni: /* General */

2016-04-26T01:08:24Z

‎General

Manni: Created page with "=General= In general, OpenSimulator is a difficult system to debug due to its high concurrency, complexity and the lack of good tools for Mono on the Linux/Mac side. We won'..."

2016-04-26T01:05:46Z

Created page with "=General= In general, OpenSimulator is a difficult system to debug due to its high concurrency, complexity and the lack of good tools for Mono on the Linux/Mac side. We won'..."

New page

=General=

In general, OpenSimulator is a difficult system to debug due to its high concurrency, complexity and the lack of good tools for Mono on the Linux/Mac side. We won't go through general information about using debuggers here, you can find it elsewhere on the net. However, one thing to note is that the debugger must be capable of ignoring the SelfDeleteException - this is currently used by the XEngine script engine to kill scripts aborted via the llDie() LSL command.

=Thread Dumps=

If the simulator or some aspect of it appears to be frozen, one possibility is that threads are in deadlock for some reason. In this case, a dump of all threads can provide useful information.

In Mono, you can get this dump by sending the SIGQUIT unix signal to the Mono process. You can do this either with CTRL + \ on the console or by a command such as

kill -SIGQUIT <pid>

This dump may be very large. If you are reported this trace for debug purposes, it is essential that it is captured and reported accurately.

If at all possible, please start Mono with the --debug switch so that line numbers are added to traces (there is no major performance penalty on using this switch). This is sometimes the only way to pin down which parts of the code threads may be deadlocked on.

Sending SIGQUIT to Mono may make it unstable. If you do this, you are advised to restart the process in question after all useful debugging information has been captured.

'''Not sure how to achieve the same result on Windows, if this is possible at all. If someone knows would be great to get this section filled in.'''

=Internal tools=

There are also logging statements through the OpenSimulator code, some of which are commented out. Generally these can be uncommented to provide extra useful information, though you may have to resort to adding new log statements.

There are also some internal methods that might be useful.

* Util.PrintCallStack() - This will print the call stack at the time the method is executed before continuing execution. Unfortunately, due to Mono limitations can only work on the current thread.

=Specific areas=
However, there are a few things we say about debugging specific OpenSimulator issues. This section will be expanded as time goes on.

== Initial connection ==
This trips people up a lot because of the complex interplay between different server processes in grid mode and between simulator and viewer, with viewers on both the local LAN and over the Internet. Problems here are generally due to configuration rather than OpenSimulator code issues. See [[Troubleshooting]] for more details.

== Problems after connection established ==
Here are some commands that can help you get more information is you have problems when a connection has already been established (e.g. avatars stopping in place), etc. You can get more help on any of these commands by typing "help <command-name>" on the simulator console.

* debug packet <0-256> [<first-name>] [<last-name>] - this command logs various incoming and outgoing packets depending on the packet level (0-256). This can help determine whether there is any packet flow between simulator and client at all.

* show queues [<full>] - this command shows packet in, out and resent statistics for particular clients, as well as the packets being queued. Monitoring the in and outbound packet numbers will show if packets are getting through between simulator and viewer. If resent is climbing rapidly then its likely you have connection issues since the simulator is having to resend lots of packets that aren't being acknowledged by the viewer. If the Q numbers increase without going down then clients may have extremely small bandwidth limits or the outgoing network connection from the simulator may be overwhelmed.

* show users - show users active on the simulator

* show connections - show information about individual client connections, including their IP address and whether they are active (in OpenSimulator 0.7.4 dev code only).

== Threadpool Activity ==

A lot of the work in OpenSim is done in tasks that are run on a general-purpose threadpool. You can [[General-Purpose Threadpool|enable logging that shows activity in this threadpool]].

== HTTP Activity ==

Use this console command to enable logging of HTTP requests and responses in OpenSim or Robust:

debug http in|out|all [<level>]

Options:
<pre>
If in or all and
level <= 0 then no extra logging is done.
level >= 1 then short warnings are logged when receiving bad input data.
level >= 2 then long warnings are logged when receiving bad input data.
level >= 3 then short notices about all incoming non-poll HTTP requests are logged.
level >= 4 then the time taken to fulfill the request is logged.
level >= 5 then a sample from the beginning of the data is logged.
level >= 6 then the entire data is logged.
no level is specified then the current level is returned.

If out or all and
level >= 3 then short notices about all outgoing requests going through WebUtil are logged.
level >= 4 then the time taken to fulfill the request is logged.
level >= 5 then a sample from the beginning of the data is logged.
level >= 6 then the entire data is logged.
</pre>

In particular, to get a good idea of the communications flow turn on debug level 5 on both the simulator and Robust to see short snippets from each request and response. This will also show HTTP requests between the viewer and the Simulator.

@@ Line 45: / Line 45: @@
 * show connections - zeigt Informationen über einzelne Client-Verbindungen an, einschließlich ihrer IP-Adresse und ob sie aktiv sind (nur im OpenSimulator 0.7.4 Entwicklercode).
-== Threadpool Activity ==
+== Threadpool-Aktivität ==
-A lot of the work in OpenSim is done in tasks that are run on a general-purpose threadpool. You can [[General-Purpose Threadpool|enable logging that shows activity in this threadpool]].
+Ein Großteil der Arbeit in OpenSim erfolgt in Aufgaben, die auf einem allgemeinen Threadpool ausgeführt werden. Sie können [[General-Purpose Threadpool|Protokollierung aktivieren, die die Aktivität in diesem Threadpool zeigt]].
 == HTTP Activity ==

@@ Line 37: / Line 37: @@
 Hier sind einige Befehle, die Ihnen helfen werden, weitere Informationen zu erhalten, wenn Sie Probleme haben und wenn bereits eine Verbindung hergestellt wurde (zB Avatare an Ort und Stelle zu stoppen), usw. können Sie weitere Hilfe auf einen dieser Befehle erhalten, indem sie "help <command-name>" in der Simulator-Konsole eingeben.
-* debug packet <0-256> [<first-name>] [<last-name>] - this command logs various incoming and outgoing packets depending on the packet level (0-256).  This can help determine whether there is any packet flow between simulator and client at all.
+* debug packet <0-256> [<first-name>] [<last-name>] - dieser Befehl protokolliert verschiedene eingehende und ausgehende Pakete abhängig vom Paketlevel (0-256). Dies kann helfen festzustellen, ob überhaupt ein Paketfluss zwischen Simulator und Client stattfindet.
-* show queues [<full>] - this command shows packet in, out and resent statistics for particular clients, as well as the packets being queued.  Monitoring the in and outbound packet numbers will show if packets are getting through between simulator and viewer.  If resent is climbing rapidly then its likely you have connection issues since the simulator is having to resend lots of packets that aren't being acknowledged by the viewer.  If the Q numbers increase without going down then clients may have extremely small bandwidth limits or the outgoing network connection from the simulator may be overwhelmed.
+* show queues [<full>] - dieser Befehl zeigt die Statistik der eingehenden, ausgehenden und erneut gesendeten Pakete für bestimmte Clients sowie die in der Warteschlange befindlichen Pakete an. Die Überwachung der Anzahl der eingehenden und ausgehenden Pakete zeigt, ob Pakete zwischen Simulator und Viewer durchkommen. Wenn die Anzahl der erneut gesendeten Pakete schnell ansteigt, deutet dies wahrscheinlich auf Verbindungsprobleme hin, da der Simulator viele Pakete erneut senden muss, die vom Viewer nicht bestätigt werden. Wenn die Q-Zahlen steigen, ohne wieder zu sinken, könnten die Clients extrem geringe Bandbreitenbeschränkungen haben oder die ausgehende Netzwerkverbindung des Simulators könnte überlastet sein.
-* show users - show users active on the simulator
+* show users - zeigt aktive Benutzer auf dem Simulator an
-* show connections - show information about individual client connections, including their IP address and whether they are active (in OpenSimulator 0.7.4 dev code only).
+* show connections - zeigt Informationen über einzelne Client-Verbindungen an, einschließlich ihrer IP-Adresse und ob sie aktiv sind (nur im OpenSimulator 0.7.4 Entwicklercode).
 == Threadpool Activity ==

@@ Line 21: / Line 21: @@
 '''Nicht sicher , wie das gleiche Ergebnis auf Windows zu erreichen, wenn dies überhaupt möglich ist . Wenn jemand wäre toll , weiß in diesem Abschnitt gefüllt zu bekommen.'''
-=Internal tools=
+=Interne Tools=
-There are also logging statements through the OpenSimulator code, some of which are commented out.  Generally these can be uncommented to provide extra useful information, though you may have to resort to adding new log statements.
+Es gibt auch die Anmeldung Aussagen über den Opensimulator-Code, von denen einige auf Kommentar. Im Allgemeinen können diese unkommentiert werden, um zusätzliche nützliche Informationen zur Verfügung zu stellen, wenn Sie das Hinzufügen neuer Protokollanweisungen müssen zurückgreifen kann.
-There are also some internal methods that might be useful.
+Es gibt auch einige interne Methoden, die nützlich sein könnten.
-* Util.PrintCallStack() - This will print the call stack at the time the method is executed before continuing execution.  Unfortunately, due to Mono limitations can only work on the current thread.
+* Util.PrintCallStack() - Damit wird der Call-Stack zum Zeitpunkt druckt das Verfahren vor der Fortsetzung des Ablaufs ausgeführt wird. Leider kann aufgrund Mono Einschränkungen nur für den aktuellen Thread arbeiten.
 =Specific areas=

← Older revision		Revision as of 01:14, 26 April 2016
Line 1:		Line 1:
		+	{{Quicklinks\|Debugging}}
		+
	=General=		=General=

Line 74:		Line 76:

	In particular, to get a good idea of the communications flow turn on debug level 5 on both the simulator and Robust to see short snippets from each request and response. This will also show HTTP requests between the viewer and the Simulator.		In particular, to get a good idea of the communications flow turn on debug level 5 on both the simulator and Robust to see short snippets from each request and response. This will also show HTTP requests between the viewer and the Simulator.
		+
		+	[[Category:German Translations]]

@@ Line 51: / Line 51: @@
 == HTTP Activity ==
-Use this console command to enable logging of HTTP requests and responses in OpenSim or Robust:
+Verwenden Sie diese Konsole Befehl zum Aktivieren der Protokollierung von HTTP-Anfragen und Antworten in OpenSim oder Robust:
   debug http in|out|all [<level>]
@@ Line 58: / Line 58: @@
 <pre>
 If in or all and
-   level <= 0 then no extra logging is done.
+   level <= 0 keine zusätzliche Protokollierung.
-   level >= 1 then short warnings are logged when receiving bad input data.
+   level >= 1 kurze Warnungen protokolliert werden, wenn schlechte Eingangsdaten.
-   level >= 2 then long warnings are logged when receiving bad input data.
+   level >= 2 lange Warnungen protokolliert werden, wenn schlechte Eingangsdaten.
-   level >= 3 then short notices about all incoming non-poll HTTP requests are logged.
+   level >= 3 kurze Hinweise über alle eingehenden nicht-Umfrage HTTP-Anfragen werden protokolliert.
-   level >= 4 then the time taken to fulfill the request is logged.
+   level >= 4 die Zeit, die Anforderung zu erfüllen protokolliert.
-   level >= 5 then a sample from the beginning of the data is logged.
+   level >= 5 eine Probe aus dem Anfang der Daten wird protokolliert.
-   level >= 6 then the entire data is logged.
+   level >= 6 dann werden die gesamten Daten protokolliert.
-   no level is specified then the current level is returned.
+   no level angegeben wird, dann wird das aktuelle Niveau zurückgeführt.
 If out or all and
-   level >= 3 then short notices about all outgoing requests going through WebUtil are logged.
+   level >= 3 kurze Hinweise über alle ausgehenden Anfragen durch WebUtil gehen werden protokolliert.
-   level >= 4 then the time taken to fulfill the request is logged.
+   level >= 4 die Zeit, die Anforderung zu erfüllen protokolliert.
-   level >= 5 then a sample from the beginning of the data is logged.
+   level >= 5 eine Probe aus dem Anfang der Daten wird protokolliert.
-   level >= 6 then the entire data is logged.
+   level >= 6 dann werden die gesamten Daten protokolliert.
 </pre>
-In particular, to get a good idea of the communications flow turn on debug level 5 on both the simulator and Robust to see short snippets from each request and response. This will also show HTTP requests between the viewer and the Simulator.
+Insbesondere eine gute Vorstellung von den Kommunikationsfluss wiederum auf Debug-Level 5 sowohl auf dem Simulator zu bekommen und robuste kurze Ausschnitte aus jeder Anforderung und Antwort zu sehen. Dies wird auch HTTP-Anfragen zwischen dem Betrachter und dem Simulator zeigen.
 [[Category:German Translations]]

@@ Line 29: / Line 29: @@
 * Util.PrintCallStack() - Damit wird der Call-Stack zum Zeitpunkt druckt das Verfahren vor der Fortsetzung des Ablaufs ausgeführt wird. Leider kann aufgrund Mono Einschränkungen nur für den aktuellen Thread arbeiten.
-=Specific areas=
+=Spezifische Bereiche=
-However, there are a few things we say about debugging specific OpenSimulator issues.  This section will be expanded as time goes on.
+Allerdings gibt es ein paar Dinge, die wir sagen, über bestimmte Themen Open debuggen. In diesem Abschnitt wird erweitert, wie die Zeit vergeht.
-== Initial connection ==
+== Probleme nach der Verbindung ==
-This trips people up a lot because of the complex interplay between different server processes in grid mode and between simulator and viewer, with viewers on both the local LAN and over the Internet.  Problems here are generally due to configuration rather than OpenSimulator code issues.  See [[Troubleshooting]] for more details.
+Hier sind einige Befehle, die Ihnen helfen werden, weitere Informationen zu erhalten, wenn Sie Probleme haben und wenn bereits eine Verbindung hergestellt wurde (zB Avatare an Ort und Stelle zu stoppen), usw. können Sie weitere Hilfe auf einen dieser Befehle erhalten, indem sie "help <command-name>" in der Simulator-Konsole eingeben.
-−
-== Problems after connection established ==
-Here are some commands that can help you get more information is you have problems when a connection has already been established (e.g. avatars stopping in place), etc.  You can get more help on any of these commands by typing "help <command-name>" on the simulator console.
 * debug packet <0-256> [<first-name>] [<last-name>] - this command logs various incoming and outgoing packets depending on the packet level (0-256).  This can help determine whether there is any packet flow between simulator and client at all.

@@ Line 5: / Line 5: @@
 =Thread Dumps=
-If the simulator or some aspect of it appears to be frozen, one possibility is that threads are in deadlock for some reason.  In this case, a dump of all threads can provide useful information.
+Wenn der Simulator oder ein Aspekt davon scheint eingefroren zu sein, eine Möglichkeit ist, dass Themen in einer Sackgasse, aus irgendeinem Grund. In diesem Fall kann ein Dump aller Threads nützliche Informationen liefern.
-In Mono, you can get this dump by sending the SIGQUIT unix signal to the Mono process.  You can do this either with CTRL + \ on the console or by a command such as
+In Mono können Sie diesen Dump erhalten durch das SIGQUIT Unix Signal an den Mono-Prozess sendet. Sie können dies entweder mit STRG + \ auf der Konsole oder durch einen Befehl wie
   kill -SIGQUIT <pid>
-This dump may be very large.  If you are reported this trace for debug purposes, it is essential that it is captured and reported accurately.
+Dieser Dump kann sehr groß sein. Wenn Sie diese Spur für Debug-Zwecke gemeldet werden, ist es wichtig, dass es genau erfasst und gemeldet wird.
-If at all possible, please start Mono with the --debug switch so that line numbers are added to traces (there is no major performance penalty on using this switch).  This is sometimes the only way to pin down which parts of the code threads may be deadlocked on.
+Wenn möglich, bitte Mono mit der debug-Schalter starten, so dass Zeilennummern Spuren hinzugefügt werden (es gibt keine großen Leistungseinbußen über die Verwendung dieser Schalter). Dies ist manchmal der einzige Weg, zu fassen, welche Teile der Code Threads Deadlock auf sein können.
-Sending SIGQUIT to Mono may make it unstable.  If you do this, you are advised to restart the process in question after all useful debugging information has been captured.
+Senden SIGQUIT auf Mono kann es instabil machen. Wenn Sie dies tun, sollten Sie den Prozess in Frage neu zu starten, nachdem alle nützlichen Debug-Informationen erfasst wurde.
-'''Not sure how to achieve the same result on Windows, if this is possible at all.  If someone knows would be great to get this section filled in.'''
+'''Nicht sicher , wie das gleiche Ergebnis auf Windows zu erreichen, wenn dies überhaupt möglich ist . Wenn jemand wäre toll , weiß in diesem Abschnitt gefüllt zu bekommen.'''
 =Internal tools=

@@ Line 1: / Line 1: @@
 =General=
-In general, OpenSimulator is a difficult system to debug due to its high concurrency, complexity and the lack of good tools for Mono on the Linux/Mac side.  We won't go through general information about using debuggers here, you can find it elsewhere on the net.  However, one thing to note is that the debugger must be capable of ignoring the SelfDeleteException - this is currently used by the XEngine script engine to kill scripts aborted via the llDie() LSL command.
+Im Allgemeinen ist Open ein schwieriges System aufgrund seiner hohen Parallelität zu debuggen, die Komplexität und der Mangel an guten Werkzeugen für Mono auf der Linux / Mac-Seite. Wir werden nicht durch allgemeine Informationen gehen über Debugger hier verwenden, können Sie es an anderer Stelle im Netz finden können. Allerdings ist eine Sache, zu beachten ist, dass der Debugger ignorieren die SelfDeleteException fähig sein müssen - das derzeit von der xengine Skript-Engine verwendet wird, Skripte über das llDie () LSL-Befehl abgebrochen zu killen.
 =Thread Dumps=