Don't understand backtrace on invalid pointer

Hi, whenever I quit my program, it will crash instead due to an free(): invalid pointer. When I back trace with gdb, this what I get -

Code:

---

(gdb) back
#0  0xb7fe2424 in __kernel_vsyscall ()
#1  0xb7b3c751 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0xb7b3fb82 in *__GI_abort () at abort.c:92
#3  0xb7b7318d in __libc_message (do_abort=2, fmt=0xb7c37738 "*** glibc detected *** %s: %s: 0x%s ***\n")
    at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#4  0xb7b7d281 in malloc_printerr (action=<value optimized out>, str=0x6 <Address 0x6 out of bounds>, ptr=0xb7a33b70)
    at malloc.c:6267
#5  0xb7b7ead8 in _int_free (av=<value optimized out>, p=<value optimized out>) at malloc.c:4795
#6  0xb7b81bbd in *__GI___libc_free (mem=0xb7a33b70) at malloc.c:3739
#7  0xb7f5e7c5 in Fl_Preferences::Node::~Node() () from /usr/lib/libfltk.so.1.1
#8  0xb7f5fd6f in Fl_Preferences::RootNode::~RootNode() () from /usr/lib/libfltk.so.1.1
#9  0xb7f5fdf7 in Fl_Preferences::~Fl_Preferences() () from /usr/lib/libfltk.so.1.1
#10 0xb7b41688 in __cxa_finalize (d=0xb7faf8c0) at cxa_finalize.c:56
#11 0xb7f2c804 in ?? () from /usr/lib/libfltk.so.1.1
#12 0xb7f98da0 in _fini () from /usr/lib/libfltk.so.1.1
#13 0xb7ff1226 in _dl_fini () at dl-fini.c:248
#14 0xb7b412bf in __run_exit_handlers (status=0, listp=0xb7c54304, run_list_atexit=true) at exit.c:78
#15 0xb7b4132f in *__GI_exit (status=0) at exit.c:100
#16 0xb7b28c7e in __libc_start_main (main=0x804f2e0 <main>, argc=5, ubp_av=0xbffff464,
    init=0x8060110 <__libc_csu_init>, fini=0x8060100 <__libc_csu_fini>, rtld_fini=0xb7ff1040 <_dl_fini>,
    stack_end=0xbffff45c) at libc-start.c:260
#17 0x0804a8d1 in _start ()

---

None of these are files in my program. I can't really make anything useful out of it. The only thing that stands out to me is #4, but I don't know what to do about it. Can someone try to explain what this is trying to tell me or what to look for? Any help is appreciated.

Kind of hard to tell, I think, without more context and maybe even some code. What are the libraries you are using, etc?

If you have gone out of bounds somewhere, you may have written over a memory address, then when that becomes relevant, you have a problem. Those are hard to find, but if you have access to valgrind, it will probably make the process much much easier by reporting an "access violation" during runtime at the point when the overwrite occurs.

Got any C arrays? Change 'em to std::array/std::vector to catch out-of-bounds access.
Using any C strings? Change 'em to std::string to stop bugs causing buffer overflows.
Using anything allocated with new? Use smart pointers to take care of freeing to avoid double-free.

#7 0xb7f5e7c5 in Fl_Preferences::Node::~Node() () from /usr/lib/libfltk.so.1.1
#8 0xb7f5fd6f in Fl_Preferences::RootNode::~RootNode() () from /usr/lib/libfltk.so.1.1
#9 0xb7f5fdf7 in Fl_Preferences::~Fl_Preferences() () from /usr/lib/libfltk.so.1.1
Running destructors in Fast Light Toolkit (FLTK)

#14 0xb7b412bf in __run_exit_handlers (status=0, listp=0xb7c54304, run_list_atexit=true) at exit.c:78
#15 0xb7b4132f in *__GI_exit (status=0) at exit.c:100
#16 0xb7b28c7e in __libc_start_main (main=0x804f2e0 <main>, argc=5, ubp_av=0xbffff464,
If you were to get your startup library code, it would look something like this

Code:

---

libc_start_main ( argc, argv ) {
    // some stuff
    int result = main( argc, argv );
    GI_exit( result );
    // some more stuff
}

---

Basically, you've done a normal return from your main, and now it is running the global destructors in fltk.

Two things to do/consider.
1. Have a look at your code to see if there is a better way of cleaning up the library.
2. +1 for MK27's suggestion for running valgrind

