Re: lib/41085: sigaction returns EINVAL instead of -1

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR lib/41085; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
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@localhost