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.

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