On Wednesday 16 July 2008 13:41:46 Edward Sutton wrote: > I have had a very hard time trying to debug which has hindered my work on > some projects. In particular I have had trouble properly grasping how to > work with debugging multi threaded applications, memory errors, and stack > corruption. I know that it is not a five minute learning process to absorb > such knowledge, but I have not yet found helpful references. I have had > best luck trying to logically guess a location close to the problem, then > setting a break and walking through the code. Once I hit a segfault, I run > through the code with a breakpoint bringing me to just before the problem, > but do not always understand how to go further. Strange things I see look > like bad pointer addresses or the problems being caused within another > thread. Since moving to FreeBSD7, I have been unable to use valgrind (which > did not seem to help much on multi threaded apps) and I have not found a > way to test binaries in the work directories and have had to install it to > test it. At present, either gdb alone or kdbg seem to be the only ways I > have been able to get even partially reliable responses from gdb because > other interfaces disregard breakpoints and interrupts to execution. Are > such difficulties common? On another similar topic, is there a good place > to start learning about limitations to system internals, such as > kern.ipc.shmmax and why I may 'not' want to set it to excessively high > values or how other values relate to changing it? How can I tell what cap > is occurring, whether it be a system limit or something controlled within > the app such as with pthread_attr_setstacksize() and how are 'proper' > values determined? The books "advanced programming in the unix environment" > and "programming with posix threads" help me learn the unix world a bit > better, but without debugging knowledge I find it hard to get anywhere with > writing more than my high school level of programs and very difficult to > get anywhere on the projects of others once threads and/or dynamic memory > is involved. Any suggested course for further study from here? > Thanks again, > Edward Sutton, III
Debugging threaded applications is an exercise in frustration and downright irritation. There aren't many easy methods. It seems that you're already familiar with gdb so brush up on how to attach to specific threads within the application and such. Usually, it seems that problems with multi-threaded programming come from two threads trying to access the same structure, or object, at the same time. Look through your code and make sure you're not doing something like this. For example, one thread is trying to read from the same file another is trying to read from thus getting file pointers confused. Please note that this scenario only causes problems if the file was opened in one thread and then the file handle was passed to two others (probably not the best way to do things but . . .). Andy _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
