Re: strange problem in libc: free invalid pointer, but valgrind doesn't show it.

[Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>]

Hi,


On 12-08-2014 06:18, Linda A. Walsh wrote:
> I'm getting a glibc dump soon after startup...(~3-4 seconds)....
> It seems repeatable in normal execution, but not under valgrind -- which
> makes me think the problem might be in the glibc memory management,
> or the C++ routines that call them.

I really doubt the problem relies either in glibc or C++ routines.  GLIBC malloc
implementation is quite battle-proven and has not been changed for some time.  C++
new/delete for G++ are just wrappers for underlying C malloc routines.


>
>
>
> ----
> Stack entry #6 points at line 295
>
>  278 void val_array_status(const char* name, valarray<uint64_t>&vaa) {
>  279   printf("%s_sz=%d, vals=",name, vaa.size());
>  280   for(auto &vamem:vaa) printf("%ld,");
>  281   printf("\n");
>  282 }

This seems *very* suspicious: printf is being called with no argument, but it is expecting
one ("%ld").  What happens if you omit this printf or actually adds an argument?

Also, I'm not an expert in C++11, but usually best way to use it is with
iterators if type 'valarray' provides one (I am only guessing here, since I don't know
what exactly is vamem::vaa type).

> ...
>  291   shift_samples();
>  292   val_array_status("fields", fields_);
>  293   col_samp_dat = fields_;
>  294   val_array_status("col_samp_dat", col_samp_dat);
>  295   samples[0].D        = fields_;
>  296   val_array_status("samples[0].D", samples[0].D);
> ---
>
> Output (repeated from above before the glib dump):
> FMG:rfrsh:sc(0)<W(696);sw={0/1;1},s/c={0/1;1}
> fields_sz=3, vals=2147483636,2147483637,2147483637,
> col_samp_dat_sz=3, vals=2147483630,2147483637,2147483637,
>
>
>
> So it prints fields_, col_samp_dat, but dies on line 295 in the
> assignment to samples.
>
> At the point of 'death', it looks like glib is printing out a guard string,
> but it is in free() and I'm doing assignments (those appear to be
> valid numbers for numbers of ethernet bytes on a specific interface.
>
> ----
>
> kernel=Linux Ishtar 3.15.8-Isht-Van #1 SMP PREEMPT Sat Aug 2 01:04:05 PDT 2014 x86_64 x86_64 x86_64 GNU/Linux
> glib rpm:
> glibc-2.18-4.4.1.x86_64
> C++
> gcc-c++-4.8-2.1.2.x86_64
>
> -----
>
> So any idea *why* it doesn't crash under valgrind and valgrind
> finds no signs of memory corruption?

Valgrind overrides program malloc/free and a bunch or string operations with its own.  However,
I can't really say what is happening without a real testcase that stresses this issue.  It would
be really helpful if you could provide a minimum testcase that mimics your program behavior
and trigger this issue.

>
> maybe the stack guard?  Though I'd be afraid to turn it off, since
> if it is a real bug and that hides it... that would be bad.
>
> ... double posting this to the G++ lib list as well... hope that
> doesn't violate any protocols...but at this point, I'm not sure
> where the problem is -- glib's alloc, or the c++ libs that call it,
> or somehow in my program safely hidden so valgrind doesn't find it.  ;-(
>
> FWIW, vg summary:
>
> ==38919== LEAK SUMMARY:
> ==38919==    definitely lost: 0 bytes in 0 blocks
> ==38919==    indirectly lost: 0 bytes in 0 blocks
> ==38919==      possibly lost: 131 bytes in 4 blocks
> ==38919==    still reachable: 475,759 bytes in 979 blocks
> ==38919==         suppressed: 0 bytes in 0 blocks
> ==38919== Reachable blocks (those to which a pointer was found) are not shown.
> ==38919== To see them, rerun with: --leak-check=full --show-reachable=yes
> ==38919==
> ==38919== For counts of detected and suppressed errors, rerun with: -v
> ==38919== ERROR SUMMARY: 8 errors from 8 contexts (suppressed: 2 from 2)
>
> (full report available if wanted).
>
> Ideas?
>
>
>
>
>
>
>