Regarding Possible Lost in Valgrind

Question

What is wrong if we push the strings into vector like this:

globalstructures->schema.columnnames.push_back("id");

When i am applied valgrind on my code it is showing

possibly lost of 27 bytes in 1 blocks are possibly lost in loss record 7 of 19.

like that in so many places it is showing possibly lost.....because of this the allocations and frees are not matching....which is resulting in some strange error like

malloc.c:No such file or directory

Although I am using calloc for allocation of memory everywhere in my code i am getting warnings like

Syscall param write(buf) points to uninitialised byte(s)

The code causing that error is

  datapage *dataPage=(datapage *)calloc(1,PAGE_SIZE);               
  writePage(dataPage,dataPageNumber); 
             
                     
  int writePage(void *buffer,long pagenumber)                 
  {
    int fd;
    fd=open(path,O_WRONLY, 0644);

     if (fd < 0)
        return -1;

    lseek(fd,pagenumber*PAGE_SIZE,SEEK_SET);

     if(write(fd,buffer,PAGE_SIZE)==-1)
    return false;


      close(fd);
      return true;
  }

Exact error which i am getting when i am running through gdb is ...

Breakpoint 1, getInfoFromSysColumns (tid=3, numColumns=@0x7fffffffdf24: 1, typesVector=..., constraintsVector=..., lengthsVector=..., columnNamesVector=..., offsetsVector=...) at dbheader.cpp:1080

Program received signal SIGSEGV, Segmentation fault.

_int_malloc (av=0x7ffff78bd720, bytes=8) at malloc.c:3498 3498 malloc.c: No such file or directory.

When i run the same through valgrind it's working fine...

if `shema.columnnames` is an `std::vector` then there's nothing wrong with the push_back. — juanchopanza, Nov 22 '12 at 18:31
@juanchopanza: valgrind sometimes has issues with implementation memory pooling schemes (I see that with GCC sometimes), but with given info impossible to tell if that's the issue here. — Benjamin Bannier, Nov 22 '12 at 18:33
@honk sure, "possibly lost" is usually a false positive due to some custom memory management. But pushing a `const char*` into a vector is safe. — juanchopanza, Nov 22 '12 at 18:42
Regarding **calloc** when i am using malloc...i am getting some garbage values...instead of again applying memset....i had used the calloc...Is there any performance issues... — Rohit, Nov 22 '12 at 18:43
@nos I had edited the reason for the error **Syscall param write(buf) points to uninitialised byte(s)**...i think this is a warning by valgrid....although i am using calloc, i am unable to found why it is showing that error — Rohit, Nov 22 '12 at 19:58
I doubt you `write()` an empty buffer. Therefore please note, that Valgrind recognizes, if you copy uninitialised data in to a buffer (and herewith initialize the buffer) and then access this buffer, as "indirectly" accessing uninitialise memory. The drawback is, that Valgrind does not log "indirect" in such a case, but simply "uninitialised". — alk, Nov 22 '12 at 20:05
To cut my last comment short: If you initialise a buffer A with the content of an uninitialised buffer B, then write out buffer A, Valgrind will log the access to buffer A as access to uninitialised memory. — alk, Nov 22 '12 at 20:13
@alk I had defined & initialized the dataPage buffer with the help of calloc...and i am passing that to the writePage function....i.e initialized buffer starting address is passed....so there is no where uninitialized buffer is used....Is there any wrong in my code there — Rohit, Nov 22 '12 at 20:23
Hm, perhaps `calloc()` returned `NULL`? Or the code might have smashed the memory management way before this call. — alk, Nov 22 '12 at 20:29
@alk No it's not returning NULL,i am writing content also it is working....the code is executing fine after this execution also.....The Code is working fine with valgrind with some warnings as above...but with gdb it is showing as malloc.c: No such file or directory — Rohit, Nov 22 '12 at 20:38
The best would be to go for *nos*'s advice. Addtionally check **all** allocations, freeings and all operations on pointers involved to the latter. Even way before the logged errors and/or SEGV locations. As the segmentation violation might due to something that went wrong way before, but had not had any directly visible effect. — alk, Nov 22 '12 at 20:51
If got you right you get a SEGV when calling `malloc()`. This is **very strong hint** that memory management had already been corrupted **before** the call to `malloc()` that failed. Even if the app runs fine under Valgrind, the fact it *only" crashed under `gbd` clearly indicates that something is awfully wrong (mostly likley in the memory handling of the code). — alk, Nov 22 '12 at 20:53

score 3 · Accepted Answer · answered Nov 23 '12 at 11:12

Well,

malloc.c:No such file or directory

can occur while you are debugging using gdb and you use command "s" instead of "n" near malloc which essentially means you are trying to step into malloc, the source of which may not be not available on your Linux machine.

That is perhaps the same reason why it is working fine with valgrind.

score 0 · Answer 2 · edited May 23 '17 at 11:48

Why error is in malloc:

The problem is that you overwrote some memory buffer and corrupted one of the structures used by the memory manager. (c)

Try to run valgrind with --track-origins=yes and see where that uninitialized access comes from. If you believe that it should be initialized and it is not, maybe the data came from a bad pointer, valgrind will show you where exactly the values were created. Probably those uninitialized values overwrote your buffer, including memory manager special bytes.

Also, review all valgrind warnings before the crash.

Regarding Possible Lost in Valgrind

2 Answers2