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

[Not Zed <notzed ximian com>]

On Mon, 2003-01-06 at 05:45, Mika Liljeberg wrote:
> On Sun, 2003-01-05 at 20:30, Jeffrey Stedfast wrote:
> > 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.
>
> Ok, I see what you mean. Only the server's EThread handle is known to
> clients.

Yeah, that code is a bit dodgey, it breaks through some abstraction
layers, but its all part of the same code really, so ...

But server_port is just another member of EThread, so it is accessed via
a lock (even in thread_dispatch the lock is always held if the port is
to be modified).

The reason the code is there isn't very worthwhile anyway, there isn't
any reason you'd want to drop any messages, so it could probabhly be
removed.

> > if you can find evidence to the contrary, please point it out.
>
> Well, e_thread_destroy() empties the server_port message queue without
> acquiring EThread.lock. Conceivably there could be a race there. I
> sincerily hope it's not "just" random memory corruption. ;-)

Memory bugs are sometimes hard to find ... :-/

e_thread_destroy doesn't need to lock because if anything still has a
handle to the ethread at the time it is destroyed, its already a bug.