hey phil,
file descriptor 5 is being allocated via the dup call.
it's a duplicate of file descriptor 3.
it'd be interesting to see where the application is dying.
one way to determine this would be to do the following:
- get the pid of the linux shell process:
# echo $$
12345
- as root from the global zone, use truss to trace the linux
shell process and it's children. have truss stop any children
when they get a SIGSEGV. this can be done with the following
command:
# truss -f -t\!all -s \!all -S SIGSEGV -p 12345
- then in the linux shell process try to start the webmin process.
in the global zone you should see something like (but not exactly
the same as):
# truss -f -t\!all -s \!all -S SIGSEGV -p 12345
13000: Incurred fault #6, FLTBOUNDS %pc = 0x080509D5
13000: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
13000: Received signal #11, SIGSEGV [default]
13000: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
- at this point, the program that is crashing has been stopped.
so now in the global zone you can interrupt truss with a ctrl-C
and run pstack on the stopped process. it'll looking something
like:
13000: Received signal #11, SIGSEGV [default]
13000: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
^C
# pstack 13000
13000: ./a
...
the output from both the truss and pstack commands could be very
informative.
ed
On Wed, Sep 19, 2007 at 10:01:37PM -0700, Phil Cordier wrote:
> For this seg vio issue - there is no core file generated that I can find
> anywhere...
>
> Interestingly enough, this appears to be a problem related to /dev/null - I
> can eliminate the error by removing the redirection of stderr to /dev/null.
>
> Ie this line in /etc/init.d/webmin causes the problem:
>
> $start > /dev/null 2>&1 < /dev/null
>
> [root at centos init.d]# ./webmin start
> ./webmin: line 70: 8973 Segmentation fault $start >/dev/null 2>&1
> </dev/null
>
> But this one does not:
>
> $start > /dev/null < /dev/null
>
> [root at centos init.d]# ./webmin start
> [root at centos init.d]# pgrep -fl webmin
> 8990 /usr/bin/perl /usr/libexec/webmin/miniserv.pl /etc/webmin/miniserv.conf
>
>
> I see these same errors output by a number of other init scripts on boot,
> when logged into the zone console.
>
> I can reproduce the problem also from an interactive shell, by redirecting
> stderr / file handle 2 to /dev/null. Redirecting stderr to a file seems to
> work fine.
>
> So I ran : strace -v -s 1024-f ./webmin start
>
> the last few lines of which look like:
>
> [pid 9104] ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0x80476b8) = -1 ENOTTY
> (Inappropriate ioctl for device)
> [pid 9104] _llseek(4, 0, 0x80476f0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
> [pid 9104] fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
> [pid 9104] connect(4, {sa_family=AF_FILE, path="/dev/log"}, 110) = 0
> [pid 9104] select(8, [4], NULL, [4], {0, 0}) = 0 (Timeout)
> [pid 9104] write(4, "<86>webmin[9104]: Webmin starting\n\0", 35) = 35
> [pid 9104] dup(3) = 5
> [pid 9104] ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS <unfinished ...>
> [pid 9104] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> Process 9103 resumed
> Process 9104 detached
> <... waitpid resumed> [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}], 0) = 9104
> fstat64(2, {st_dev=makedev(181, 5), st_ino=72845, st_mode=S_IFREG|0644,
> st_nlink=1, st_uid=0, st_gid=0, st_blksize=1310
> 72, st_blocks=164, st_size=244032, st_atime=2007/09/20-00:52:20,
> st_mtime=2007/09/20-00:53:19, st_ctime=2007/09/20-00:5
> 3:19}) = 0
> mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0xfebe5000
> write(2, "./webmin: line 70: 9104 Segmentation fault $start >/dev/null
> 2>&1 </dev/null\n", 83./webmin: line 70:
> 9104 Segmentation fault $start >/dev/null 2>&1 </dev/null
> ) = 83
>
> It looks like file descriptor 5 being passed to the ioctl above is not
> allocated/defined anywhere in the results of the strace, that I can find......
>
> Trying to use either ksh or ash to run the script also results in a seg vio
> errror, so this certainly does not look a bash specific issue, but something
> related to usage of /dev/null itself.
>
>
> This message posted from opensolaris.org
> _______________________________________________
> brandz-discuss mailing list
> brandz-discuss at opensolaris.org
