Debugging/de

From OpenSimulator

(Difference between revisions)
Jump to: navigation, search
(Internal tools)
(Specific areas)
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.
 
* 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.
 +
== Die erstmalige Verbindung ==
 +
Dies stellt die Menschen viel, weil das komplexe Zusammenspiel zwischen den verschiedenen Server-Prozessen in Rastermodus und zwischen Simulator und Betrachter, mit den Zuschauern sowohl auf dem lokalen LAN und über das Internet. Die Probleme sind hier in der Regel aufgrund der Konfiguration statt Open Code Fragen. Siehe [[Troubleshooting]] für weitere Details.
  
== 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.
 
* 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.

Revision as of 18:27, 25 April 2016

Contents

General

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

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 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>

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.

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.

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.

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.

Interne Tools

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.

Es gibt auch einige interne Methoden, die nützlich sein könnten.

  • 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.

Spezifische Bereiche

Allerdings gibt es ein paar Dinge, die wir sagen, über bestimmte Themen Open debuggen. In diesem Abschnitt wird erweitert, wie die Zeit vergeht.

Die erstmalige Verbindung

Dies stellt die Menschen viel, weil das komplexe Zusammenspiel zwischen den verschiedenen Server-Prozessen in Rastermodus und zwischen Simulator und Betrachter, mit den Zuschauern sowohl auf dem lokalen LAN und über das Internet. Die Probleme sind hier in der Regel aufgrund der Konfiguration statt Open Code Fragen. Siehe Troubleshooting für weitere Details.

Probleme nach der Verbindung

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.
  • 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 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:

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.

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.

Personal tools
General
About This Wiki