On Tue, Aug 08, 2006 at 06:14:17PM +0200, Mohammed Adnène Trojette <[EMAIL
PROTECTED]> was heard to say:
> On Tue, Aug 08, 2006, Julien Danjou wrote:
> > > (3) If it's reproducible, can you trace through the code and see where
> > > it fails? In particular, what value is being returned from
> > > pthread_cond_timedwait?
> >
> > I can, but I'd need a little help, I'm not a C++ guru.
>
> It is reproducible on Julien's Xen machine, with this debug output:
Ick, I didn't realize this was a virtual machine.
> | ......................
> | rval == -1080447064
> |
> | now2.tv_sec == 1155053066
> | now.tv_sec + 2 == 1155053066
> | now2.tv_usec == 882203
> | now.tv_usec == 887661
> | F.............
Hm. I'm inclined to close this as a bug in xen --
pthread_cond_timedwait should never ever return success if it hasn't
waited long enough, which is what appears to be happening. [0] Does xen
play games with the system clock?
Daniel
[0] Specifically, the only allowed error codes are ETIMEDOUT
(indicating that we ran out of time) and EINTR; aptitude
continues waiting until it receives something other than
EINTR and assumes that if it didn't get EINTR, the wait
succeeded. (now that I look at it again, this could be
more defensively coded, but it should be correct anyway)
