On Mon, 2016-02-22 at 13:26 -0500, Jim wrote:
> I'd appreciate any input on helping me track this error down. Is this
> a problem with valgrind, or with my program? Please let me know if
> there's more information I should post.
Can you do the following 4 trials and attach the resulting logs
to the bug 349128, which maybe/probably is the best matching bug ?
When looking at the log of your program, I am not very sure
that the 'initial problem' is linked to the leak search.
The bug 353891 fixed in revision 15716 had the following symptoms:
program running normally, no SEGV encountered
leak search starting
SEGV during leak search due to heuristic dereferences not protected
assert failing as there was no specific handler for heuristic dereferences
While in your case, we first see a SEGV,
followed by a leak search which then causes a similar assert.
So, I suspect what you see is a 'client' SEGV, causing a termination
of the program. This termination implies a leak search, and during
the leak search, we encounter a 'second bug', which is in any case
unexpected, as revision 15716 is supposed to have fixed all that :(.
The initial SEGV is maybe the indication of something strange
happening during thread termination, causing after
the SEGV and/or leak search problem. See helgrind/tests/stackteardown.c
for a somewhat strange way in which android terminates a thread.
Maybe something similar happens on MacOS and/or with MPI.
E.g. maybe MPI uses shared memory in a special way ?
With the below 4 trials, we might have a better idea of the bug origin.
Thanks
Philippe
Trials to do:
1. run with --leak-check-heuristics=none
If the problem is fixed, then do:
for h in stdstring length64 newarray multipleinheritance
do
run with --leak-check-heuristics=$h
done
to find which heuristic causes the problem.
2. run with --leak-check=no
do we still see a SEGV ?
3. run with more tracing i.e. with
-v -v -v -d -d -d --vgdb-stop-at=valgrindabexit
valgrind should stop and wait for vgdb when encountering the assert.
Then in another shell window, do
vgdb v.info memory aspacemgr
Valgrind will produce the memory mapping.
We can then see if the address causing the SEGV is somewhat special
(e.g. what is the segment of this address ? Was this a thread stack ?
...)
4. Would it be possible to translate the below host addresses in
sourcefile + linenr ?
On linux, the host stacktrace is symbolic. No idea why on MacOS it is
not the case. I guess MacOS has a tool that can translate these
addresses, which are in the memcheck executable so something like
memcheck-amd64-darwin.
(or I suppose gdb will be able to translate these addresses)
> Memcheck: mc_leakcheck.c:1106 (void lc_scan_memory(Addr, SizeT, Bool,
> Int, Int, Addr, SizeT)): Assertion 'bad_scanned_addr >=
> VG_ROUNDUP(start, sizeof(Addr))' failed.
>
> host stacktrace:
> ==59226== at 0x23804F24E: ???
> ==59226== by 0x23804F66C: ???
> ==59226== by 0x23804F64A: ???
> ==59226== by 0x238003953: ???
> ==59226== by 0x238003135: ???
> ==59226== by 0x238001D17: ???
> ==59226== by 0x23801482D: ???
> ==59226== by 0x23805C0F2: ???
> ==59226== by 0x2380EE752: ???
The best is to attach all the produced output/log files to the bug
349128.
Thanks
Philippe
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
