C++ – How to approach this Linux C++ warning? “can’t find linker symbol for virtual table for `sockaddr_in'”

c++eclipselinker-warning

Ubuntu 10.04 32-bit, eclipse, C and C++

I have a program that uses select() to monitor a bunch of TCP and UDP ports. I create those ports in the usual way (socket(), bind(), listen(), accept() etc.) using sockaddr_in structures.

The program works fine at the command line. I was using the eclipse debugger to fix a bug (fixed now!) when I noticed the following warning:

warning: can't find linker symbol for virtual table for `sockaddr_in' value
warning:   found `operator delete(void*)' instead

Well, after fixing my bug I checked and the warning persisted.

I know that the warnings commence as soon as I enter my ConfigureServer() routine where the ports/sockets get connected. The sockaddr_in structures are declared in the routine and are on the stack. In fact, nothing in the program is yet in the heap. This is a mix of C and C++ with no objects declared or used up to this point.

This is the beginning odf the routine. There are several additional identical bits for other ports.

int      configureServer()
{
   sockaddr_in         servAddr; 

   memset(&servAddr, 0, sizeof(servAddr));
   servAddr.sin_family        = AF_INET;        
   servAddr.sin_port          = htons( g_tcpPorts[0].serverPort ); 
   servAddr.sin_addr.s_addr   = htonl(INADDR_ANY); 

   /* Create and initialize the TCP socket */
   if (( g_tcpPorts[0].serverSock = socket(AF_INET, SOCK_STREAM, IPPROTO_IP)) < 0 )
   {
      PLOG( ERROR ) << "failed to acquire a socket for IO Control Server port:  " << g_tcpPorts[0].serverPort;
      return -1;     // caller will CloseAllPorts();
   } 

// ...........
}

So, my question is, how do I debug and track down the cause of these warnings.

Thanks,

Best Solution

GDB is still less than perfect, especially when it comes to debugging C++ code.

In this case, sockaddr_in is "plain old data" (a C struct without any C++ features). It does not need and should not have any virtual table. If GDB thinks otherwise, that's a problem with GDB.

There are two bugs open in GDB bug database that quite this exact message (for different structs/classes). I would not worry about it too much unless it gets in the way of your debugging.

Related Question