This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: trying to understand what's going on with timers and boot process
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: "Mark Seger" <Mark dot Seger at hp dot com>
- Cc: libc-help at sourceware dot org
- Date: Sun, 6 Jul 2008 12:23:45 -0400
- Subject: Re: trying to understand what's going on with timers and boot process
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=1khPk8QJ63jZlF4f06SSNM2HprTWo4B/73zRZNeTmoo=; b=slYUfia5oyLyVClRs0kwpxWRyJmXcFfH1Ko4p7oq5/C6aQ5Xb/bAd1LGcIyLt3KMtF o7GPFz1mGu5X1GX+T/xJ38Cjt5UBa9yU2b3TfZUnO9khFtgjwPDdQ0eGYpqdxo9OL3sp x0ZNe7F3nd4GNQ8mOwCoIFYn2d2J2mORhGlEU=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=oKUENsrEzK+O+EERX7XXDal6G2OzpP9mNhZqravJxQapuuKz5lcqPfWnAcWrC6e6u2 VdTZq4lxMJRZ64dfFuBmkzMNcbGhcpsAh1QvYCn4m+ZZsxQSDOsJiJaVfe9ZwBId415c QRWYAzy/ws4KDjOdFsCPuQprR1s/A8ZNhv02o=
- References: <486A2C72.9080903@hp.com> <119aab440807010726g1999b5e5p9dd583728a5df181@mail.gmail.com> <486A424D.3050508@hp.com>
On Tue, Jul 1, 2008 at 10:42 AM, Mark Seger <Mark.Seger@hp.com> wrote:
> Does that help?
The setitimer call in glibc is an assembly wrapper to the kernel
syscall. On x86 there is no logic in userspace, it's handled
completely by the kernel.
The glibc wrapper might have some argument setup code, but nothing
more. Disassemble setitimer from a debug version of libc.so.6 to see
the wrapper.
A recent kernel implementation of sys_setitimer calls do_setitimer
which uses the following check (((unsigned long) (t)->tv_usec) <
USEC_PER_SEC) to invalidate large usec values and return EINVAL.
In summary, it would appear that if a user upgrades their kernel, the
buggy Time:HiRes perl module must surely break.
Does that help? :-)
In the future *please* produce a test-case that shows the problem,
even if it is a buggy call to a libc routine.
1. Expected behaviour
2. Observed behaviour
3. Reproducible test-case.
e.g.
Expected behaviour:
- Call to setitimer fails.
Observed behaviour:
- Invalid call to setitimer works in glibc 2.3 and 2.5, but sometimes
fails in 2.5.
Test-case
.... Code showing invalid call to setitimer.
Cheers,
Calros.