Re: Any advice for learning debugging threading and stack corruption problems for c/c++?

2008-07-20 Thread Andrew Falanga
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]


Any advice for learning debugging threading and stack corruption problems for c/c++?

2008-07-16 Thread Edward Sutton

  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

_
Keep your kids safer online with Windows Live Family Safety.
http://www.windowslive.com/family_safety/overview.html?ocid=TXT_TAGLM_WL_family_safety_072008___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]