Haxx ad

curl's project page on


cURL > Mailing List > Monthly Index > Single Mail

curl-tracker mailing list Archives

[ curl-Bugs-1999181 ] CLOCK_MONOTONIC always fails on some systems

From: <>
Date: Sat, 21 Jun 2008 01:18:42 +0000

Bugs item #1999181, was opened at 2008-06-20 22:29
Message generated for change (Comment added) made by yangtse
You can respond by visiting:

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: compile or build problem
Group: wrong behaviour
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Lightsey (jlightsey)
Assigned to: Daniel Stenberg (bagder)
Summary: CLOCK_MONOTONIC always fails on some systems

Initial Comment:
I've seen several Centos 3 i386 systems with this particular problem.

clock_gettime(CLOCK_MONOTONIC) compiles and links correctly, but at runtime it will always fail and return -1. This causes curl to timeout before opening a socket when creating a https connection.

verbose output:
root@centos3edge [~]# /opt/curlssl/bin/curl -G -v
* About to connect() to port 443 (#0)
* Connection time-out
* Closing connection #0
curl: (28) Connection time-out

The attached patch checks for broken CLOCK_MONOTONIC support at configure time so that curl will fallback on gettimeofday() on these systems.


Comment By: Yang Tse (yangtse)
Date: 2008-06-21 01:18

Logged In: YES
Originator: NO

My point of view...

Linking of libcurl using function clock_gettime() is only possible if the
system libraries actually provide an implementation of the clock_gettime(),
otherwise linking would fail and curl would not build.

Compilation of libcurl using function clock_gettime() and clock_id
CLOCK_MONOTONIC is only possible if the system header files provide both a
prototype for function clock_gettime() and the clock_id definition for
CLOCK_MONOTONIC, otherwise compilation would fail.

Both checks mentioned above are done at libcurl configuration time, and if
any of them fail libcurl will be configured to not use the clock_gettime()
function, and simply use gettimeofday().

If a system provides bogus information in its system header files relative
to the actual capabilities of its libraries implementation it is a system
library or system header file issue. No application will be capable of
building properly using that system. The OS provider can fix the header
files or fix the system library implementation. Or not fix it and expect
the rest of the world to workaround the system bugs.

It could also be possible that there is no problem on the OS provided
system header files and the OS provided system libraries. But it could
happen that someone could have 'ugraded' the system header files without
'upgrading' the system libraries creating and unexpected problem for any
application that is built on that 'unbalanced' system.

The IEEE and The Open Group [1] are very clear at this point. The
clock_gettime() function shall fail if the clock_id argument does not
specify a known clock.

From what you are describing the system header files do define a clock_id
for CLOCK_MONOTONIC, that implies that the system headers _know_ the
CLOCK_MONOTONIC clock, but later on the system libraries do not _know_ it
and fail at runtime.

Could you verify/discard if its just an accidental mismatch between system
libraries and header files ?

If not, then, could you provide further information on which system
library version and provider has the problem ? And if it has already been
fixed in a further version ? Or a pointer to the bug/fix record ?



You can respond by visiting:
Received on 2008-06-21

These mail archives are generated by hypermail.

donate! Page updated November 12, 2010.
web site info

File upload with ASP.NET