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?