Re: [Valgrind-users] Segfault, Assertion 'bad_scanned_addr >= VG_ROUNDUP (MPI / pthread program)

[Philippe W. <phi...@sk...>]

On Mon, 2016-02-22 at 22:16 -0500, Jim wrote:

> 2. run with --leak-check=no
>   do we still see a SEGV ?
> 
>   Yes, problem still persists. Still a SEGV with the same error stack
> track from memcheck.
So, this indicates that what you see is not related to the bug 353891
which was solved with revision 15716 : this bug could only be
triggered when doing a leak search.

Is the SEGV also produced when using other tools ?
(e.g.  --tool=none ? --tool=lackey ? --tool=helgrind ?
 --tool=callgrind ?)


> 
> 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 ?
>   ...)
> 
> ==> this didn't work for me; ended with an error instead of waiting.
> see attached file for the full output.
vgdb is supposed to work on MacOs but last time I tested was something
like 4 years ago so status is unknown :(.

Nevertheless, the trace has given the aspacemgr mapping.

The log only contains the valgrind trace, not the 'normal output'.
But assuming the same address causes the SEGV (0x7000036B2C1C),
then this is really strange: this address is inside the segment:
--68920:1: aspacem 203: ANON 7000035bc000-7000036bbfff 1048576 rwx--
which is the valgrind stack of the thread tid 6 ???

The trace shows other not understandable entries such as:
--68920:2: stacks   no addressable segment for SP 0x70000373EF80

So, it looks like at thread startup time or very quickly after
thread startup, we have a SP which is outside any segment
as maintained by valgrind aspacemgr.
This is all very strange/not understandable.

Maybe you could try to increase the valgrind stack size, just
to experiment. Try e.g. with--valgrind-stacksize=8388608.
If you can control the user thread stacksize, maybe also try
to increase it.
   
At this stage, I have not much idea, and without a reproducer
on linux, not much chance to to find the problem with
mail remote debugging :(.

Philippe