julien.boibessot at free.fr
Sun Jan 31 19:33:39 UTC 2010
after a big bug hunt we also found that the implementation of the
"times" system call in uClibc 0.9.29/0.9.30 is problematic on some 32
bits architectures (arm926 in our case); like it was reported 2 years
ago by Will.
The fact that uClibc considers some Linux sys_times() return values as
errors makes some user space applications become crazy (Qt in our case):
when Linux "times" syscall's return value is inside uClibc errors range
(cf INTERNAL_SYSCALL_ERROR_P macro), uClibc forward a (-1) error code to
caller. An application may freeze during many seconds (40 if system tick
is 10ms), if it's event handling relies on times() accuracy. Problem
occurs after 5 minutes of system's running, when Linux tick timer value
reaches its limit on 32 bits systems.
glibc has a special handling for "times" syscall.
I have attached a patch that implements times in the same way as glibc.
Could maintainers of uClibc get inspired from that patch and do a
correction for this problem please ?
Denys Vlasenko a écrit :
> On Thursday 24 April 2008 21:43, Will Newton wrote:
>>> > This is effectively testing the bottom 32bits of jiffies_64 against
>>> > the largest known errno value which occasionally will be true even
>>> > when no error has been returned.
>>> Just delete the check for error.
>> The check is in generic syscall wrappers. glibc does exactly the same thing.
> I propose creating another wrapper for syscalls which never fail.
>>> My take is that this syscall should be considered
>>> as "never returning errors".
>> syscalls do return errors!
> What error can this particular syscall return? I see only one:
> EINVAL, when user passed invalid pointer to "struct tms".
> In this case, the program is buggy anyway.
> It probably won't help one iota that libc will pass EINVAL
> back in errno in this case. So why should we do that?
>>> The only programs which will see the difference are buggy already
>>> since they pass invalid pointer to kernel.
>> The case I am interested in is when a valid pointer is passed in but
>> the value of the low 32bits of jiffies_64 returned is being
>> interpreted as an error.
> Yes, I understand that.
> I propose to fix it by interpreting all posiible return values
> as non-errors.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2146 bytes
Desc: not available
More information about the uClibc