Re: [Valgrind-developers] aspace mgr woes

[Julian S. <js...@ac...>]

On 02/02/15 19:16, Florian Krohm wrote:
> Consider this snippet from m_addrinfo.c:
> 
> const NSegment *seg = VG_(am_find_nsegment) (a);
> ...
> if (seg->kind == SkFileC)
>    ai->Addr.SegmentKind.filename
>       = VG_(strdup)("mc.da.skfname", VG_(am_get_filename)(seg));
> ai->Addr.SegmentKind.hasR = seg->hasR;
> ai->Addr.SegmentKind.hasW = seg->hasW;
> ai->Addr.SegmentKind.hasX = seg->hasX;

The basic problem is that any dynamic memory allocation potentially
invalidates any NSegment* that you might have.  I don't know how we
can mechanically (compile time, or run-time assertions etc) avoid that.

> I'm currently thinking of adding
>    NSegment *sorted_nsegments[VG_N_SEGMENTS]
> as a fix. Basically, introducing another level of indirection.

Can you say how that would help?

In this case -- considering that we are trying to describe a file segment
that belongs to the client (a SkFileC) it can't be the case that calling
VG_(malloc) makes the segment become invalid, because at worst, dynamic
memory allocation will cause expansion or merging of anonymous segments
that belong to V (SkAnonV's).  So we're OK.  But I agree, it's pretty
fragile.  Maybe we should split NSegment* into two different types, one for
client segments, one for V segments?  Or something like that?

J