Bug #9008

TestProcess#test_clock_getres_constants and TestProcess#test_clock_gettime_constants fails on ARM

Added by Vit Ondruch 6 months ago. Updated 2 months ago.

[ruby-core:57771]
Status:Rejected
Priority:Normal
Assignee:Akira Tanaka
Category:-
Target version:-
ruby -v:ruby -v: ruby 2.1.0dev (2013-09-22 trunk 43011) [armv7hl-linux] Backport:1.9.3: UNKNOWN, 2.0.0: UNKNOWN

Description

=begin
I observe following two errors on ARM Building Ruby for Fedora Rawhide. It seems that (({:CLOCKREALTIMEALARM})) and (({:CLOCKBOOTTIMEALARM})) are not supported there. The error message is confusing, though :/

3) Error:
TestProcess#testclockgetresconstants:
Errno::E524: Unknown error 524 - clock
getres
/builddir/build/BUILD/ruby-2.1.0-preview1/test/ruby/testprocess.rb:1752:in clock_getres'
/builddir/build/BUILD/ruby-2.1.0-preview1/test/ruby/test_process.rb:1752:in
block in test
clockgetresconstants'
/builddir/build/BUILD/ruby-2.1.0-preview1/test/ruby/testprocess.rb:1749:in each'
/builddir/build/BUILD/ruby-2.1.0-preview1/test/ruby/test_process.rb:1749:in
test
clockgetresconstants'
4) Error:
TestProcess#testclockgettimeconstants:
Errno::E524: Unknown error 524 - clock
gettime
/builddir/build/BUILD/ruby-2.1.0-preview1/test/ruby/testprocess.rb:1676:in clock_gettime'
/builddir/build/BUILD/ruby-2.1.0-preview1/test/ruby/test_process.rb:1676:in
block in test
clockgettimeconstants'
/builddir/build/BUILD/ruby-2.1.0-preview1/test/ruby/testprocess.rb:1673:in each'
/builddir/build/BUILD/ruby-2.1.0-preview1/test/ruby/test_process.rb:1673:in
test
clockgettimeconstants'

I am going to resolve the issue temporary by applying

sed -i '/Process.constants.grep(\/\ACLOCK\/).each {|n|/ s/$/\n next if [:CLOCKREALTIMEALARM, :CLOCKBOOTTIMEALARM].include? n/' \
test/ruby/test
process.rb

on ARM platform, but is there some better solution?
=end

History

#1 Updated by Akira Tanaka 6 months ago

2013/10/9 vo.x (Vit Ondruch) v.ondruch@tiscali.cz:

Bug #9008: TestProcess#testclockgetresconstants and TestProcess#testclockgettimeconstants fails on ARM
https://bugs.ruby-lang.org/issues/9008

I observe following two errors on ARM Building Ruby for Fedora Rawhide. It seems that (({:CLOCKREALTIMEALARM})) and (({:CLOCKBOOTTIMEALARM})) are not supported there. The error message is confusing, though :/

Errno::E524: Unknown error 524 - clock_gettime

This means clock_gettime() causes an error and errno is 524.

Why clock_gettime on Fedora Rawhide (ARM) doesn't cause EINVAL for
such constants?

http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_getres.html
|
| [EINVAL]
| The clock_id argument does not specify a known clock.
--
Tanaka Akira

#2 Updated by Vit Ondruch 6 months ago

Why clock_gettime on Fedora Rawhide (ARM) doesn't cause EINVAL for
such constants?

That is good question. I was hoping that you might know better ... So to say, I have no idea. I tried to identify the place where the error is risen, but I failed. I might try to report this issue to our Kernel maintainers.

#3 Updated by Motohiro KOSAKI 6 months ago

ENOTSUPP
Note:

524 mean ENOSUPP.
CLOCKREALTIMEALARM and CLOCKBOOTTIMEALARM uses following code. That says, it's a kernel bug.

linux/kernel/time/alarmtimer.c

/**
* alarmclockgetres - posix getres interface
* @whichclock: clockid
* @tp: timespec to fill
*
* Returns the granularity of underlying alarm base clock
*/
static int alarm
clockgetres(const clockidt whichclock, struct timespec *tp)
{
clockid
t baseid = alarmbases[clock2alarm(whichclock)].base_clockid;

    if (!alarmtimer_get_rtcdev())
            return -ENOTSUPP;

    return hrtimer_get_res(baseid, tp);

}

