Member Discussions

Hey.

In my Makefile, I'm compiling with the following flags:

-O -ggdb -g3,

however, the cores that are dumped do not contain any stack information (used by 'info locals' and such). Any idea as to why this does not happen?

I've tried -O -ggdb -g0, -O -g -g3 as well.

You've probably overwritten memory allocated on the stack. This is very common.

For example:

jlambert@agamemnon ~
$ cat memover.c
a() {
  char c[10];
  int i;
  for (i=0;i<50;i++) c[i] = 'x';
}

int main(int argc, char** argv) {
  char c[10];
  a();
  return 0;
}

jlambert@agamemnon ~
$ gcc -g -o memover memover.c

jlambert@agamemnon ~
$ gdb -f memover
...
(gdb) r
Starting program: /home/jlambert/memover

Program received signal SIGSEGV, Segmentation fault.
0x78787878 in ?? ()
(gdb) bt
#0  0x78787878 in ?? ()
#1  0x78787878 in ?? ()
#2  0x78787878 in ?? ()
#3  0x78787878 in ?? ()
#4  0x78787878 in ?? ()
#5  0x00007878 in ?? ()
(gdb) info locals
No symbol table info available.
(gdb)

Results displayed above are version and implementation dependent. YMMV.

I don't seem to remember having purposefully done that to my RoT-based code, however, do you know if this is a standard RoT problem, and if so, do you know where it's located and how it can be fixed? I suppose it's in comm.c's main void, but where?

I don't seem to remember having purposefully done that to my RoT-based code, however, do you know if this is a standard RoT problem, and if so, do you know where it's located and how it can be fixed? I suppose it's in comm.c's main void, but where?

There are 101 creative ways or more to trash the stack. While it's never happened to me personally *kof* *kof*, I have noticed the problem using lesser gifted programmers' sources (aka, Diku derived codes). *ahen*

Here's another example:

/* Following function added by David Moron - copyrighted 1997
 (please see my license for details on how to give me credits and stuffs) */
a() {
char buf[10];
sprintf(buf,'$N gives %s a %s', 'Dorkus', 'big puking shiny sward o duum.');
}

int main(int argc, char** argv) {
  char c[10];
/* Following function added by David Moron - copyrighted 1997
 (please see my license for details on how to give me credits and stuffs) */
  a();
  return 0;
}

You could grep your sources for Mr. David Moron, or you could look for the functions he's fond of abusing.

$ egrep -ch 'strcat|sprintf|strcpy' *.c | gawk '{s+=$1}; END {print s}'
1397

It's probably on one of those 1397 lines. Maybe.

If the bug is repeatable, you can strategically place breakpoints and watches to narrow down the search. If it's not but happens in short order, use 'trace/strace'. There are tools like Valgrind and Electric Fence that will flag suspicious memory manipulations. BTW, Electric Fence won't help you with my examples anyway as it's a malloc/free/new/delete abuse detector. OTOH, Valgrind probably would. I'd outline a complete bug grokking stategy for you, but it's been years since I had any *kof* bugs *kof*, and I have to resort to deliberately concocting examples.

HTH ;-)

So basically, this means that every freaking function can be causing this, just because something ( char c buf in this case ) is reserved both before and inside the function called?

Geee, this is gonna take a while, lol

So basically, this means that every freaking function can be causing this, just because something ( char c buf in this case ) is reserved both before and inside the function called?

Geee, this is gonna take a while, lol

Err no. These bugs are much easier to find than tracking down wild pointers and dynamic memory allocation problems.

I added a tutorial for just your sort of problem (fubared stack) here,
HowToFindStackBugs, on me web page.

So basically, this means that every freaking function can be causing this, just because something ( char c buf in this case ) is reserved both before and inside the function called?

Nope, it's not the variable declaration. Its the buffer overrun. Writing a long string to a small buffer is bound to give you problems.

While Tyche has been pretty thorough (and taught me something as well :), the best way to prevent this kind of error is to remove all calls to the insecure string functions strcat, sprintf and strcpy, and replace them with the safe versions strncat, snprintf and strncpy.

It won't prevent the homemade loops like Tyche showed in his first reply, but it will make your life as a debugger easier.

And Tyches wiki is very nice - even taught me a couple of things :)

Welcor

Thanks alot for your help, Tyche and Welcor.

I will get working now :)