[Evolution] Re: [Evolution-hackers] SIGSEGV on setting label - gdb output and analysis

[Jeffrey Stedfast <fejj ximian com>]

On Sun, 2003-01-05 at 13:22, Mika Liljeberg wrote:
> Hi Jeff,
>
> You'll note that EMsgPort has its own .lock member

yes, I know :-)

> , which is acquired by
> e_msgport_put(), e_msgport_get(), e_msgport_wait() and all other
> routines before accessing or modifying the message port data.

yea... 

>  To me this
> a pretty strong indication that this is a mailbox that is accessed by
> multiple threads. Looks like a pretty standard client-server pattern,
> where the server thread is sitting on top of a mailbox and dispatching
> service requests from client threads.
>
> I think EThread.lock is there just to protect the EThread member
> variables.

of which, server_port is one of them ;-)

What I'm saying is that EThread.server_port's queue is not modified
outside of a EThread.mutex and so it is all safe. If that wasn't the
case, I would agree with you - then there would be a poblem, but as far
as I can tell, EThread.mutex is always in a locked state when
EThread.serverport.queue is modified in any way.

if you can find evidence to the contrary, please point it out.

Jeff

>  I don't know the code very well, so I could be completely off
> the base, though.
>
> Cheers,
>
>       MikaL
>
>
> On Sun, 2003-01-05 at 20:03, Jeffrey Stedfast wrote:
> > > As you can see, there are two calls to e_dlist_length() to find out the
> > > message queue length without locking it first. e_dlist_length() iterates
> > > the whole message queue, which might be modified simultaneously by
> > > another thread.
> >
> > except that it can't be modified by another thread because a few lines
> > above the code you pasted, there is a:
> >
> > pthread_mutex_lock (&e->mutex);
> >
> > Note that (assuming I am reading the code correctly, anyway) the EThread
> > (e) *owns* the EMsgPort (e->server_port). This means that so long as we
> > don't access the EThread's EMsgPort directly (which we can't, note that
> > EThread is a private structure) or without first locking e->mutex, there
> > can be no "thread locking problems".
> >
> > Simply put: so long as e->mutex is locked, accessing
> > e->server_port->queue is safe. There is no need to lock
> > e->server_port->lock.
> >
> > So, this means that the only way problems could arise is if we modify
> > e->server_port->queue outside of a e->mutex lock. I scanned the code and
> > could not find evidence that this could occur.
> >
> > I think that the corruption to this list may be more likely to just be
> > random memory corruption than a bug in the e-msgport.c code, but I'll
> > wait to see what Michael Zucchi says (he's the one that wrote this
> > code).
> >
> > Jeff
>
> _______________________________________________
> evolution-hackers maillist  -  evolution-hackers ximian com
> http://lists.ximian.com/mailman/listinfo/evolution-hackers
-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fejj ximian com  - www.ximian.com