Re: [Evolution] Re: [Evolution-hackers] SIGSEGV on setting label - gdb output and analysis
- From: Not Zed <notzed ximian com>
- To: Mika Liljeberg <mika liljeberg welho com>
- Cc: Jeffrey Stedfast <fejj ximian com>, evolution-hackers ximian com, evolution ximian com
- Subject: Re: [Evolution] Re: [Evolution-hackers] SIGSEGV on setting label - gdb output and analysis
- Date: 06 Jan 2003 10:53:43 +1030
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
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
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.
] [Thread Prev