Re: [Valgrind-developers] lazy eflags seems to work now

[Jeremy F. <je...@go...>]

On Fri, 2002-12-06 at 12:12, Julian Seward wrote:

> > Anyway, tell me what you get with the current versions of 61 and 62.
> 
> No improvement with OO.
> 
> I tried mozilla. It also won't start up, the simulated machine falling 
> into an endless sequence of poll() calls seperated by nanosleep(13 
> milliseconds), which afaics is the nonblocking poll() in vg_libpthread.c.
> 
> Trying OO with tracing on indicates it spins in the same place.  
> 
> Hmm.  This is very odd.  I'm wondering if there is some problem with the
> non-D flags (OSZACP) causing "if (res > 0) {" at line 2636 never to
> get into the then-clause.  Except that if there was such a problem,
> most programs wouldn't work (I'd guess).

I think that's a red herring.  In OO's case, thread 3 is polling on IO
(I presume to the X server), thread 2 is blocked in a condvar_wait, and
thread 1 is spinning CPU-bound.  I'm guessing that thread 2 is waiting
for either thread 1 or 3 to do something, and thread 1 is expected to do
something but isn't.

However, if I use "--trace-codegen=10001 --trace-signals=yes" and pipe
that into a "tail -100000" (my disk not being big enough to fit a
complete codegen trace) and then wait for it to stabilize (stop codegen
for new BBs, observed by looking at strace of the process), then it
tends to actually work.  So that's no use.

Mozilla is similar.  Sometimes it works, and sometimes it doesn't. 
Sometimes it works, but takes a really long time.  In particular, it
normally takes 30 user CPU seconds for moz to appear on my laptop with
--skin=none.  Sometimes it never appears, and just seems to burn CPU. 
Other times, it appears after 60 or more (wall-clock seconds), but after
still only using 30 CPU seconds (with nothing else using the CPU).

If you try just 61, do you see the same problem?

It does seem very fragile.  I just added another patch to V, which
should be completely benign, but it changes the behaviour.

        J