Home

 

Download

 

News

 

Support

 

Admin

 

Dev

 

Screen Shots

 

Grid List

 

Bugs

Languages:

English    Deutsch

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

Verwenden Sie diese Konsole Befehl zum Aktivieren der Protokollierung von HTTP-Anfragen und Antworten in OpenSim oder Robust:

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

Options:

If in or all and
  level <= 0 keine zusätzliche Protokollierung.
  level >= 1 kurze Warnungen protokolliert werden, wenn schlechte Eingangsdaten.
  level >= 2 lange Warnungen protokolliert werden, wenn schlechte Eingangsdaten.
  level >= 3 kurze Hinweise über alle eingehenden nicht-Umfrage HTTP-Anfragen werden protokolliert.
  level >= 4 die Zeit, die Anforderung zu erfüllen protokolliert.
  level >= 5 eine Probe aus dem Anfang der Daten wird protokolliert.
  level >= 6 dann werden die gesamten Daten protokolliert.
  no level angegeben wird, dann wird das aktuelle Niveau zurückgeführt.

If out or all and
  level >= 3 kurze Hinweise über alle ausgehenden Anfragen durch WebUtil gehen werden protokolliert.
  level >= 4 die Zeit, die Anforderung zu erfüllen protokolliert.
  level >= 5 eine Probe aus dem Anfang der Daten wird protokolliert.
  level >= 6 dann werden die gesamten Daten protokolliert.

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.