Any question?

#4 Updated by Motohiro KOSAKI 6 months ago

One more.

Linux man page agree with OpenGroup spec. see

http://man7.org/linux/man-pages/man2/clock_getres.2.html

EINVAL The clk_id specified is not supported on this system.

#5 Updated by Akira Tanaka 6 months ago

2013/10/15 kosaki (Motohiro KOSAKI) kosaki.motohiro@gmail.com:

Issue #9008 has been updated by kosaki (Motohiro KOSAKI).

ENOTSUPP
Note:

524 mean ENOSUPP.

Any question?

Is ENOTSUPP related with ENOTSUP defined by POSIX?
--
Tanaka Akira

#6 Updated by Motohiro KOSAKI 6 months ago

(10/15/13 3:30 AM), Tanaka Akira wrote:

2013/10/15 kosaki (Motohiro KOSAKI) kosaki.motohiro@gmail.com:

Issue #9008 has been updated by kosaki (Motohiro KOSAKI).

ENOTSUPP
Note:

524 mean ENOSUPP.

Any question?

Is ENOTSUPP related with ENOTSUP defined by POSIX?

dunno.

  1. Linux doesn't have ENOTSUP
  2. Linux define ENOTSUPP as NFS specific and in-kernel only definition
  3. ENOTSUPP is not exported to userland
  4. but timer_create and other various syscall uses ENOTSUPP as ENOTSUP

    I guess this is historical mess. And I guess 4 is a bug. But I'm not sure.

#7 Updated by Motohiro KOSAKI 6 months ago

Oops. error.

Current glibc has following definition.

/usr/include/bits/errno.h

define ENOTSUP EOPNOTSUPP

So, my previous mail is wrong. ENOTSUPP is equal to ENOTSUP now.

#8 Updated by Akira Tanaka 6 months ago

2013/10/16 kosaki (Motohiro KOSAKI) kosaki.motohiro@gmail.com:

Issue #9008 has been updated by kosaki (Motohiro KOSAKI).

Current glibc has following definition.

/usr/include/bits/errno.h

define ENOTSUP EOPNOTSUPP

EOPNOTSUPP is not ENOTSUPP.

If errno 524 is defined as an error symbol Ruby knows,
Errno::XXX should be defined.
(Ruby knows ENOTSUP and EOPNOTSUPP.)

Anyway I understand ENOTSUP is not intended to used in userland.
So Ruby don't need to know it.
--
Tanaka Akira

#9 Updated by Motohiro KOSAKI 6 months ago

On Tue, Oct 15, 2013 at 6:48 PM, Tanaka Akira akr@fsij.org wrote:

2013/10/16 kosaki (Motohiro KOSAKI) kosaki.motohiro@gmail.com:

Issue #9008 has been updated by kosaki (Motohiro KOSAKI).

Current glibc has following definition.

/usr/include/bits/errno.h

define ENOTSUP EOPNOTSUPP

EOPNOTSUPP is not ENOTSUPP.

Right. sorry for noise.

If errno 524 is defined as an error symbol Ruby knows,
Errno::XXX should be defined.
(Ruby knows ENOTSUP and EOPNOTSUPP.)

Anyway I understand ENOTSUP is not intended to used in userland.

So Ruby don't need to know it.

Tanaka Akira

#10 Updated by Vit Ondruch 6 months ago

Just for the record, this is discussed on Fedora's ARM list as well: https://lists.fedoraproject.org/pipermail/arm/2013-October/006965.html

#11 Updated by Motohiro KOSAKI 6 months ago

  • Status changed from Open to Rejected

I and John Stulz agreed we need Linux kernel and now my patch is queued for linux 3.13.
It mean Linux 3.13 and later return EINVAL instead 524.

Closed then.

#12 Updated by Vit Ondruch 6 months ago

Thank you for sorting this out!

#13 Updated by Motohiro KOSAKI 6 months ago

I and John Stulz agreed we need Linux kernel

s/need Linux kernel/need to fix Linux kernel/, of course.

#14 Updated by Vit Ondruch 2 months ago

Just FYI, the test suite passes on Fedora Rawhide with 3.12.9-300.fc20.armv7hl Kernel. Thanks for pushing the fix upstream.

Also available in: Atom PDF