[darcs-users] [darcs-devel] buildbot failure in darcs on karel opensolaris OpenSolaris-2008.05 nevada-86-rc3 i386

[Karel Gardas]

zooko wrote:
>> Anyway, if you like to test anything on this broken "box", just let me
>> know and I'll test it for you
> 
> Thank you!  I do care about the issue of programs depending on a
> monotonically increasing gettimeofday when they do not need to.  In my
> opinion it is one of those "insidious" issues that causes a problem so
> rarely that most people think it is okay.
> 
> Looking around, I see that libcurl very recently started detecting and
> using CLOCK_MONOTONIC:
> 
> http://article.gmane.org/gmane.comp.web.curl.cvs/9220
> 
> If you want to test darcs with a very recent libcurl, then I would be
> happy to gain confidence that darcs (and other libcurl-using programs)
> are not going to mysteriously hang if they hit the rare case that
> gettimeofday is not monotonically increasing.
> 

Interesting, I hope to give it a try later this week.

> 
> Hm.  Except I just realized that I do not understand what happened on
> your system:
> 
>> Interesting, so I used Solaris's pstack tool to print the stack of the
>> running process.
> 
> What a cool tool.  I wish linux had that.

http://www.google.cz/search?q=pstack+for+linux -- but I've not tested
this lsstack at all.

> 
>> It was quite strange to see all the threads ending on
>> something which should block and wait and see. So I executed pstack
>> several times and then seen that one thread is executing some call from
>> curl and that the threads' top stack item is gettimeofday call.
> 
> Does this mean that libcurl is in a fast polling loop, calling
> gettimeofday() over and over and using up CPU?

I think this is probably the case.

> Or that it is blocked in a system call that has not returned?

In this case I will see curl somewhere in the stack all the time, but
this is not the case. Pity I don't know DTrace enough to proof this by
counting getimeofday entries/exits... but I'll think about it.

Cheers,
Karel