Like Tree1Likes
  • 1 Post By grumpy

mtrace : Free was never allocated

This is a discussion on mtrace : Free was never allocated within the C Programming forums, part of the General Programming Boards category; Hi guys mtrace log says : Code: - 0x0052cfc0 Free 21794 was never alloc'd /home/mtrace/oscam-garbage.c:100 - 0x2aa02220 Free 21919 was ...

  1. #1
    Registered User
    Join Date
    Oct 2012
    Posts
    25

    mtrace : Free was never allocated

    Hi guys

    mtrace log says :
    Code:
    - 0x0052cfc0 Free 21794 was never alloc'd /home/mtrace/oscam-garbage.c:100
    - 0x2aa02220 Free 21919 was never alloc'd /home/mtrace/oscam-garbage.c:106

    here is the releated source code :

    Code:
    void garbage_collector() {
            time_t now;
            int8_t i;
            struct cs_garbage *garbage, *next, *prev;
            
            while (garbage_collector_active) {
                    
                    for(i = 0; i < HASH_BUCKETS; ++i){
                        cs_lock(&garbage_lock[i]);
                        now = time(NULL);
        
                        prev = NULL;
                        garbage = garbage_first[i];  
                        while (garbage) {
                                next = garbage->next;
                                if (now > garbage->time+5) { //5 seconds!
    if(garbage->data)                
     //This is oscam-garbage.c : Line 100 , mentioned in mtrace log    
                   free(garbage->data);
                                        
                                        if (prev)
                                                prev->next = next;
                                        else
                                                garbage_first[i] = next;
    //This is Oscam-garbage.c : line 106
    if (garbage)               
                        free(garbage);
                                }
                                else
                                        prev = garbage;
                                garbage = next;
                        }
                        cs_unlock(&garbage_lock[i]);
                      }
                    cs_sleepms(1000);
            }
            pthread_exit(NULL);
    }
    I did several attempt ( to prevent that error log in mtrace , the error was gone , but seems after that , performance has been reduced (seems after my change more memory leaks happened , actually in while loop , before line 100 , i added line for malloc the garbage , but i know this is not the correct solution , That's why i ask)

    would appreciate if some expert guide me , what is the best solution to fix this bug.(would be thankful , if u would write the code u are meaning , my reading (understanding) with the source code is sheer better than mu English technical concepts reading. )

    p.s: here is entire oscam-garbage.c source code
    Best Regards
    Last edited by jimycn; 10-20-2012 at 03:39 PM.

  2. #2
    Registered User
    Join Date
    Jun 2005
    Posts
    6,174
    Essentially the messages mean your code is calling free() on a pointer that was not returned by malloc(), calloc(), or realloc(). It can also mean calling free() more than once on such a pointer.

    The problem is therefore probably not in the code you have shown.

    The basic rule is that, for every call of malloc()/callo() there needs to be exactly ONE call of free(). Conversely, any pointer provided to free() needs to have been returned by malloc() or calloc(). [That is adapted a bit if your code uses realloc(), but same idea].

    The problem will therefore be in the code doing the malloc/calloc calls, in how such pointers are registered in your "garbage" list, or in intervening code.

    The use of pthread_exit() hints that your code is multi-threaded, which doesn't help make it easier to find such problems. Relatively few implementations of malloc/calloc/realloc/free are thread safe.
    Salem likes this.
    Right 98% of the time, and don't care about the other 3%.

  3. #3
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,422
    malloc , how could free a return value?

    - 0x0052cfc0 Free 21794 was never alloc'd /home/mtrace/oscam-garbage.c:100
    - 0x2aa02220 Free 21919 was never alloc'd /home/mtrace/oscam-garbage.c:106
    You need to be investigating things which add entries into your garbage collection lists.

    For example, some code adds an entry to your garbage collection pool, then decides to call free() directly anyway.


    Do any of your valgrind reports contain any of these?
    ==2996== Invalid write of size X
    ==2996== Invalid read of size Y
    If they do, you need to fix these ASAP.
    You can't debug malloc related issues while the program is still trashing memory it doesn't own.
    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.

  4. #4
    Registered User
    Join Date
    Oct 2012
    Posts
    25
    @Salem
    For example, some code adds an entry to your garbage collection pool, then decides to call free() directly anyway.
    I am not sure if i got your meaning completely , so , Do u mean , I should investigate codes , and if anywhere after add_garbage() , There would be , calling free() too , this would be incorrect and i should remove those free() calling after add_garbage call?

    Do any of your valgrind reports contain any of these?
    Yes , only "Invalid read of size" shown in valgrind log (there is no invalid Write of size) , here is those logs :


    ==12541== 2 errors in context 1 of 10:
    ==12541== Thread 6:
    ==12541== Invalid read of size 4
    ==12541== at 0x804F5B2: write_ecm_answer (oscam.c:1818)
    ==12541== by 0x8079703: reader_get_ecm (oscam-reader.c:469)
    ==12541== by 0x807A378: reader_do_pipe (oscam-reader.c:739)
    ==12541== by 0x807A46A: reader_main (oscam-reader.c:773)
    ==12541== by 0x807A71E: start_cardreader (oscam-reader.c:826)
    ==12541== by 0x403D609: start_thread (in /lib/libpthread-2.11.3.so)
    ==12541== by 0x4233FDD: clone (in /lib/libc-2.11.3.so)
    ==12541== Address 0x50cdb14 is 428 bytes inside a block of size 6,176 free'd
    ==12541== at 0x40226D1: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
    ==12541== by 0x8077500: garbage_collector (oscam-garbage.c:91)
    ==12541== by 0x403D609: start_thread (in /lib/libpthread-2.11.3.so)
    ==12541== by 0x4233FDD: clone (in /lib/libc-2.11.3.so)
    ==12541==
    ==12541== 99 errors in context 2 of 10:
    ==12541== Thread 51:
    ==12541== Invalid read of size 4
    ==12541== at 0x80868B5: ll_lock (module-datastruct-llist.c:49)
    ==12541== by 0x8086CB8: ll_iter_next (module-datastruct-llist.c:194)
    ==12541== by 0x807F130: add_stat (module-stat.c:415)
    ==12541== by 0x804F885: send_reader_stat (oscam.c:1888)
    ==12541== by 0x80501B0: chk_dcw (oscam.c:2093)
    ==12541== by 0x8052879: process_client_pipe (oscam.c:3006)
    ==12541== by 0x805269F: process_input (oscam.c:2955)
    ==12541== by 0x808F533: cc_srv_connect (module-cccam.c:2853)
    ==12541== by 0x808F752: cc_srv_init (module-cccam.c:2899)
    ==12541== by 0x804DCA3: clientthread_init (oscam.c:1157)
    ==12541== by 0x403D609: start_thread (in /lib/libpthread-2.11.3.so)
    ==12541== by 0x4233FDD: clone (in /lib/libc-2.11.3.so)
    ==12541== Address 0x54cc9a4 is 36 bytes inside a block of size 40 free'd
    ==12541== at 0x40226D1: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
    ==12541== by 0x8077500: garbage_collector (oscam-garbage.c:91)
    ==12541== by 0x403D609: start_thread (in /lib/libpthread-2.11.3.so)
    ==12541== by 0x4233FDD: clone (in /lib/libc-2.11.3.so)
    ==12541==
    ==12541== ERROR SUMMARY: 109 errors from 10 contexts (suppressed: 0 from 0)
    Actually , yesterday i had rewriten , cs_malloc , cs_realloc , i removed redundant parameters from cs_malloc (though fixing in entire source tree was such a pain in my ass) and had corrected the cs_realloc behavior completely , after this change , it looks obviously better (use less resources)

    but still in other parts there are some bug like "invalid read" which quoted above , would u please , or any other expert guy , help me with one of those two invalid read error above or guide me please how could i fix it? here is the link of related source code

    Thanks in advance,
    Last edited by jimycn; 10-21-2012 at 01:55 AM.

  5. #5
    Registered User
    Join Date
    Jun 2005
    Posts
    6,174
    Quote Originally Posted by jimycn View Post
    I am not sure if i got your meaning completely , so , Do u mean , I should investigate codes , and if anywhere after add_garbage() , There would be , calling free() too , this would be incorrect and i should remove those free() calling after add_garbage call?
    Salem's point - like mine - is that, somewhere, there is code doing a malloc() call, and some code registering the pointers in the garbage list. You need to investigate the behaviour of that code to find the root cause of your problem.

    Quote Originally Posted by jimycn View Post
    but still in other parts there are some bug like "invalid read" which quoted above , would u please , or any other expert guy , help me with one of those two invalid read error above or guide me please how could i fix it?
    We have already provided you such guidance. The problem is yours to find.

    The thing to remember is that you need to look at all relevant functions together to find the problem. If a problem is occurring with a free() call, then there are two main candidates for the cause

    1) the preceding malloc()/calloc()/realloc() calls.

    2) any code that manipulates the malloc'd/calloc'd/realloc'd pointers (for example, stores them into the garbage list) before they are retrieved and supplied to free().

    There is no alternative other than for you to examine the behaviour of your code, end to end. But remember that the errors you are getting are symptoms, not causes. The causes can be in any code executed before the symptoms are reported.
    Right 98% of the time, and don't care about the other 3%.

  6. #6
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,422
    I am not sure if i got your meaning completely , so , Do u mean , I should investigate codes , and if anywhere after add_garbage() , There would be , calling free() too , this would be incorrect and i should remove those free() calling after add_garbage call?
    That's exactly what I mean.

    > ==12541== at 0x80868B5: ll_lock (module-datastruct-llist.c:49)
    > ==12541== by 0x8086CB8: ll_iter_next (module-datastruct-llist.c:194)
    ...
    > ==12541== Address 0x54cc9a4 is 36 bytes inside a block of size 40 free'd
    Given that this is in the very code you posted in your other thread, what you're trying to do is lock a llist which has already been freed.
    Now, if that results in another call to add_garbage(), then you're well on your way to "Free 21794 was never alloc'd" error message, because you're now trying to free it again!.


    ==12541== by 0x804DCA3: clientthread_init (oscam.c:1157)
    ==12541== by 0x403D609: start_thread (in /lib/libpthread-2.11.3.so)
    ==12541== by 0x4233FDD: clone (in /lib/libc-2.11.3.so)
    vs.
    ==12541== by 0x8077500: garbage_collector (oscam-garbage.c:91)
    ==12541== by 0x403D609: start_thread (in /lib/libpthread-2.11.3.so)
    ==12541== by 0x4233FDD: clone (in /lib/libc-2.11.3.so)

    You've got two threads, trying to use the same bit of data.
    One thread passed the memory to free().
    The other comes along and it's "WTF happened to my memory!?"

    Essentially, something passed a block to add_garbage() in a bad way:
    - it kept a copy of the block for itself (for example, not removing it from the list)
    - it wasn't its job to delete the block at that point in the code (it should be done later)
    - sloppy code that has more than one pointer to a block.
    - memory shared between threads without adequate (or consistently) applied locks.

    > - 0x0052cfc0 Free 21794 was never alloc'd /home/mtrace/oscam-garbage.c:100
    > - 0x2aa02220 Free 21919 was never alloc'd /home/mtrace/oscam-garbage.c:106

    What do these numbers represent?
    Are they perhaps some kind of sequence number, like for example, the 21794 block to be allocated.

    From one test to another, do these numbers remain consistent, or are they generally spread out over a range say between 20K to 25K?
    I doubt it will be consistent, given the involvement of threads, but it's better to ask.
    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.

  7. #7
    Registered User
    Join Date
    Oct 2012
    Posts
    25
    @Salem

    Essentially, something passed a block to add_garbage() in a bad way:
    - it kept a copy of the block for itself (for example, not removing it from the list)
    - it wasn't its job to delete the block at that point in the code (it should be done later)
    - sloppy code that has more than one pointer to a block.
    - memory shared between threads without adequate (or consistently) applied locks.
    I see , Does Those Valgrind or mtrace log have the capability to show or make us know to find Where (which line) cause passing a block to add-garbage.c in a bad way? I mean , Should i investigate code (for the wrong behavior about the code u had described about the code) by reading the code myself , or those debugging tools could make help to find the line of the causes? P.S : If need to use gdb and add some breakpoint for investigating the cause , please let me know which line is good for Breakpoint , to investigate this issue (it seems to me the bug occur frequently ,so i think, i could trace it with gdb)

    > - 0x0052cfc0 Free 21794 was never alloc'd /home/mtrace/oscam-garbage.c:100
    > - 0x2aa02220 Free 21919 was never alloc'd /home/mtrace/oscam-garbage.c:106

    What do these numbers represent?
    I think, it represent the number of time , that Free Was never Alloc'd (but i am not quite sure about that) and it goes to more than 30000 (as said i think represent time of not allocated rather than the byte (u were supposed) , actually after i had rewritten the cs_malloc , cs_realloc
    Those number strated from 4595 . here is the latest mtrace log (other line of not alloc'd was exists before my change ,but in previous post i didn't mention it.

    The other line mtrace where say was never alloc'd is refer to oscam.c :3165 :
    Code:
    if (ptr) free (ptr);   
    // i also quote the containing function  of it in the next Code tag , in this thread
    my guess is above free is involved in the bad behavior of add_garbage (and the main cause) , described above
    But i have no idea how to fix it! but maybe a smart expert guy like u (Salem) could advice me how to fix it...


    Code:
    int32_t process_client_pipe(struct s_client *cl, uchar *buf, int32_t l) {
        if (!cl) return -1;
        uchar *ptr;
        uint16_t n;
        int32_t pipeCmd = read_from_pipe(cl->fd_m2c_c, &ptr);
    
    
        switch(pipeCmd) {
            case PIP_ID_ECM:
                chk_dcw(cl, (ECM_REQUEST *)ptr);
                break;
            case PIP_ID_UDP:
                if (ptr[0]!='U') {
                    cs_log("INTERNAL PIPE-ERROR");
                }
                memcpy(&n, ptr+1, 2);
                if (n+3<=l) {
                    memcpy(buf, ptr, n+3);
                }
                break;
            case PIP_ID_ERR:
                cs_exit(1);
                break;
            default:
                cs_log("unhandled pipe message %d (client %s)", pipeCmd, cl->account->usr);
                break;
        }
    
    // here is the oscam.c:3165 line
    if (ptr) free(ptr);
        return pipeCmd;
    }
    - 0x2c200468 Free 3624 was never alloc'd /home/mtrace/module-cccam.c:2762
    - 0x005271b8 Free 4595 was never alloc'd /home/mtrace/oscam-garbage.c:106
    - 0x2c2005a8 Free 5947 was never alloc'd /home/mtrace/oscam.c:3165
    - 0x2c201908 Free 5949 was never alloc'd /home/mtrace/oscam.c:3165
    - 0x2c200468 Free 6124 was never alloc'd /home/mtrace/oscam-garbage.c:106
    - 0x2c2004a0 Free 6128 was never alloc'd /home/mtrace/oscam-garbage.c:106
    - 0x2c200678 Free 6407 was never alloc'd /home/mtrace/module-cccam.c:626
    - 0x2c2004b8 Free 6422 was never alloc'd /home/mtrace/module-cccam.c:2353
    - 0x2c200548 Free 6494 was never alloc'd /home/mtrace/oscam-garbage.c:100
    - 0x2c200678 Free 6894 was never alloc'd /home/mtrace/module-cccam.c:626
    - 0x2c2006f8 Free 6895 was never alloc'd /home/mtrace/module-cccam.c:626
    - 0x00536ad8 Free 6897 was never alloc'd /home/mtrace/module-cccam.c:626
    - 0x2c200578 Free 6900 was never alloc'd /home/mtrace/module-cccam.c:1308
    - 0x2c2005f0 Free 6903 was never alloc'd /home/mtrace/module-cccam.c:1308
    - 0x00536da8 Free 6905 was never alloc'd /home/mtrace/module-cccam.c:626
    - 0x00536d20 Free 6906 was never alloc'd /home/mtrace/module-cccam.c:1308
    - 0x00536a60 Free 6908 was never alloc'd /home/mtrace/module-cccam.c:1308
    - 0x00536b58 Free 6918 was never alloc'd /home/mtrace/oscam.c:3165
    - 0x2c2004b8 Free 6923 was never alloc'd /home/mtrace/module-cccam.c:2353
    - 0x00535838 Free 6935 was never alloc'd /home/mtrace/module-cccam.c:2353
    - 0x00535810 Free 6943 was never alloc'd /home/mtrace/module-cccam.c:2353
    - 0x2c2004f0 Free 6953 was never alloc'd /home/mtrace/module-cccam.c:2353
    - 0x00535828 Free 7005 was never alloc'd /home/mtrace/oscam-garbage.c:100
    - 0x2c200668 Free 7007 was never alloc'd /home/mtrace/oscam-garbage.c:100
    - 0x00536d98 Free 7009 was never alloc'd /home/mtrace/oscam-garbage.c:100
    - 0x2c200548 Free 7017 was never alloc'd /home/mtrace/oscam-garbage.c:100
    - 0x00536a98 Free 9515 was never alloc'd /home/mtrace/oscam-reader.c:788
    - 0x00508610 Free 9516 was never alloc'd /home/mtrace/module-cccam.c:626
    - 0x005367d8 Free 9517 was never alloc'd /home/mtrace/module-cccam.c:1308
    - 0x00536c60 Free 9518 was never alloc'd /home/mtrace/oscam-reader.c:788
    - 0x00536e28 Free 9519 was never alloc'd /home/mtrace/oscam-reader.c:788
    - 0x005371b8 Free 9520 was never alloc'd /home/mtrace/oscam-reader.c:788
    - 0x00536ff0 Free 9521 was never alloc'd /home/mtrace/oscam-reader.c:788
    - 0x00537380 Free 9525 was never alloc'd /home/mtrace/oscam.c:3165
    - 0x2c201908 Free 9527 was never alloc'd /home/mtrace/oscam.c:3165
    - 0x2c201ad0 Free 9529 was never alloc'd /home/mtrace/oscam.c:3165
    - 0x00535a20 Free 9538 was never alloc'd /home/mtrace/module-cccam.c:2353
    - 0x00508600 Free 9618 was never alloc'd /home/mtrace/oscam-garbage.c:100
    - 0x2c200660 Free 9625 was never alloc'd /home/mtrace/oscam-garbage.c:106
    - 0x2c2004b8 Free 9629 was never alloc'd /home/mtrace/oscam-garbage.c:106
    - 0x2c201908 Free 9914 was never alloc'd /home/mtrace/oscam.c:3165
    - 0x2c201ad0 Free 9916 was never alloc'd /home/mtrace/oscam.c:3165
    - 0x2c2004f0 Free 10019 was never alloc'd /home/mtrace/oscam-garbage.c:106
    - 0x2c2005c0 Free 10033 was never alloc'd /home/mtrace/oscam-garbage.c:106
    + 0x0051bbe0 Alloc 13087 duplicate: /home/mtrace/oscam-simples.c:645 ./ttt:[0x40f796]
    .....
    .....
    - 0x00524c80 Free 26465 was never alloc'd /home/mtrace/oscam-garbage.c:106
    - 0x00524b48 Free 26467 was never alloc'd /home/mtrace/oscam-garbage.c:106
    - 0x00525528 Free 26469 was never alloc'd /home/mtrace/oscam-garbage.c:106
    - 0x00525468 Free 26471 was never alloc'd /home/mtrace/oscam-garbage.c:106
    - 0x00524ec0 Free 26509 was never alloc'd /home/mtrace/oscam-garbage.c:106
    - 0x00524d58 Free 26511 was never alloc'd /home/mtrace/oscam-garbage.c:106
    - 0x00524bf0 Free 26513 was never alloc'd /home/mtrace/oscam-garbage.c:106
    - 0x00525480 Free 26515 was never alloc'd /home/mtrace/oscam-garbage.c:106
    - 0x00524ed8 Free 26551 was never alloc'd /home/mtrace/oscam-garbage.c:106
    - 0x00529ea8 Free 26553 was never alloc'd /home/mtrace/oscam-garbage.c:106
    - 0x2c202c30 Free 30807 was never alloc'd /home/mtrace/module-cccam.c:626
    - 0x2c202610 Free 30808 was never alloc'd /home/mtrace/oscam-reader.c:788
    - 0x2c2029a0 Free 30809 was never alloc'd /home/mtrace/oscam-reader.c:788
    - 0x2c202f90 Free 30810 was never alloc'd /home/mtrace/module-cccam.c:626
    - 0x2c202ec8 Free 30811 was never alloc'd /home/mtrace/module-cccam.c:1308
    - 0x2c2027d8 Free 30812 was never alloc'd /home/mtrace/oscam-reader.c:788
    - 0x2c202b68 Free 30817 was never alloc'd /home/mtrace/module-cccam.c:1308
    - 0x2c202d00 Free 30820 was never alloc'd /home/mtrace/oscam.c:3165
    - 0x2c201908 Free 30836 was never alloc'd /home/mtrace/module-cccam.c:2187
    - 0x2c202088 Free 30854 was never alloc'd /home/mtrace/module-cccam.c:2353
    - 0x2c201cc8 Free 30920 was never alloc'd /home/mtrace/oscam-garbage.c:100
    - 0x2c201cd8 Free 30922 was never alloc'd /home/mtrace/oscam-garbage.c:100
    - 0x0051c2e0 Free 31085 was never alloc'd /home/mtrace/oscam-garbage.c:106
    ...
    ...
    - 0x2c202088 Free 35471 was never alloc'd /home/mtrace/oscam.c:3165
    - 0x2c201920 Free 35476 was never alloc'd /home/mtrace/module-cccam.c:2187
    - 0x2c201cf8 Free 35482 was never alloc'd /home/mtrace/module-cccam.c:2353
    - 0x00538be0 Free 35494 was never alloc'd /home/mtrace/module-cccam.c:2353
    - 0x2c201948 Free 35504 was never alloc'd /home/mtrace/module-cccam.c:2353
    - 0x2c201938 Free 35526 was never alloc'd /home/mtrace/oscam-garbage.c:100
    - 0x00527c88 Free 35528 was never alloc'd /home/mtrace/oscam-garbage.c:100
    - 0x2c201cc0 Free 35536 was never alloc'd /home/mtrace/oscam-garbage.c:100
    - 0x2c2019e8 Free 35538 was never alloc'd /home/mtrace/oscam-garbage.c:100
    - 0x2c201bb8 Free 38732 was never alloc'd /home/mtrace/module-cccam.c:1308
    - 0x2c2019a0 Free 38753 was never alloc'd /home/mtrace/module-cccam.c:2353

    Best Regards
    Last edited by jimycn; 10-21-2012 at 08:28 AM.

  8. #8
    Registered User
    Join Date
    Oct 2012
    Posts
    25
    @Salem

    Is there any way (with common debug tools) figure out , where this bad passing to garbage_collector occur? (which indicate which line cause it)

    ie Does adding a breakpoint with Gdb helps in this case , or i have to trace the code without any tools ?
    Last edited by jimycn; 10-21-2012 at 01:30 PM.

  9. #9
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,422
    > // here is the oscam.c:3165 line
    > if (ptr) free(ptr);
    Study what read_from_pipe() does.

    Checking for non-null is a poor test for a malloc'ed pointer.

    Besides, if it is NULL, then all of these lines might blown up as well.
    chk_dcw(cl, (ECM_REQUEST *)ptr);
    if (ptr[0]!='U')
    memcpy(&n, ptr+1, 2);
    memcpy(buf, ptr, n+3);


    If you suspect 'use after free' issues, then this is a good way to find them.
    Code:
    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>
    
    void baz ( ) {
        char *useAfterFree = malloc(20);
        free(useAfterFree);
        strcpy(useAfterFree,"oops");
    }
    
    int main ( ) {
        baz();
        return 0;
    }
    
    $ gcc -g bar.c -lefence
    $ gdb ./a.out 
    GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08
    Copyright (C) 2011 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "x86_64-linux-gnu".
    For bug reporting instructions, please see:
    <http://bugs.launchpad.net/gdb-linaro/>...
    Reading symbols from /home/sc/Documents/a.out...done.
    (gdb) run
    Starting program: /home/sc/Documents/a.out 
    [Thread debugging using libthread_db enabled]
    
      Electric Fence 2.1 Copyright (C) 1987-1998 Bruce Perens.
    
    Program received signal SIGSEGV, Segmentation fault.
    0x00000000004006ba in baz () at bar.c:16
    16	    strcpy(useAfterFree,"oops");
    (gdb) bt
    #0  0x00000000004006ba in baz () at bar.c:16
    #1  0x00000000004006d3 in main () at bar.c:24
    (gdb) quit
    A debugging session is active.
    
    	Inferior 1 [process 6027] will be killed.
    
    Quit anyway? (y or n) y
    The "Electric Fence" library is yet another malloc debug library, which will cause immediate segfaults if you do some kinds of dumb things with allocated memory (one being use after free).
    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.

  10. #10
    Registered User
    Join Date
    Oct 2012
    Posts
    25
    Hi guys , with some analysis tools , i got some error performance with this source code , but i don't know What it means (The problem)

    [module-cccam.c:3049] -> [module-cccam.c:3050]: (performance) Buffer 'buf' is being written before its old content has been used.
    [module-cccam.c:3054] -> [module-cccam.c:3057]: (performance) Buffer 'buf' is being written before its old content has been used.
    [module-cccam.c:3055] -> [module-cccam.c:3058]: (performance) Buffer 'pwd' is being written before its old content has been used.


    And here is related source codes :

    Code:
     
           uint8_t *buf = cc->send_buffer;
        char pwd[64];
    
    
    
    // this is line 3049 :
    memset(buf, 0, CC_MAXMSGSIZE);
        memcpy(buf, rdr->r_usr, strlen(rdr->r_usr));
        cs_ddump_mask(D_CLIENT, buf, 20, "cccam: username '%s':", buf);
        cc_cmd_send(cl, buf, 20, MSG_NO_HEADER); // send usr '0' padded -> 20 bytes
    
    // This line 3054 
        memset(buf, 0, CC_MAXMSGSIZE);
    
    // line 3055
        memset(pwd, 0, sizeof(pwd));
    
    
        memcpy(buf, "CCcam", 5);
        strncpy(pwd, rdr->r_pwd, sizeof(pwd) - 1);
        cc_crypt(&cc->block[ENCRYPT], (uint8_t *) pwd, strlen(pwd), ENCRYPT);
        cc_cmd_send(cl, buf, 6, MSG_NO_HEADER); // send 'CCcam' xor w/ pwd


    These codes are put from module-cccam.c , Funtion "cc_cli_connect" , this is link of module-cccam.c

    What's wrong with above code , which analysis tools complain about that performance problem? (would appreciate , to write your answer with programming language)

    Regards.
    Last edited by jimycn; 10-25-2012 at 05:02 AM.

  11. #11
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,422
    // This line 3054
    memset(buf, 0, CC_MAXMSGSIZE);

    // line 3055
    memset(pwd, 0, sizeof(pwd));

    memcpy(buf, "CCcam", 5);
    strncpy(pwd, rdr->r_pwd, sizeof(pwd) - 1);

    There is seldom any point is calling memset on a block of memory if the next thing you're going to do is write all over it with your actual data.

    Unless CC_MAXMSGSIZE is actually 5, then initialising buf with strcpy(buff,"CCcam"); would succeed in putting a C-style string there, complete with the trailing \0.
    Filling the whole buffer with \0 just to save copying one later doesn't help.

    You might care about zero-padding a buffer for security, then do something like memset(buff+6,0,CC_MAXMSGSIZE-6);

    Likewise, if you're always wanting a \0 at the end of a strncpy string, then do pwd[sizeof(pwd)-1] = '\0';
    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.

  12. #12
    Registered User
    Join Date
    Oct 2012
    Posts
    25
    @Salem
    Thanks for your great tips and Comments.

    Just for being sure , may i conclude from your last explanation , that in this case , i could safely remove those 3 memset?

    Regards

  13. #13
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,422
    Well that really depends.

    How reliant are you on the memset() to place a \0 somewhere in the buffer to make things a proper string?

    Like I said, if you NEED a \0 at the end of a string, then write a single \0 in the right place.

    For example,
    memcpy(buf, "CCcam", 5); // no \0, relies on memset to fill everything with zeros
    vs
    memcpy(buf, "CCcam", 6); // copies a single \0 automatically, and leaves the rest of the buffer uninitialised.
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Free allocated space
    By Fader_Berg in forum C Programming
    Replies: 1
    Last Post: 10-31-2010, 07:49 AM
  2. How to properly free a pointer and its allocated memory
    By yuzhangoscar in forum C Programming
    Replies: 2
    Last Post: 09-16-2008, 06:26 AM
  3. Can you free memory allocated by a std::string?
    By BrianK in forum C++ Programming
    Replies: 17
    Last Post: 05-15-2008, 11:57 AM
  4. Will free() clean up this allocated memory?
    By simguy in forum C Programming
    Replies: 3
    Last Post: 01-18-2007, 04:21 PM
  5. free allocated memory on interrupts
    By scrappy in forum C Programming
    Replies: 4
    Last Post: 02-20-2004, 10:13 AM

Tags for this Thread


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