NetBSD Problem Report #16284
Received: (qmail 7184 invoked from network); 10 Apr 2002 13:08:18 -0000
Message-Id: <200204101307.g3AD7k417099@nutcracker.stacken.kth.se>
Date: Wed, 10 Apr 2002 15:07:46 +0200 (CEST)
From: lha@stacken.kth.se
Reply-To: lha@stacken.kth.se
To: gnats-bugs@gnats.netbsd.org
Subject: running function in stoped gdb causes signal 93
X-Send-Pr-Version: 3.95
>Number: 16284
>Category: kern
>Synopsis: running function in stoped gdb causes signal 93
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kamil
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Apr 10 13:09:00 +0000 2002
>Closed-Date: Tue Jun 04 22:41:48 +0000 2019
>Last-Modified: Tue Jun 04 22:41:48 +0000 2019
>Originator: Love
>Release: NetBSD 1.5ZC
>Organization:
Stacken Computer Club
>Environment:
System: NetBSD nutcracker.stacken.kth.se 1.5ZC NetBSD 1.5ZC (NUTCRACKER) #8: Mon Apr 8 06:06:20 CEST 2002 lha@nutcracker.stacken.kth.se:/usr/src/sys/arch/i386/compile/NUTCRACKER i386
Architecture: i386
Machine: i386
>Description:
Running function in stoped gdb causes signal 93, example:
On a 1.5ZC/i386 host:
: root@nutcracker ; uname -rm
1.5ZC i386
: root@nutcracker ; cp /afs/e.kth.se/home/staff/lha/src/hacks/bar.c /tmp
: root@nutcracker ; gcc -o bar bar.c -g
: root@nutcracker ; gdb -q bar
(gdb) r
Starting program: /tmp/bar
^C
Program received signal SIGINT, Interrupt.
0x4809e9ef in select () from /usr/lib/libc.so.12
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x4809e9ef in select () from /usr/lib/libc.so.12
(gdb) p foo()
hej
$1 = void
(gdb) c
Continuing.
bar: select: Unknown error: 93
Program exited with code 01.
On a 1.5.3_ALPHA/i386 host:
: root@leif ; uname -rm
1.5.3_ALPHA i386
: root@leif ; gcc -o bar bar.c -g
: root@leif ; gdb -q bar
(gdb) r
Starting program: /tmp/bar
^C
Program received signal SIGINT, Interrupt.
0x48093c4b in select ()
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x48093c4b in select ()
(gdb) p foo()
hej
$1 = void
(gdb) c
Continuing.
>How-To-Repeat:
Use the following testprogram bar.c and do like above.
cat > bar.c <<EOF
#include <sys/types.h>
#include <sys/time.h>
#include <stdio.h>
#include <errno.h>
#include <err.h>
#include <unistd.h>
void
foo(void)
{
write(1, "hej\n", 4);
}
int
main(int argc, char **argv)
{
int ret;
struct timeval tv, t = { 1, 0};
while(1) {
tv = t;
ret = select(0, NULL, NULL, NULL, &tv);
if (ret < 0 && errno != EAGAIN)
err(1, "select");
}
}
EOF
>Fix:
Unknown at this moment.
>Release-Note:
>Audit-Trail:
From: Love <lha@stacken.kth.se>
To: gnats-bugs@netbsd.org
Cc:
Subject: kern/16284
Date: Fri, 12 Apr 2002 05:34:26 +0200 (CEST)
Ooops
s/signal/errno/
It was pointed out to me that it might be uninitized variable.
Love
From: Love <lha@stacken.kth.se>
To: gnats-bugs@netbsd.org
Cc:
Subject: kern/16284
Date: 29 Sep 2002 18:00:13 +0200
The errno doesn't seem to get down on the userland stack (the EAGAIN) that
is when the process got woken up by ptrace.
From: David Laight <david@l8s.co.uk>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/16284 running function in stoped gdb ...
Date: Sun, 3 Jan 2010 21:07:54 +0000
This still happens, errno is unchanged and the 'ret' value
from select() seems to be undefined.
ktrace shows a 'RET syscall 0' for the return from select
errno is unchanged (unless set in the called function).
gdb has to do some horrid stuff in order to call a process
function - and even the 'success' result is lost.
Sometimes, but not always, I also see almost 2 seconds delay before
the output from the called function - not sure where that delay comes from.
(A 2nd ^C gives a "Corrupt Obj_Entry pointer in GOT" error.)
Anyone know the ptrace interface well enough to know what gdb is
trying to do ?
David
--
David Laight: david@l8s.co.uk
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, lha@stacken.kth.se
Subject: Re: kern/16284 running function in stoped gdb ...
Date: Sun, 3 Jan 2010 21:19:36 +0000
On Sun, Jan 03, 2010 at 09:10:06PM +0000, David Laight wrote:
> This still happens, errno is unchanged and the 'ret' value
> from select() seems to be undefined.
My first guess would be that something in gdb that thinks %eax doesn't
have to be saved and restored (because it's caller-save) is trashing
the return value (which is held in %eax).
> Sometimes, but not always, I also see almost 2 seconds delay before
> the output from the called function - not sure where that delay comes from.
maybe another trip into select?
> (A 2nd ^C gives a "Corrupt Obj_Entry pointer in GOT" error.)
That's weird.
> Anyone know the ptrace interface well enough to know what gdb is
> trying to do ?
Not without reading gdb code.
--
David A. Holland
dholland@netbsd.org
From: Nick Hudson <nick.hudson@gmx.co.uk>
To: gnats-bugs@netbsd.org,
dsl@netbsd.org
Cc: kern-bug-people@netbsd.org,
gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
lha@stacken.kth.se
Subject: Re: kern/16284 running function in stoped gdb ...
Date: Mon, 4 Jan 2010 12:20:07 +0000
On Sunday 03 January 2010 21:10:06 David Laight wrote:
> The following reply was made to PR kern/16284; it has been noted by GNATS.
>
> From: David Laight <david@l8s.co.uk>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: kern/16284 running function in stoped gdb ...
> Date: Sun, 3 Jan 2010 21:07:54 +0000
>
> This still happens, errno is unchanged and the 'ret' value
> from select() seems to be undefined.
It works for me on NetBSD/i386 netbsd-5 from around Dec 12th.
Where do you see the problem?
> ktrace shows a 'RET syscall 0' for the return from select
> errno is unchanged (unless set in the called function).
>
> gdb has to do some horrid stuff in order to call a process
> function - and even the 'success' result is lost.
>
> Sometimes, but not always, I also see almost 2 seconds delay before
> the output from the called function - not sure where that delay comes
> from. (A 2nd ^C gives a "Corrupt Obj_Entry pointer in GOT" error.)
>
> Anyone know the ptrace interface well enough to know what gdb is
> trying to do ?
set debug infrun 1
See below
>
> David
>
Nick
--
kenny$ gdb bar
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386--netbsdelf"...
(gdb) set debug infrun 1
(gdb) run
Starting program: /tmp/bar
infrun: wait_for_inferior
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0xbbbf4770
infrun: quietly stopped
infrun: stop_stepping
infrun: resume (step=0, signal=0)
infrun: wait_for_inferior
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0xbbbf4770
infrun: quietly stopped
infrun: stop_stepping
infrun: proceed (addr=0xffffffff, signal=0, step=0)
infrun: resume (step=0, signal=0)
infrun: wait_for_inferior
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0xbbbf4ab8
infrun: BPSTATE_WHAT_CHECK_SHLIBS
infrun: no stepping, continue
infrun: resume (step=1, signal=0)
infrun: prepare_to_wait
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0xbbbf5d72
infrun: trap expected
infrun: no stepping, continue
infrun: resume (step=0, signal=0)
infrun: prepare_to_wait
^Cinfrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0xbbb1ba87
infrun: random signal 2
Program received signal SIGINT, Interrupt.
infrun: stop_stepping
0xbbb1ba87 in select () from /usr/lib/libc.so.12
(gdb) p foo()
infrun: proceed (addr=0x804877c, signal=0, step=0)
infrun: resume (step=0, signal=0)
infrun: wait_for_inferior
hej
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x8048540
infrun: BPSTATE_WHAT_STOP_SILENT
infrun: stop_stepping
$1 = void
(gdb) c
Continuing.
infrun: proceed (addr=0xffffffff, signal=144, step=0)
infrun: resume (step=0, signal=0)
infrun: wait_for_inferior
^Cinfrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0xbbb1ba87
infrun: random signal 2
Program received signal SIGINT, Interrupt.
infrun: stop_stepping
0xbbb1ba87 in select () from /usr/lib/libc.so.12
(gdb)
From: David Laight <david@l8s.co.uk>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/16284 running function in stoped gdb ...
Date: Mon, 4 Jan 2010 20:53:21 +0000
On Mon, Jan 04, 2010 at 12:20:07PM +0000, Nick Hudson wrote:
> >
> > This still happens, errno is unchanged and the 'ret' value
> > from select() seems to be undefined.
>
> It works for me on NetBSD/i386 netbsd-5 from around Dec 12th.
>
> Where do you see the problem?
By fixing the sample program to always print the return value from
select as well as errno.
Then splurious +ve values are also reported.
> set debug infrun 1
I'll try that and see...
David
--
David Laight: david@l8s.co.uk
Responsible-Changed-From-To: kern-bug-people->kamil
Responsible-Changed-By: kamil@NetBSD.org
Responsible-Changed-When: Sat, 07 Oct 2017 00:01:07 +0200
Responsible-Changed-Why:
Take.
I'm not sure if the original problem is still there, but I'm getting something else:
On Linux:
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x00007ffff7b1b3d3 in __select_nocancel () at ../sysdeps/unix/syscall-template.S:84
84 in ../sysdeps/unix/syscall-template.S
On NetBSD 8.99.1 amd64 with GDB 7.12
(gdb) r
Starting program: /tmp/bar
^C
Program received signal SIGINT, Interrupt.
0x00006fe10423b30a in _sys___select50 () from /usr/lib/libc.so.12
(gdb) c
Continuing.
bar: select: Interrupted system call
[Inferior 1 (LWP 0) exited with code 01]
(gdb)
This behavior change is suspicious and I will investigate it in future (but in few days or so).
State-Changed-From-To: open->closed
State-Changed-By: kamil@NetBSD.org
State-Changed-When: Wed, 05 Jun 2019 00:41:48 +0200
State-Changed-Why:
Problem no longer reproducible as of NetBSD 8.99.42.
Interrupted select returns EINTR and there is need to check for EINTR too next to EAGAIN.
If there are still any issues please report a new bug.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home