Debugging Concurrent and Graphical Applications in Font

Draw PDF417 in Font Debugging Concurrent and Graphical Applications

Although a debugger is a fundamental tool for inspecting applications, it is not the Holy Grail, and it must be used carefully, being aware of the fact that the process will interfere with the normal execution of the application. The most relevant impact that the debugging process has over a running program is the influence over the execution timing, which is a critical aspect of concurrent and graphical applications, which are becoming common nowadays. Sometimes a bug even disappears while using the debugger because of these changes to execution timings. Debugging and testing concurrent applications can be particularly difficult because the use of a debugger is guaranteed to alter execution timings. There is no general rule for debugging concurrent applications, but here we briefly discuss how the debugger can be used in these cases. Consider this simple example of a multithreaded application: #light open System open System.Threading

let t1 = Thread(fun () -> while true do printf "Thread 1\n" ) let t2 = Thread(fun () -> while true do printf "Thread 2\n" ) t1.Start() t2.Start() Threads t1 and t2 access the console, which is a shared resource; when we run the program without a debugger attached, the string printed by the two threads appears interleaved on the console. If you set a breakpoint on the two printf statements and you start a debugging session, you see that stepping automatically moves from one thread to the other and the output of the program is completely different from the one obtained without debugging; this is true also if you disable the breakpoints. The output is even more unbalanced if you set the breakpoint in only one of the two threads. We discussed shared memory multithreaded applications in 13. In these applications, shared objects accessed by different threads are critical resources that may be viewed in the debugger. If the debug of a single thread fails, setting breakpoints in different threads may help to study the dynamic of the application, even if the full interaction of the threads cannot be fully simulated. If this approach fails, it may be useful to introduce tests inside the application and use the Debugger type only when a given condition occurs. Channel-based messagepassing applications are generally easier to debug than those that rely on shared memory, because it is possible to monitor the communication end points using breakpoints or logging messages. Although the careful use of the debugger may help in debugging concurrent applications, sometimes external observation is enough to influence a running program. In these cases, tracing through debug output becomes a viable alternative, and in fact, large systems have different levels of traces to monitor program execution while running. Graphical applications also present issues when debugging. As discussed in 11, the event loop of a GUI application is handled by a single thread, and if this is blocked, the GUI of the application will cease working until it is suspended in the debugger. Consider the following simple application: open System open System.Windows.Forms let f = new Form(Text="Hello world") let b = new Button(Text="Click me!", Dock=DockStyle.Fill) b.Click.Add(fun _ -> b.Text <- "Click me again" MessageBox.Show("Hello world") |> ignore ) f.Controls.Add(b) f.Show() Application.Run(f)

If you set a breakpoint at the MessageBox statement and debug the application, then when the button is clicked, the debugger suspends execution, and the form stops responding. Moreover, the text of the button does not change until the execution is resumed. This effect is because the thread suspended by the debugger is responsible for handling GUI events, including the paint event that will refresh the content of the button updating the button label. More specifically, event handlers can affect the appearance of a form in two ways: by setting properties of graphical controls and by explicitly drawing using a Graphics object. In the first case, the change will not be noticed until the execution is resumed; this is because the property change usually asks for a refresh of the control appearance, which will eventually result in a paint event that must be processed by the thread that is suspended in the debugger. In the second case, updates are immediately visible when a statement involving drawing primitives is executed (unless double buffering has been enabled on the particular window). For example, consider the following program displaying a window with a number of vertical lines: open System open System.Windows.Forms open System.Drawing let f = new Form(Text="Hello world") f.Paint.Add(fun args -> let g = args.Graphics for i = 0 to f.Width / 10 do g.DrawLine(Pens.Black, i*10, 0, i*10, f.Height) ) f.Show() Application.Run(f) You can set the breakpoint at the DrawLine statement and start debugging the application, paying attention to move the debugger window in order to make the application form visible. If you continue the execution one statement at a time, you can see the lines appearing in the form. In this case, the interaction with the graphical system does not trigger an event but interacts directly with the Graphics object by emitting graphic primitives that are rendered immediately. We have discussed the issues of debugging graphical applications by showing examples based on Windows Forms. The same considerations apply to all event systems where a thread is responsible for event notification. For graphical systems such as WPF based on the retention of graphic primitives, things work slightly differently, though analogous considerations can be made.