tags:

views:

41

answers:

2

hello, when i run the core file in gdb, gdb doesn't show where the error is coming from or what line in the application that causes the problem.

i'm using the compiler options -g -DDEBUG -D_DEBUG, but it doesnt seem help.

Any help would be appreciated, thanks.

+1  A: 

You could be blowing your stack. For example, after running the following program

#include <stdio.h>
#include <string.h>

int main(void)
{
  int a[10];

  memset(a, 0, 100 * sizeof a[0]);

  return 0;
}

and then running gdb on the resulting core yields

$ gdb oflow core
[...]
Core was generated by `./oflow'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000000000000000 in ?? ()

The output of the where and bt commands isn't terribly useful:

(gdb) where
#0  0x0000000000000000 in ?? ()
#1  0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x0000000000000000 in ?? ()
Greg Bacon
A: 

ok, problem solved. i had a recursive function that returned a string, but the problem was there was nothing being returned, but i still don't understand why debugging info wasn't generated, when i step through the code it shows the line numbers i'm stepping through, but i guess because the line it was getting an error was missing? so there was no breakpoint for where it went wrong? when it tried to concatenate itself by recursing into the function, using "+=" it would go into the second call but then crash at the end of the function because nothing was being returned. but shouldn't that have generated an error on the first function call on the line where it didn't return?

thanks.