segfault of malloc_consolidate from gethostbyname [duplicate]

Question

This question already has answers here:

Segfaults in malloc() and malloc_consolidate() (2 answers)

Closed 8 years ago.

Some background information:

I'm working on a group project for my networks class. We are to implement a Key Distribution Center with 3 parts; the KDC itself, an initiator (A) and a responder(B) using c++ with g++ on RedHat 6 servers owned by the university.

We've been using this Practical Sockets library and things have been going relatively smoothly.

The Problem:

My partner and I have started to get segfaults when calling Unix's gethostbyname() function specifically in the fillAddr() function.

// Function to fill in address structure given an address and port
static void fillAddr(const string &address, unsigned short port, 
                     sockaddr_in &addr) {
  memset(&addr, 0, sizeof(addr));  // Zero out address structure
  addr.sin_family = AF_INET;       // Internet address

  hostent *host;  // Resolve name
  if ((host = gethostbyname(address.c_str())) == NULL) { /* offending line */
    // strerror() will not work for gethostbyname() and hstrerror() 
    // is supposedly obsolete
    throw SocketException("Failed to resolve name (gethostbyname())");
  }
  addr.sin_addr.s_addr = *((unsigned long *) host->h_addr_list[0]);

  addr.sin_port = htons(port);     // Assign port in network byte order
}

We've used valgrind, GDB, "cout s" and such to debug but have been making negative progress. Here is what a GDB backtrace tells us (server names censored, typical "server.college.edu" addresses used):

Program received signal SIGSEGV, Segmentation fault.
0x00000039b1a7621b in malloc_consolidate () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.107.el6.x86_64 libgcc-4.4.7-3.el6.x86_64 libstdc++-4.4.7-3.el6.x86_64
(gdb) backtrace
#0  0x00000039b1a7621b in malloc_consolidate () from /lib64/libc.so.6
#1  0x00000039b1a79385 in _int_malloc () from /lib64/libc.so.6
#2  0x00000039b1a7a911 in malloc () from /lib64/libc.so.6
#3  0x00000039b1b03265 in gethostbyname () from /lib64/libc.so.6
#4  0x00000000004033f7 in fillAddr (address="KDC", port=9284, addr=...)
    at PracticalSocket.cpp:72
#5  0x0000000000404484 in UDPSocket::sendTo (this=0x7fffffffe410, buffer=0x6102a0, bufferLen=40, foreignAddress=
    "KDC", foreignPort=9284) at PracticalSocket.cpp:299
#6  0x00000000004085e2 in sendRecv (sock=..., message="2007|137.28.8.164|SERVER_B|1234", addr=
    "KDC", port=9284) at initiator.cpp:144
#7  0x0000000000407a3f in getSessionKey (sock=..., kdc_addr=0x40aa84 "KDC",
    resp_addr=0x40aa98 "RESPONDER", nonce="1234") at initiator.cpp:88
#8  0x0000000000407546 in main (argc=1, argv=0x7fffffffe548) at initiator.cpp:49

Let me explain negative progress:

It seems the more we compile, test, debug, etc. with only minor changes such as additional std::cout's and the like, the less our code executes. This fillAddr() function is used, successfully, several times at least at first. Now will reliably segfault caused by malloc_consolidate().

The following is the current state of affairs:

*** glibc detected *** ./kdc: malloc(): memory corruption: 0x000000000132b7d0 ***

*** glibc detected *** ./kdc: malloc(): memory corruption: 0x000000000132b7d0 ***

...


*** glibc detected *** ./kdc: malloc(): memory corruption: 0x000000000132b7d0 ***

This fills our console window of the KDC.

Any help will be greatly appreciated. If you would like more information, please let me know.

Answer 1

If you're crashing within the innards of the malloc-type functions, you've almost certainly corrupted the memory arena.

At some point, you've (for example) allocated 30 bytes then tried to fill it with 60 bytes of data.

You need to track down the root cause of this problem which is, unfortunately, not in the code you've shown. It's far more likely to be in your own code, at some indeterminant point before you call gethostbyname(). Look for anywhere where you allocate heap memory then write to it.

Your "negative" progress is also a good indication of this sort of problem since a trashed arena can cause myriad problems.