Re: [BUG] segfault in perf-top -- thread refcnt

[Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>]

Em Mon, Mar 30, 2015 at 02:56:31PM +0200, Jiri Olsa escreveu:
> On Mon, Mar 30, 2015 at 09:48:52PM +0900, Namhyung Kim wrote:
> > Hi Jiri,
> > 
> > On Mon, Mar 30, 2015 at 01:49:07PM +0200, Jiri Olsa wrote:
> > > On Mon, Mar 30, 2015 at 01:21:08PM +0200, Jiri Olsa wrote:
> > > > On Mon, Mar 30, 2015 at 12:22:20PM +0200, Jiri Olsa wrote:
> > > > > On Mon, Mar 30, 2015 at 10:07:37AM +0200, Jiri Olsa wrote:
> > > -	th = thread__new(pid, tid);
> > > +	th = thread__new(machine, pid, tid);
> > >  	if (th != NULL) {
> > > +
> > > +		pthread_mutex_lock(&machine->threads_lock);
> > >  		rb_link_node(&th->rb_node, parent, p);
> > >  		rb_insert_color(&th->rb_node, &machine->threads);
> > > +		pthread_mutex_unlock(&machine->threads_lock);
> > 
> > I think you also need to protect the rb tree traversal above.
> 
> yep, I already have another version.. but it blows on another place ;-)

Well, why? The point of refcounting is that the structure will not go
away while we have it in the rbtree.

Or are you talking about two threads trying to insert entries in the
rbtree? Can you point where this can happen?
 
> > But this makes every sample processing grabs and releases the lock so
> > might cause high overhead.  It can be a problem if such processing is
> > done parallelly like my multi-thread work. :-/
 
> yep.. perhaps instead of more locking we need to find a way where
> only single thread do the update on hists/threads

But that should be really rare, no? The problem is to search in one
thread (the fast path) and inserting entries (slow path), no?

- Arnaldo