NetBSD Problem Report #41085
From www@NetBSD.org Fri Mar 27 13:10:37 2009
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
by www.NetBSD.org (Postfix) with ESMTP id A488163BAFE
for <gnats-bugs@gnats.netbsd.org>; Fri, 27 Mar 2009 13:10:37 +0000 (UTC)
Message-Id: <20090327131037.4C13F63B8DE@www.NetBSD.org>
Date: Fri, 27 Mar 2009 13:10:37 +0000 (UTC)
From: matteo@beccati.com
Reply-To: matteo@beccati.com
To: gnats-bugs@NetBSD.org
Subject: sigaction returns EINVAL instead of -1
X-Send-Pr-Version: www-1.0
>Number: 41085
>Category: lib
>Synopsis: sigaction returns EINVAL instead of -1
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: lib-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Mar 27 13:15:00 +0000 2009
>Closed-Date: Mon Apr 13 02:55:00 +0000 2009
>Last-Modified: Mon Apr 13 02:55:00 +0000 2009
>Originator: Matteo Beccati
>Release: 4.0 (XEN DOM0)
>Organization:
>Environment:
NetBSD epia.hq.beccati.com 4.0_STABLE NetBSD 4.0_STABLE (EPIA) #4: Thu Mar 26 18:25:20 CET 2009 toor@epia.hq.beccati.com:/mnt/usb/src/sys/arch/i386/compile/obj/EPIA i386
>Description:
Under some circumstances sigaction returns the errno instead of returning -1 and setting the errno variable. Unfortunately I wasn't able to write a self contained test case. The bug is triggered when running a unit test for the php pcntl extension (CVS HEAD).
Here's what I found out when running gdb:
Breakpoint 1, php_signal (signo=-1, func=0x82d00f3 <pcntl_signal_handler>,
restart=1) at /root/compile/php-HEAD/ext/pcntl/php_signal.c:28
called php_signal with a valid func pointer and invalid signo.
28 act.sa_handler = func;
(gdb) next
29 sigemptyset(&act.sa_mask);
(gdb) next
30 act.sa_flags = 0;
(gdb) next
sigaction act was set
33 if (signo == SIGALRM || (! restart)) {
(gdb) next
39 act.sa_flags |= SA_RESTART; /* SVR4, 4.3+BSD */
(gdb) next
restart flag also set.
43 retval = sigaction(signo, &act, &oact);
(gdb) step
45 if (retval < 0)
(gdb) print retval
$1 = 22
retval == EINVAL
(gdb) print act
$2 = {_sa_u = {_sa_handler = 0x82d00f3 <pcntl_signal_handler>,
_sa_sigaction = 0x82d00f3 <pcntl_signal_handler>}, sa_mask = {__bits = {0,
0, 0, 0}}, sa_flags = 2}
act looks fine to me
(gdb) print errno
$3 = 0
errno == 0
(gdb) print oact
$4 = {_sa_u = {_sa_handler = 0x8537160, _sa_sigaction = 0x8537160}, sa_mask = {
__bits = {138096588, 136402289, 138096544, 6}}, sa_flags = 15}
oact looks a bit weird.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
From: Matthias Drochner <M.Drochner@fz-juelich.de>
To: gnats-bugs@NetBSD.org
Cc: lib-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
netbsd-bugs@NetBSD.org
Subject: Re: lib/41085: sigaction returns EINVAL instead of -1
Date: Fri, 27 Mar 2009 18:32:07 +0100
That's really weird... At some time (before netbsd-4) the binary
layout of "struct sigaction" changed, because sigset_t was
expanded to make room for more than 32 signals. There is a
compatibility stub for old binaries, you'll get that if
you don't include the header which redirects to the current
version. In that case, a linker warning should be issued,
recommending to include <signal.h>. Is that perhaps what
happens here?
best regards
Matthias
-------------------------------------------------------------------
-------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt,
Dr. Sebastian M. Schmidt
-------------------------------------------------------------------
-------------------------------------------------------------------
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: lib/41085: sigaction returns EINVAL instead of -1
Date: Fri, 27 Mar 2009 22:00:32 +0000
On Fri, Mar 27, 2009 at 01:15:01PM +0000, matteo@beccati.com wrote:
> 43 retval = sigaction(signo, &act, &oact);
> (gdb) step
> 45 if (retval < 0)
> (gdb) print retval
> $1 = 22
That's bizarre. If this is repeatable, can you try running it under
ktrace? That would reveal at least which sigaction call it's actually
making, and if the return/error value shows up strangely under ktrace
it will be a big hint.
--
David A. Holland
dholland@netbsd.org
From: Matteo Beccati <matteo@beccati.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: lib/41085: sigaction returns EINVAL instead of -1
Date: Sat, 28 Mar 2009 01:08:21 +0100
> From: David Holland <dholland-bugs@netbsd.org>
> On Fri, Mar 27, 2009 at 01:15:01PM +0000, matteo@beccati.com wrote:
> > 43 retval = sigaction(signo, &act, &oact);
> > (gdb) step
> > 45 if (retval < 0)
> > (gdb) print retval
> > $1 = 22
>
> That's bizarre. If this is repeatable, can you try running it under
> ktrace? That would reveal at least which sigaction call it's actually
> making, and if the return/error value shows up strangely under ktrace
> it will be a big hint.
Even more bizzare is the fact that I can't see any call to the
__sigaction_sigtramp when sigaction() is returning 22:
Proper call to sigaction(SIGALRM), with PHP outputting the result bool(true)
15993 1 php RET write 12/0xc
15993 1 php CALL
__sigaction_sigtramp(SIGALRM,0xbfbfcfbc,0xbfbfcfa4,0xbaf58e6c,2)
15993 1 php RET __sigaction_sigtramp 0
15993 1 php CALL write(1,0x83b30f4,0xb)
15993 1 php GIO fd 1 wrote 11 bytes
"bool(true)
"
Call with a wrong callback, PHP outputs an error, plus the false result:
15993 1 php RET write 11/0xb
15993 1 php CALL write(1,0x83b3254,0x8c)
15993 1 php GIO fd 1 wrote 140 bytes
"
Warning: pcntl_signal(): Invalid value for handle argument
specified i\
n /root/compile/php-HEAD/ext/pcntl/tests/pcntl_signal.php on
line 10
"
15993 1 php RET write 140/0x8c
15993 1 php CALL write(1,0x83b30f4,0xc)
15993 1 php GIO fd 1 wrote 12 bytes
"bool(false)
"
This is the interesting bit. PHP outputs bool(true) because sigaction
returned 22. No trace of the sigaction(-1) call.
15993 1 php RET write 12/0xc
15993 1 php CALL write(1,0x83b30f4,0xb)
15993 1 php GIO fd 1 wrote 11 bytes
"bool(true)
"
It seems that sigaction() validates signo itself and returns EINVAL
without making the syscall, or something along the lines.
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: lib/41085: sigaction returns EINVAL instead of -1
Date: Sat, 28 Mar 2009 04:44:06 +0000
On Sat, Mar 28, 2009 at 12:10:05AM +0000, Matteo Beccati wrote:
> It seems that sigaction() validates signo itself and returns EINVAL
> without making the syscall, or something along the lines.
Is maybe PHP doing some kind of macro wrapper around sigaction? This
is PHP we're talking about after all... and while it's possible that
ktrace could just miss the sigaction call entirely, that doesn't seem
very likely. (And in fact, the code in libc is such that if you try to
sigaction on signal -1, it ought to call __sigaction_sigtramp
*twice*.)
I've looked over the kernel and libc code involved and I don't see any
plausible way for it to mix the return value and error code, unless
something Xen-specific is causing the carry flag (which distinguishes
error returns from real return values) to get cleared in the low-level
code on the way back from the system call. But for that one would need
to explain why ktrace isn't seeing anything. Plus, if it's there and
it's repeatable, one would expect it to affect a lot more than just
sigaction.
Can you easily check if the problem occurs only under Xen?
--
David A. Holland
dholland@netbsd.org
From: Matteo Beccati <matteo@beccati.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: lib/41085: sigaction returns EINVAL instead of -1
Date: Sat, 28 Mar 2009 08:21:23 +0100
David Holland wrote:
> Is maybe PHP doing some kind of macro wrapper around sigaction? This
> is PHP we're talking about after all... and while it's possible that
> ktrace could just miss the sigaction call entirely, that doesn't seem
> very likely. (And in fact, the code in libc is such that if you try to
> sigaction on signal -1, it ought to call __sigaction_sigtramp
> *twice*.)
From what I can see the PHP code calls sigaction() just like any other
libc sig* function.
> I've looked over the kernel and libc code involved and I don't see any
> plausible way for it to mix the return value and error code, unless
> something Xen-specific is causing the carry flag (which distinguishes
> error returns from real return values) to get cleared in the low-level
> code on the way back from the system call. But for that one would need
> to explain why ktrace isn't seeing anything. Plus, if it's there and
> it's repeatable, one would expect it to affect a lot more than just
> sigaction.
>
> Can you easily check if the problem occurs only under Xen?
Same happens with a GENERIC kernel. If you want I can provide ssh access
to the machine.
Anyway, here's a trimmed down version of the script. I've added a
nanosleep call just to make it obvious to identify the call in the
ktrace output:
root@epia:~/compile/php-HEAD# cat pcntl_signal.php
<?php
usleep(1);
var_dump(pcntl_signal(-1, function(){}));
ktrace of sig related calls, plus the sigaction call above:
...
745 1 php CALL __sigprocmask14(0,0,0xbfa00074)
745 1 php RET __sigprocmask14 0
745 1 php CALL __sigprocmask14(0,0,0xbaee3be0)
745 1 php RET __sigprocmask14 0
745 1 php CALL
__sysctl(0xbfbfe7dc,2,0xbfbfe7e4,0xbfbfe7e8,0,0)
745 1 php RET __sysctl 0
745 1 php CALL
__sysctl(0xbfbfe81c,2,0xbafc3240,0xbfbfe824,0,0)
745 1 php RET __sysctl 0
745 1 php CALL
__sigaction_sigtramp(SIGPIPE,0xbfbfe688,0xbfbfe670,0xbaf58e6c,2)
745 1 php RET __sigaction_sigtramp 0
...
745 1 php CALL
__sigaction_sigtramp(SIGPROF,0xbfbfe5c8,0xbfbfe5b0,0xbaf58e6c,2)
745 1 php RET __sigaction_sigtramp 0
745 1 php CALL __sigprocmask14(3,0xbaee3be0,0)
745 1 php RET __sigprocmask14 0
...
745 1 php CALL nanosleep(0xbfbfcffc,0)
745 1 php RET nanosleep 0
745 1 php CALL write(1,0x83b2600,0xb)
745 1 php GIO fd 1 wrote 11 bytes
"bool(true)
"
...
gdb:
(gdb) break php_signal
Breakpoint 1 at 0x82d0296: file
/root/compile/php-HEAD/ext/pcntl/php_signal.c, line 29.
(gdb) run pcntl_signal.php
Starting program: /root/compile/php-HEAD/sapi/cli/php pcntl_signal.php
Breakpoint 1, php_signal (signo=-1, func=0x82d00de
<pcntl_signal_handler>, restart=1) at
/root/compile/php-HEAD/ext/pcntl/php_signal.c:29
29 act.sa_handler = func;
(gdb) list
24 * in the Unix Environment by W. Richard Stevens p 298. */
25 Sigfunc *php_signal(int signo, Sigfunc *func, int restart)
26 {
27 int retval;
28 struct sigaction act,oact;
29 act.sa_handler = func;
30 sigemptyset(&act.sa_mask);
31 act.sa_flags = 0;
32 if (signo == SIGALRM || (! restart)) {
33 #ifdef SA_INTERRUPT
(gdb) list
34 act.sa_flags |= SA_INTERRUPT; /* SunOS */
35 #endif
36 } else {
37 #ifdef SA_RESTART
38 act.sa_flags |= SA_RESTART; /* SVR4, 4.3+BSD */
39 #endif
40 }
41
42 retval = sigaction(signo, &act, &oact);
43
(gdb) disassemble
Dump of assembler code for function php_signal:
0x082d0290 <php_signal+0>: push %ebp
0x082d0291 <php_signal+1>: mov %esp,%ebp
0x082d0293 <php_signal+3>: sub $0x48,%esp
0x082d0296 <php_signal+6>: mov 0xc(%ebp),%eax
0x082d0299 <php_signal+9>: mov %eax,0xffffffe4(%ebp)
0x082d029c <php_signal+12>: sub $0xc,%esp
0x082d029f <php_signal+15>: lea 0xffffffe4(%ebp),%eax
0x082d02a2 <php_signal+18>: add $0x4,%eax
0x082d02a5 <php_signal+21>: push %eax
0x082d02a6 <php_signal+22>: call 0x805d0a0 <__sigemptyset14@plt>
0x082d02ab <php_signal+27>: add $0x10,%esp
0x082d02ae <php_signal+30>: movl $0x0,0xfffffff8(%ebp)
0x082d02b5 <php_signal+37>: cmpl $0xe,0x8(%ebp)
0x082d02b9 <php_signal+41>: je 0x82d02ca <php_signal+58>
0x082d02bb <php_signal+43>: cmpl $0x0,0x10(%ebp)
0x082d02bf <php_signal+47>: je 0x82d02ca <php_signal+58>
0x082d02c1 <php_signal+49>: mov 0xfffffff8(%ebp),%eax
0x082d02c4 <php_signal+52>: or $0x2,%eax
0x082d02c7 <php_signal+55>: mov %eax,0xfffffff8(%ebp)
0x082d02ca <php_signal+58>: sub $0x4,%esp
0x082d02cd <php_signal+61>: lea 0xffffffcc(%ebp),%eax
0x082d02d0 <php_signal+64>: push %eax
0x082d02d1 <php_signal+65>: lea 0xffffffe4(%ebp),%eax
0x082d02d4 <php_signal+68>: push %eax
0x082d02d5 <php_signal+69>: pushl 0x8(%ebp)
0x082d02d8 <php_signal+72>: call 0x805d360 <__sigaction14@plt>
0x082d02dd <php_signal+77>: add $0x10,%esp
0x082d02e0 <php_signal+80>: mov %eax,0xfffffffc(%ebp)
0x082d02e3 <php_signal+83>: cmpl $0x0,0xfffffffc(%ebp)
0x082d02e7 <php_signal+87>: jns 0x82d02f2 <php_signal+98>
0x082d02e9 <php_signal+89>: movl $0xffffffff,0xffffffbc(%ebp)
0x082d02f0 <php_signal+96>: jmp 0x82d02f8 <php_signal+104>
0x082d02f2 <php_signal+98>: mov 0xffffffcc(%ebp),%eax
0x082d02f5 <php_signal+101>: mov %eax,0xffffffbc(%ebp)
0x082d02f8 <php_signal+104>: mov 0xffffffbc(%ebp),%eax
0x082d02fb <php_signal+107>: leave
0x082d02fc <php_signal+108>: ret
End of assembler dump.
(gdb) advance 44
php_signal (signo=-1, func=0x82d00de <pcntl_signal_handler>, restart=1)
at /root/compile/php-HEAD/ext/pcntl/php_signal.c:44
44 if (retval < 0)
(gdb) print retval
$1 = 22
(gdb) print act
$2 = {_sa_u = {_sa_handler = 0x82d00de <pcntl_signal_handler>,
_sa_sigaction = 0x82d00de <pcntl_signal_handler>}, sa_mask = {__bits =
{0, 0, 0, 0}}, sa_flags = 2}
(gdb) print oact
$3 = {_sa_u = {_sa_handler = 0x8537098, _sa_sigaction = 0x8537098},
sa_mask = {__bits = {138093920, 136402289, 138092292, 6}}, sa_flags = 15}
From: David Laight <david@l8s.co.uk>
To: gnats-bugs@NetBSD.org
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, matteo@beccati.com
Subject: Re: lib/41085: sigaction returns EINVAL instead of -1
Date: Sat, 28 Mar 2009 12:24:58 +0000
On Sat, Mar 28, 2009 at 04:45:02AM +0000, David Holland wrote:
>
> I've looked over the kernel and libc code involved and I don't see any
> plausible way for it to mix the return value and error code, unless
> something Xen-specific is causing the carry flag (which distinguishes
> error returns from real return values) to get cleared in the low-level
> code on the way back from the system call.
Or somehow some Linux system call code is being used/assumed...
Where, instead of using the carry flag, small negative return values
are taken as errno values.
David
--
David Laight: david@l8s.co.uk
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: lib/41085: sigaction returns EINVAL instead of -1
Date: Sat, 28 Mar 2009 17:55:37 +0000
On Sat, Mar 28, 2009 at 07:25:01AM +0000, Matteo Beccati wrote:
> From what I can see the PHP code calls sigaction() just like any other
> libc sig* function.
Yeah, and if there were shenanigans going on it'd be clear from the
disassembly in your last mail.
Still, it does rather look like it's not getting into the kernel at
all.
What's php linked against? Do any of the shared library images ldd
reports define a __sigaction14 or __sigaction_sigtramp symbol, other
than libc? That seems unlikely, but might as well rule out as many
possible avenues of weirdness as possible.
Does the same thing happen in a standalone program that calls
sigaction on signal -1? e.g. something like this:
#include <stdio.h>
#include <signal.h>
#include <errno.h>
void sig(int foo) {
printf("sig: %d\n", foo);
}
int main(void) {
struct sigaction sa;
int ret;
sa.sa_handler = sig;
sigemptyset(&sa.sa_mask);
sa.sa_flags = 0;
errno = 12345;
ret = sigaction(-1, &sa, NULL);
printf("got %d, errno %d\n", ret, errno);
return 0;
}
If not, I wonder if the problem is that php is corrupting the PLT or
something...
>> Can you easily check if the problem occurs only under Xen?
>
> Same happens with a GENERIC kernel.
Well, that rules that out...
> If you want I can provide ssh access to the machine.
Hopefully that shouldn't be necessary.
> Anyway, here's a trimmed down version of the script. I've added a
> nanosleep call just to make it obvious to identify the call in the
> ktrace output:
>
> root@epia:~/compile/php-HEAD# cat pcntl_signal.php
> <?php
> usleep(1);
> var_dump(pcntl_signal(-1, function(){}));
Doesn't work in php 5.2.9, which is all I have ready access to :-/
(I also don't currently have anything older than 4.99.72 to test on.)
Another thing you might try, since you can get it in gdb, is to stepi
into the sigaction call and see where it goes; it *should* go to
__sigaction14, which will (possibly twice) call __sigaction_sigtramp,
which will do int 0x80 to make the actual syscall.
But I dunno how well this will work. stepi in gdb has never been very
friendly to me...
--
David A. Holland
dholland@netbsd.org
From: Matteo Beccati <matteo@beccati.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: lib/41085: sigaction returns EINVAL instead of -1
Date: Sat, 28 Mar 2009 20:17:25 +0100
David Holland wrote:
> On Sat, Mar 28, 2009 at 07:25:01AM +0000, Matteo Beccati wrote:
> > From what I can see the PHP code calls sigaction() just like any other
> > libc sig* function.
>
> Yeah, and if there were shenanigans going on it'd be clear from the
> disassembly in your last mail.
>
> Still, it does rather look like it's not getting into the kernel at
> all.
>
> What's php linked against? Do any of the shared library images ldd
> reports define a __sigaction14 or __sigaction_sigtramp symbol, other
> than libc? That seems unlikely, but might as well rule out as many
> possible avenues of weirdness as possible.
root@epia:~/compile/php-HEAD# ldd sapi/cli/php | cut -d ' ' -f 3 | grep
.so | xargs -n1 grep sigaction
Binary file /usr/lib/libpthread.so.0 matches
Binary file /usr/lib/libc.so.12 matches
> Does the same thing happen in a standalone program that calls
> sigaction on signal -1? e.g. something like this:
Nope. That's why I wasn't able to build a self contained test case.
But, given the above, look at this:
root@epia:~/compile/php-HEAD# gcc pn.c
root@epia:~/compile/php-HEAD# ./a.out
got -1, errno 22
root@epia:~/compile/php-HEAD# gcc -lpthread pn.c
root@epia:~/compile/php-HEAD# ./a.out
got 22, errno 12345
From: David Holland <dholland-bugs@netbsd.org>
To: Matteo Beccati <matteo@beccati.com>
Cc: gnats-bugs@netbsd.org
Subject: Re: lib/41085: sigaction returns EINVAL instead of -1
Date: Sat, 28 Mar 2009 19:58:51 +0000
On Sat, Mar 28, 2009 at 07:20:06PM +0000, Matteo Beccati wrote:
> root@epia:~/compile/php-HEAD# gcc -lpthread pn.c
> root@epia:~/compile/php-HEAD# ./a.out
> got 22, errno 12345
Aaaargh....
Index: pthread_sig.c
===================================================================
RCS file: /cvsroot/src/lib/libpthread/Attic/pthread_sig.c,v
retrieving revision 1.47.2.2
diff -u -p -r1.47.2.2 pthread_sig.c
--- pthread_sig.c 16 Sep 2008 18:49:33 -0000 1.47.2.2
+++ pthread_sig.c 28 Mar 2009 19:57:40 -0000
@@ -220,8 +220,10 @@ __sigaction14(int sig, const struct siga
pthread_t self;
int retval;
- if ((sig <= 0) || (sig >= _NSIG))
- return EINVAL;
+ if ((sig <= 0) || (sig >= _NSIG)) {
+ errno = EINVAL;
+ return -1;
+ }
self = pthread__self();
pthread_spinlock(self, &pt_sigacts_lock);
--
David A. Holland
dholland@netbsd.org
From: Andrew Doran <ad@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, matteo@beccati.com
Subject: Re: lib/41085: sigaction returns EINVAL instead of -1
Date: Sat, 28 Mar 2009 20:46:11 +0000
On Sat, Mar 28, 2009 at 08:00:09PM +0000, David Holland wrote:
> Aaaargh....
Kind of understandable given the environment, most of the calls return
errno directly. Must have seemed like a good idea at some point.
From: David Holland <dholland-bugs@netbsd.org>
To: Andrew Doran <ad@netbsd.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: lib/41085: sigaction returns EINVAL instead of -1
Date: Sat, 28 Mar 2009 21:36:12 +0000
On Sat, Mar 28, 2009 at 08:46:11PM +0000, Andrew Doran wrote:
> > Aaaargh....
>
> Kind of understandable given the environment, most of the calls return
> errno directly. Must have seemed like a good idea at some point.
It seemed like a good idea to the pthreads committee, who also gave us
so many other things to rejoice about. :-|
--
David A. Holland
dholland@netbsd.org
From: Matteo Beccati <matteo@beccati.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: lib/41085: sigaction returns EINVAL instead of -1
Date: Wed, 01 Apr 2009 19:00:22 +0200
David Holland wrote:
> Index: pthread_sig.c
> ===================================================================
> RCS file: /cvsroot/src/lib/libpthread/Attic/pthread_sig.c,v
> retrieving revision 1.47.2.2
The fix works smoothly, however I haven't seen the commit to the
netbsd-4 branch.
NetBSD 5 works ok out of the box (and I expect -current does as well) as
it seems that sigaction is not redefined in libpthread.
Thanks again
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: lib/41085: sigaction returns EINVAL instead of -1
Date: Sun, 5 Apr 2009 04:44:58 +0000
On Wed, Apr 01, 2009 at 05:05:05PM +0000, Matteo Beccati wrote:
> The fix works smoothly, however I haven't seen the commit to the
> netbsd-4 branch.
That's because (lacking a netbsd-4 machine at the moment) I was
waiting for someone to check it before filing the request with releng.
I have now done that; it's pullup-4 #1301.
--
David A. Holland
dholland@netbsd.org
From: <matteo@beccati.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: lib/41085: sigaction returns EINVAL instead of -1
Date: Sun, 05 Apr 2009 14:14:00 +0200
On Sun, 5 Apr 2009 04:45:02 +0000 (UTC), David Holland
<dholland-bugs@netbsd.org> wrote:
> On Wed, Apr 01, 2009 at 05:05:05PM +0000, Matteo Beccati wrote:
> > The fix works smoothly, however I haven't seen the commit to the
> > netbsd-4 branch.
>
> That's because (lacking a netbsd-4 machine at the moment) I was
> waiting for someone to check it before filing the request with releng.
>
> I have now done that; it's pullup-4 #1301.
Thanks a lot!
From: Soren Jacobsen <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/41085 CVS commit: [netbsd-4] src/lib/libpthread
Date: Fri, 10 Apr 2009 20:27:45 +0000
Module Name: src
Committed By: snj
Date: Fri Apr 10 20:27:45 UTC 2009
Modified Files:
src/lib/libpthread [netbsd-4]: pthread_sig.c
Log Message:
Apply patch (requested by dholland in ticket #1301):
In the pthreads wrapper for __sigaction14, return -1 and set errno
rather than returning an error number directly like many pthreads
functions do. Fixes a problem where sigaction(-1, ...) returns
EINVAL instead of failing with EINVAL, reported by Matteo Beccati
in PR lib/41085.
To generate a diff of this commit:
cvs rdiff -u -r1.47.2.2 -r1.47.2.3 src/lib/libpthread/pthread_sig.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 13 Apr 2009 02:55:00 +0000
State-Changed-Why:
Fixed, thanks.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home