|
Solaris Live Transcripts Index
December 6, 2000
Chat Title: Debugging Multi-Threaded Apps
Guest Speaker: David Ford
This is a moderated forum
LizA: Welcome to Solaris Live, with our guest David Ford. David has been with Sun for 13 years, and has been the Debugger Project (dbx) lead for 4 years. Our topic today is "Debugging Multi-Threaded Applications" and we hope you have lots of questions for David.
LizA: David, to get things started, let me ask you what features the Forte Developer debugger has for supporting multi-threaded debugging.
David F: LizA, the debugger has both a graphical user interface
(WorkShop) and a command-line interface (dbx). Both are able to
display a list of threads. By choosing a particular thread, you can see the stack trace,
registers, and source location of that thread. Relevant commands are "threads" and "thread".
David M: What special techniques would you recommend for debugging a M-T RPC server?
David F: David M, thanks for the question. Depending on how much control you have over the layers in the
application, and how much of it you can compile with -g, you can set breakpoints right at the RPC calls, or the layer that makes RPC calls. If multiple threads are doing RPC, and you have ordering issues because of that, you can use a different tool, our Analyzer, to see what is going on. If you want to see what happens at both ends of the remote calls, you may want to have 2 debuggers running, one on each end of the remote connection.
LizA: Can dbx debug code that has already been optimized?
David F: LizA, yes, dbx provides partial support for optimized code. When analyzing optimized code, you can * Stop execution at the start of any function ("stop in" command)*. Evaluate, display, or modify arguments*. Evaluate, display, or modify global or static variables. However, with optimized code dbx cannot * Evaluate, display,
or modify local (stack) variables. A recent improvement allows dbx to single step within functions. Although with highly re-ordered code, it can be confusing as you step backward or to the same statement twice.
David M: We have full access to both clients and server. The clients are each single-threaded (for now), while the server is M-T. How will the Analyzer help us here? What should we use it for?
David F: David M, the Analyzer is primarily a performance measuring tool,
but it can show how you are using RPC, like a trace. You can turn collecting of analyzer
info on and off from dbx, such as between breakpoints. dbx is also
capable of doing conditional traces if you want a picture of what the app is doing.
bahram: When setting a break point on a thread, does FORTE have the capability to stop the entire application (all threads) or will the other threads continue execution?
David F: bahram,dbx is a synchronous debugger. When it hits an "event", it stops all threads. When you continue or step, it starts all threads. It does have the ability to single-step a given thread if that's what you want.
LizA: Does dbx debug lightweight processes?
David F: LizA, yes, dbx can give you a list of LWPs and allow you to get status, stack, register info just as for a thread. It can do this whether the application uses libthread.so or invokes the LWP system calls directly (though Sun does not recommend the latter).
LizA: How does dbx know that an application is multi-threaded?
David F: LizA, when you compile, you should use -mt (e.g. cc -mt foo.c) which links with -lthread. dbx recognizes a program that dynamically links with libthread.so as using Solaris threads.
LizA: Can you set a break point on a specific thread?
David F: LizA, yes, by specifying the thread in the command as follows
stop in foo -thread t@4 where 't@4' refers to the thread with id 4 as given by the "threads" command.
LizA: Can I force a particular thread to run?
David F: LizA, you cannot. In general when debugging MT applications, I
recommend you take a "stand back and watch" approach rather than trying to force your will on the program's natural flow of execution.
LizA: How do you use multiple processors in shared mode?
David F: LizA, you can control the level of concurrency at runtime by
setting the environment variable PARALLEL to a number greater than 1. You can do it at compile time by calling thr_concurrency() from somewhere in your app.
LizA: Are there any problems with debugging if the app has hundreds of threads?
David F: LizA, yes, dbx encounters resource problems if the number of threads reaches about 300 or more. To solve it, we have provided a dbxenv variable "mt_scalable". It is off by default. If you turn it on, dbxcan handle any number of threads, but slows down quite a bit.
LizA: Can I use RTC with my MT application?
David F: LizA, yes, RunTime Checking fully supports MT applications. The messages and leak summaries will specify which thread the problem occurred in.
LizA: I have hundreds of threads in my application. But I don't want to
be inundated with all of them. Is there a way to focus only on the ones I care about?
David F: LizA, yes, "the thread command" has -hide and -unhide options to control the list of threads you want to deal with.
LizA: On behalf of Solaris Live, thank you for joining us today. Our thanks, too, to our guest, David Ford. Be sure to join us again on December 19, 11 a.m. to meet Jim Mauro and Richard Mc Dougall, authors of "Solaris Internals Core Kernel Architecture".
December 2000
Back to Top
| 
Print-friendly Version
