Don't understand backtrace on invalid pointer

This is a discussion on Don't understand backtrace on invalid pointer within the C++ Programming forums, part of the General Programming Boards category; Hi, whenever I quit my program, it will crash instead due to an free(): invalid pointer. When I back trace ...

  1. #1
    Registered User
    Join Date
    Oct 2009
    Posts
    117

    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.

  2. #2
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    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.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  3. #3
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,668
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  4. #4
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,592
    #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
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  5. #5
    Registered User
    Join Date
    Oct 2009
    Posts
    117
    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?
    Last edited by SterlingM; 09-21-2011 at 01:44 PM.

  6. #6
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,714
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. realloc() invalid pointer
    By JayBlay77 in forum C Programming
    Replies: 3
    Last Post: 02-17-2010, 08:55 AM
  2. Analyze of backtrace from gdb, really hard!
    By Pavlus in forum C++ Programming
    Replies: 0
    Last Post: 11-08-2009, 11:28 AM
  3. Help with Backtrace.
    By afflictedd2 in forum C++ Programming
    Replies: 1
    Last Post: 12-09-2008, 04:58 PM
  4. munmap_chunk(): invalid pointer
    By MK27 in forum C Programming
    Replies: 2
    Last Post: 09-05-2008, 03:51 PM
  5. invalid pointer conversion
    By jimzy in forum C++ Programming
    Replies: 8
    Last Post: 04-13-2007, 12:21 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21