I've got bug in handling ERESTART_RESTARTBLOCK. Kernel version is 2.6.28.
Steps to reproduce:
1. Attach using ptrace() to process while it's in a syscall which use
ERESTART_RESTARTBLOCK
on interrupt. The easiest way is to attach to process which is in nanosleep().
2. Run a syscall in context of the process like it does gdb.
3. Continue the process.
Results:
Syscall(nanosleep) return error code 516(ERESTART_RESTARTBLOCK). It's
kernel's internal error
code and should never appear at userspace.
It seems ARM-related since I can't reproduce it on x86.
Example:
$ cat test.c
#include <errno.h>
#include <stdio.h>
#include <time.h>
int main()
{
struct timespec ts;
int ret;
ts.tv_sec = 100;
ts.tv_nsec = 0;
errno = 0;
ret = nanosleep(&ts, NULL);
printf("ret: %d, errno: %d\n", ret, errno);
return 0;
}
$ gcc test.c
$ ./a.out &
$ gdb -p "$(pidof a.out)" -ex 'call getuid()' -ex 'c' -ex 'quit'
GNU gdb (GDB) 6.8.50.20090417-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Attaching to process 6136
Reading symbols from /root/a.out...(no debugging symbols found)...done.
Reading symbols from /lib/libc.so.6...Reading symbols from
/usr/lib/debug/lib/libc-2.5.so...(no debugging symbols found)...done.
(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.3...Reading symbols from
/usr/lib/debug/lib/ld-2.5.so...(no debugging symbols found)...done.
(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.3
0x400bf97c in nanosleep () from /lib/libc.so.6
0x400bf97c <nanosleep+28>: mov r7, r12
$1 = 0
Continuing.
ret: -1, errno: 516
Program exited normally.
[1] + Done ./a.out
On Wed, Jun 10, 2009 at 01:25:34PM +0300, Kirill A. Shutemov wrote:
> I've got bug in handling ERESTART_RESTARTBLOCK. Kernel version is 2.6.28.
>
> Steps to reproduce:
> 1. Attach using ptrace() to process while it's in a syscall which use
> ERESTART_RESTARTBLOCK
> on interrupt. The easiest way is to attach to process which is in nanosleep().
> 2. Run a syscall in context of the process like it does gdb.
> 3. Continue the process.
>
> Results:
> Syscall(nanosleep) return error code 516(ERESTART_RESTARTBLOCK). It's
> kernel's internal error
> code and should never appear at userspace.
>
> It seems ARM-related since I can't reproduce it on x86.
That's because GDB has code to do the right thing on x86. Consider
filing a GDB bug please.
--
Daniel Jacobowitz
CodeSourcery
On Thu, Jun 11, 2009 at 5:27 PM, Daniel Jacobowitz<[email protected]> wrote:
> On Wed, Jun 10, 2009 at 01:25:34PM +0300, Kirill A. Shutemov wrote:
>> I've got bug in handling ERESTART_RESTARTBLOCK. Kernel version is 2.6.28.
>>
>> Steps to reproduce:
>> 1. Attach using ptrace() to process while it's in a syscall which use
>> ERESTART_RESTARTBLOCK
>> on interrupt. The easiest way is to attach to process which is in nanosleep().
>> 2. Run a syscall in context of the process like it does gdb.
>> 3. Continue the process.
>>
>> Results:
>> Syscall(nanosleep) return error code 516(ERESTART_RESTARTBLOCK). It's
>> kernel's internal error
>> code and should never appear at userspace.
>>
>> It seems ARM-related since I can't reproduce it on x86.
>
> That's because GDB has code to do the right thing on x86. Consider
> filing a GDB bug please.
http://sourceware.org/bugzilla/show_bug.cgi?id=10267