This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Adhemerval Zanella wrote:
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?
----
Oops... already worked around the problem.

you are right, I forgot the arg in my debug routine... sigh.

But the important thing it printed out was the fact that it was 0 before the assign and 3 after. Teh way the prog is constructed, it shouldn't have been 0 by that statement, so I figured, if I fixed that it would likely work....or at least no more core dump... As for whether or not the assignment is supposed to be handled (I thought it was) I don't know, but as mentioned, it didn't crash in valgrind, and gave sane enough output that I could do a workaround... but I don't know the language well enough to state with any certainty that the assignment should have worked (though it did under vg)...

But just w/glib, I'm fairly certain that a size of samples[0].D_sz=-1162167622
is pretty unlikely... <ice-cube chance in hell...

but now that the thing is working those debug routines aren't being called now. (they were just added to debug this problem -- so they weren't the source of the prob...
not sure what that was)....

Thanks for catching that...why do I do so many nights w/no sleep!... ARG...

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?










Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]