So I'm noticing some severely incorrect behavior from calls to standard library functions inside GDB. I have the following program to illustrate:

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

int main(int argc, char *argv[]) {
  char *s1 = "test";
  char *s2 = calloc(strlen("test")+1,sizeof(char));


  printf("string constant: %lu\n", strlen(s1));
  printf("allocated string: %lu\n", strlen(s2));


  return 0;

When run from the command-line, this program outputs just what you'd expect:

string constant: 4
allocated string: 4

However, in GDB, I get the following, incorrect output from calls to strlen():

(gdb) p strlen(s1)
$1 = -938856896
(gdb) p strlen(s2)
$2 = -938856896

I'm pretty sure this is a problem with glibc shipped with Ubuntu (I'm using 10.10), but this is a serious problem for those of us who spend lots of time in GDB.

  1. Is anyone else experiencing this kind of error?

  2. What's the best way to fix it? Build glibc from source? (I'm already running a version of GDB built from source)


The library is working just fine. The program reports the correct value even when run under gdb. The bug seems to be in the way that gdb is evaluating the expression and forcing the target program to call the function. I'm seeing this same behavior on 10.04 as well. Strangely p printf("foo\n") correctly prints 4.

It seems that gdb is confused because strlen is a builtin. If you do this:

int (*len)(char *) = strlen;

And then have gdb print len("foo") you get the correct result.

  • When did strlen become a builtin in gdb? And why does it only fail on Debian/Ubuntu systems? – alesplin Feb 18 '11 at 22:39
  • @alesplin it is a built in in gcc, not gdb. – psusi Feb 19 '11 at 3:34
  • Right. Had me worried there for a minute. The problem is other library functions (or "builtins") work when called directly from GDB. I rely on this quite heavily, but since I got a new work computer running Ubuntu, I can't use strlen, strcmp, etc because they are broken. Your proposal of declaring a function pointer to strlen did work, but is not really feasible for our environment. – alesplin Feb 19 '11 at 5:00
  • @alesplin builtin means it is built into the compiler, not a library function. Only certain library functions are built in. This means that the compiler directly generates the code to implement them in the place where they are used, rather than calling an actual library function. – psusi Feb 20 '11 at 0:12
  • This is even more problematic then, as other functions declared by the gcc documentation to be builtins (atoi,isdigit,isupper) work as expected. So if it's not libc, and all builtins aren't broken, does that mean Ubuntu ships a wonky gcc? I've tried this with Ubuntu's gdb (7.2), and my own (6.7.1 built from source). – alesplin Feb 20 '11 at 5:56

This is a known bug in eglibc apparently. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594740

  • I've seen this, and it's somewhat disturbing to me that such a glaring problem upstream can remain unsolved for so long. – alesplin Mar 14 '11 at 18:47
  • OMG, still not solved. – karlphillip Mar 31 '11 at 23:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.