gdb attach to process to produce stacktrace

Christopher Layne
Thu Sep 21 04:36:00 GMT 2006

On Wed, Sep 20, 2006 at 03:17:29PM -0400, Ethan Tira-Thompson wrote:
> For a quick example, try figuring out why this example program is  
> crashing... The idea is simple: set up an array of strings containing  
> 'a' through 'z', build a string from 100 random selections, and then  
> display the result.
> No fair figuring it out from looking at the code (it's a suitably  
> subtle newbie type problem, though obfuscated enough it's not  
> glaringly obvious) -- pretend it's a "real" problem in a piece of  
> fairly complicated code that isn't just a dozen lines long, try using  
> gdb to figure it out. (for the lazy/hurried, answer posted here,  
> including comparison to what happens in cygwin: http://ethan.tira- 
> )

Had to admit to pull up the test case in a debugger because Ethan
was right, it wasn't obvious ;). Anyways, my method of dealing with
the immediate segfault type situation is to pull it up in gdb and
hope for a violation that will give me a useful backtrace. If that
doesn't occur, I just do a general 'b main' and next until I step
over the function that causes it and then do the same thing within
the violating function. In this case it was easy - since I recognized:

  37619 [main] whack 2976 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
  38212 [main] whack 2976 open_stackdumpfile: Dumping stack trace to whack.exe.stackdump

as being a typical buffer walk off *and* the fact that it wasn't a
large amount of iterations (which is really what made things to be
easy - otherwise it's serious pain).

int initStrs(char* strs[]) {
  // initialize a string for each letter^M
  int i;
  for(i=0; i<'z'-'a'; i++) {^M
    strs[i][0]='a'+i; // current letter^M
    strs[i][1]='\0';  // null terminate for a c-style string^M
  return 26;


(gdb) p 'z' - 'a'
$16 = 25

Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list