Thanks for the replies everyone. I am about to start up on this code again, but first -
I use valgrind, but it doesn't crash with valgrind...it just exits normally. According to Valgrind there is nothing that I can really do about it. I do get some messages at the start though saying -

Code:

---

==5275== Thread 3:
==5275== Conditional jump or move depends on uninitialised value(s)
==5275==    at 0x40250BB: strlen (mc_replace_strmem.c:282)
==5275==    by 0x805F438: udpserver::communicate() (char_traits.h:263)
==5275==    by 0x805B6F3: ServerControl::udp_comm_thread(void*) (servercontrol.cpp:196)
==5275==    by 0x403E954: start_thread (pthread_create.c:300)
==5275==    by 0x447BE7D: clone (clone.S:130)
==5275==  Uninitialised value was created by a stack allocation
==5275==    at 0x805F406: udpserver::communicate() (udpserver.cpp:141)
==5275==
==5275== Syscall param socketcall.recvfrom(fromlen_in) points to uninitialised byte(s)
==5275==    at 0x4046428: recvfrom (socket.S:100)
==5275==    by 0x805B6F3: ServerControl::udp_comm_thread(void*) (servercontrol.cpp:196)
==5275==    by 0x403E954: start_thread (pthread_create.c:300)
==5275==    by 0x447BE7D: clone (clone.S:130)
==5275==  Address 0x59d634c is on thread 3's stack
==5275==  Uninitialised value was created by a stack allocation
==5275==    at 0x805F406: udpserver::communicate() (udpserver.cpp:141)
==5275==
==5275== Syscall param socketcall.recvfrom(fromlen_out) points to uninitialised byte(s)
==5275==    at 0x4046428: recvfrom (socket.S:100)
==5275==    by 0x805B6F3: ServerControl::udp_comm_thread(void*) (servercontrol.cpp:196)
==5275==    by 0x403E954: start_thread (pthread_create.c:300)
==5275==    by 0x447BE7D: clone (clone.S:130)
==5275==  Address 0x59d634c is on thread 3's stack
==5275==  Uninitialised value was created by a stack allocation
==5275==    at 0x805F406: udpserver::communicate() (udpserver.cpp:141)

---

The weird part is that servercontrol.cpp:196 is just calling a function (myUDP->communicate()). And udpserver.cpp:141 is just the start of that function. I would say there aren't any problems in there, but apparently I missed something. The function is small, its just -

Code:

---

void udpserver::communicate() { //line 141

    struct sockaddr_storage their_addr;
    socklen_t their_addr_size;
    socklen_t addr_len;
    int num_read;
    char in[255];

    while(!done) {

        num_read = recvfrom(fd, in, 255 , 0, (struct sockaddr *)&their_addr, &addr_len);
        if (num_read < 0 ) {}

        else {
            //cutoff index
            int term = 10;
            while(isdigit(in[term]) || in[term] == '-')
                term++;
            in[term] = '\0';
            //std::cout<<"\nRead: "<<in;

            //check which client
            if(in[2] == '1')
                get_message(in, 1);
            else
                get_message(in, 2);

            //wait and clear in
            usleep(5000);
            memset(&in, 0, term);
        }  //end else
    }  //end while
    close(fd);
}  //END COMMUNICATE

---

If you see anything that stands out can you tell me?

Code:

---

num_read = recvfrom(fd, in, 255 , 0, (struct sockaddr *)&their_addr, &addr_len);

---

Yeah there is a problem with this call. Since &their_addr isn't a NULL pointer, read what happens.

Quote:

---

Originally Posted by man recvfrom

The recvfrom() and recvmsg() system calls are used to receive messages
from a socket, and may be used to receive data on a socket whether or not
it is connection-oriented.

If address is not a null pointer and the socket is not connection-ori-
ented, the source address of the message is filled in. The address_len
argument is a value-result argument, initialized to the size of the
buffer associated with address, and modified on return to indicate the
actual size of the address stored there.

---

I just have to wonder if this is what you really want. If you want to read from a connected socket you could pass NULL instead of an uninitialized socket. As it stands the recvfrom() function's behavior is undefined, as the pointer will be interpreted as a socket. What socket? We don't know.

It should follow that since you use uninitialized values in the recvfrom() function, that it's return value is also undefined, hence the condition based on read_num depends on uninitialized values.