| << Prev | - Up - | Next >> |
Ozcar currently suffers from a number of limitations. Most of these are not severe, since simple workarounds are available.
Often, it is not be practical or possible to recompile all code of an application (including all used libraries) with debug information. Ozcar will happily attach threads executing mixed debug and non-debug code, but only if they execute a step point within code compiled with debug information or a static breakpoint. Furthermore, single-stepping and environment information will not be available within non-debug code.
Long-running applications, such as server applications, depend on tail-call optimization to implement their toplevel loop. Tail-call optimization causes stack frames to be popped before the activation of another procedure if the corresponding call is the last thing to happen within a procedure body. Thus, tail-call optimization limits stack growth. Within debug code, tail-call optimization is disabled, and long-running programs as well as programs with deep recursion may abort due to excessive stack growth.
As a workaround, implement the top-level loop of server applications in a separate component compiled without debug information.
Due to maintenance of the runtime environments, values may be referenced from closures that would not be referenced in production code. This can lead to different dynamic behaviour with respect to pickling and garbage collection: Pickling may produce larger pickles or fail due to resources or stateful data structures. Garbage collection may not be able to release as much memory. Finalizers may be called later.
Thread IDs are 16-bit integers, and as such wrap around pretty quickly. As a consequence, they may often not be unique. This can cause the thread forest display and in particular navigation to become confused when debugging massively concurrent applications, because parent-child relationships cannot be correctly determined. Note however that actions performed on and events generated by threads will always be associated correctly.
Currently, Ozcar will not attach any thread that is not executing in the toplevel space. To debug a search script, execute it on the toplevel as a workaround.
When debugging remote threads (or distributed applications), the values displayed in stack frames and environments are only approximations of the actual values on the remote site obtained through reflection. Currently, the Query dialog executes queries locally and thus operates on the approximations instead of executing remotely and operating on the actual values.
| << Prev | - Up - | Next >> |