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

[Mika Liljeberg <mika liljeberg welho com>]

Hi Jeff,

You'll note that EMsgPort has its own .lock member, 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. 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. 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