多线程调试C程序

Question

I want to debug a C program running multiple TCP server threads. I cannot set up a sophisticated Debugging tool as I have to debug in an embedded linux(busy box). I hoped it would natively support gdb.

SO I started with gdb. Once I type run, the server seems to run in the background but gdb returns the prompt and "Program received signal SIG64 (Real-time event 64)" message(related to pthread I guess). I know it has to do be something with the main getting forked into several threads. But I have no clue how to debug this. Any starting points would be so helpful.

Also, is there someother "trace" like debuggers, small footprint that I can use?

Please help

Answer 1

Most often, debugging a multi-threaded application is difficult with a debugger. The best way is to either try and isolate the bug to a single-threaded case, or use debug prints in suspect locations until the bug is discovered.

It's no help with your specific issue, but it's the best advice I've learned while working with multi-threaded applications, especially embedded.

Answer 2

See in such case I usually do this:

1. Make a thread wise log file and have all stdout and stderr output redirect in that log file ... maybe this will help you for that: In multi thread application how can i redirect stderr & stdout in separate file as per thread?

2. Keep track of global variables between all threads. Improper use of global variables tends to cause problems.

3. If you are using a mutex then check that it will not create deadlocks. In conditional & semaphore design always try to track of all those threads on paper.

Answer 3

I recommend you to use memory access check program like valgrind. In my case, many of bugs are caused by illegal memory handling. It's hard to find bug on multi-threaded program so using memory leak checking program is a better way to figure out bugs causes.

Answer 4

GDB has a few functions for debugging with multiple threads. For example, you can run the command i threads to view the currently existing threads. Here is a link that may be helpful: https://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_24.html .

Answer 5

some tricky idea ..

1. add sleep(some times) into the thread to debug as starting point
2. after program is running, check pid of thread (using ps with -L option)
3. run gdb program {pid} or call attach {pid} in gdb prompt
4. after sleep, u can trace next step for that thread

Don't forget attaching must be done before sleep time is gone.

As remarked above, testing on single thread or using text logging facility is good choice.