Debugging/de
From OpenSimulator
(→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. | ||
| − | = | + | =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. | * 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 17:27, 25 April 2016
 |
Languages: |
|
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.
