Re: [Evolution-hackers] valgrind in gnome 2.5/6

[Not Zed <notzed ximian com>]

On Fri, 2004-03-26 at 09:12 +0000, Michael Meeks wrote:
> On Fri, 2004-03-26 at 09:42 +0800, Not Zed wrote:
> > Yeah i dunno either.  Maybe trylock isn't implemented in valgrind's
> > 'hacked pthread lib' (as it calls itself).
> 
> 	Most odd.
> 
> > FWIW with this disabled, certain things simply don't work running in
> > valgrind.  Although they could point to code bugs.  When you try to do
> > autocompletion, it always complains that its getting stuff out of
> > sequence.  i.e. i think it gets responses before the call returns.
> > (which is definetely a code bug if thats what happens - this is in
> > eds/evo code though).
> 
> 	What complaints do we get ? I'd be very suprised if incoming async
> replies were happening before the outgoing async method had completed;
> but - I suppose it might be possible in some scenarios - if you have a

I looked into the code, and I couldn't see anything obvious.  The only
way it made sense is if: either the memory space wasn't as shared as it
should be, or if memory was staying in registers instead of being
written.  Given the code in the mailer is much the same as what I was
looking at, it totally makes no sense.  I generally build with -O0
anyway, so every memory write goes to memory anyway.

It happens when you try and complete an address in the composer whilst
running under valgrind.

> thread-per-request, or thread-per-connection type policy, then clearly
> the kernel could task the async caller out indefinately, while the other
> side proccessed / replied, and then task in the thread that handles
> incoming stuff, before the outgoing thread completed - that's rather
> unavoidable.

Well the code sets up the data in question, in another function, before
it calls the orbit method.  No idea, valgrind issues or something i'm
just not seeing, I guess.

Looks like Chris might've tracked down the root cuase of the issue
anyway, so it can all pass into history.

 Z