System call v.s. errno

System call v.s. errno

[Richard B. Johnson]

Does anybody know for sure if global 'errno' is supposed to
be altered after a successful system call? I'm trying to
track down a problem where system calls return with EINTR
even though all signal handlers are set with SA_RESTART in
the flags. It appears as though there may be a race somewhere
because if I directly set errno to 0x1234, within a few
hundred system calls, it gets set to EINTR even though all
system calls seemed to return 'good'. This makes it
hard to trace down the real problem.

The answer is not obvious because the 'C' runtime library
doesn't really give access to 'errno' instead it is dereferenced
off some pointer returned from a function called __errno_location().

This problem does not exist with Linux-2.4.x. It started to show
up when user's updated their machines to newer RH stuff that uses
linux-2.6.5-1.358.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

Re: System call v.s. errno

[Måns Rullgård]

"Richard B. Johnson" <linux-os@analogic.com> writes:

> Does anybody know for sure if global 'errno' is supposed to
> be altered after a successful system call? I'm trying to
> track down a problem where system calls return with EINTR
> even though all signal handlers are set with SA_RESTART in
> the flags. It appears as though there may be a race somewhere
> because if I directly set errno to 0x1234, within a few
> hundred system calls, it gets set to EINTR even though all
> system calls seemed to return 'good'. This makes it
> hard to trace down the real problem.
>
> The answer is not obvious because the 'C' runtime library
> doesn't really give access to 'errno' instead it is dereferenced
> off some pointer returned from a function called __errno_location().

The kernel knows nothing about errno.  Have you tried using strace to
check the actual return values of the system calls?

> This problem does not exist with Linux-2.4.x. It started to show
> up when user's updated their machines to newer RH stuff that uses
> linux-2.6.5-1.358.

So go file a bug with redhat.  It wouldn't be the first time they ship
broken stuff.

-- 
Måns Rullgård
mru@inprovide.com

Re: System call v.s. errno

[Wichert Akkerman]

Previously Richard B. Johnson wrote:
> Does anybody know for sure if global 'errno' is supposed to
> be altered after a successful system call?

It's not. Also this is not a kernel related question: errno is managed
by libc.

Wichert.

-- 
Wichert Akkerman <wichert@wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

Re: System call v.s. errno

[Jakub Jelinek]

On Wed, May 04, 2005 at 09:22:09AM -0400, Richard B. Johnson wrote:
> Does anybody know for sure if global 'errno' is supposed to
> be altered after a successful system call? I'm trying to
> track down a problem where system calls return with EINTR
> even though all signal handlers are set with SA_RESTART in
> the flags. It appears as though there may be a race somewhere
> because if I directly set errno to 0x1234, within a few
> hundred system calls, it gets set to EINTR even though all
> system calls seemed to return 'good'. This makes it
> hard to trace down the real problem.

http://www.opengroup.org/onlinepubs/009695399/functions/errno.html
is very clear on this.  Unless indicated that errno is valid after a call
(for many syscalls it is valid when the syscall returns -1), errno has
unspecified value.

	Jakub

Re: System call v.s. errno

[Richard B. Johnson]

On Wed, 4 May 2005, Jakub Jelinek wrote:

> On Wed, May 04, 2005 at 09:22:09AM -0400, Richard B. Johnson wrote:
>> Does anybody know for sure if global 'errno' is supposed to
>> be altered after a successful system call? I'm trying to
>> track down a problem where system calls return with EINTR
>> even though all signal handlers are set with SA_RESTART in
>> the flags. It appears as though there may be a race somewhere
>> because if I directly set errno to 0x1234, within a few
>> hundred system calls, it gets set to EINTR even though all
>> system calls seemed to return 'good'. This makes it
>> hard to trace down the real problem.
>
> http://www.opengroup.org/onlinepubs/009695399/functions/errno.html
> is very clear on this.  Unless indicated that errno is valid after a call
> (for many syscalls it is valid when the syscall returns -1), errno has
> unspecified value.
>
> 	Jakub
> -

Okay, thanks. That means that it's okay for it to get trashed
NotGood(tm) for debugging.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

Re: System call v.s. errno

[Martin Waitz]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

hoi :)

On Wed, May 04, 2005 at 09:22:09AM -0400, Richard B. Johnson wrote:
> Does anybody know for sure if global 'errno' is supposed to
> be altered after a successful system call? I'm trying to
> track down a problem where system calls return with EINTR
> even though all signal handlers are set with SA_RESTART in
> the flags.

syscalls are only automatically restarted by the interrupt if the
syscall returns -ERESTARTSYS. If it returns -EINTR itself then that will
be delivered to userspace even when it sets SA_RESTART.

-- 
Martin Waitz

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: System call v.s. errno

[Arjan van de Ven]

On Wed, 2005-05-04 at 09:22 -0400, Richard B. Johnson wrote:
> Does anybody know for sure if global 'errno' is supposed to

errno is a glibc level thing really, and in recent glibc tehre is no
global errno anymore, only a per thread errno.

> The answer is not obvious because the 'C' runtime library
> doesn't really give access to 'errno' instead it is dereferenced
> off some pointer returned from a function called __errno_location().

yeah to make sure you get the per thread errno instead. Any reasonable
sane code (and all standards conforming code) just deals with that fine.
The case that is known to break is if your app has it's own

extern int errno;

in it, instead of using the proper header to get it.

Re: System call v.s. errno

[Stephen Hemminger]

On Wed, 4 May 2005 09:49:37 -0400 (EDT)
"Richard B. Johnson" <linux-os@analogic.com> wrote:

> On Wed, 4 May 2005, Jakub Jelinek wrote:
> 
> > On Wed, May 04, 2005 at 09:22:09AM -0400, Richard B. Johnson wrote:
> >> Does anybody know for sure if global 'errno' is supposed to
> >> be altered after a successful system call? I'm trying to
> >> track down a problem where system calls return with EINTR
> >> even though all signal handlers are set with SA_RESTART in
> >> the flags. It appears as though there may be a race somewhere
> >> because if I directly set errno to 0x1234, within a few
> >> hundred system calls, it gets set to EINTR even though all
> >> system calls seemed to return 'good'. This makes it
> >> hard to trace down the real problem.
> >
> > http://www.opengroup.org/onlinepubs/009695399/functions/errno.html
> > is very clear on this.  Unless indicated that errno is valid after a call
> > (for many syscalls it is valid when the syscall returns -1), errno has
> > unspecified value.
> >
> > 	Jakub
> > -
> 
> Okay, thanks. That means that it's okay for it to get trashed
> NotGood(tm) for debugging.
> 
> Cheers,
> Dick Johnson

Also, on with NPTL and many thread libraries errno is really a macro
that refers to a per-thread variable.

-- 
Stephen Hemminger	<shemminger@osdl.org>