solaris libc中的ioctl原型 [英] ioctl prototype in solaris libc

问题描述

我在以下堆栈中遇到了程序问题.

I had a program issue with the following stack.

6600:   ora_d006_LOOKUP
 ffffffff7addbbd0 __systemcall6 (3, ffffffff7d300440, 0, ffffffff7adc1268, d, fff7) + 24
 ffffffff7adcba74 pthread_sigmask (2000, 0, 0, 0, ffffffff7d300200, d) + 1c4
 00000001068ff3bc sslssalck (ffffffff7fffb138, 2, ffffffff7fffb070, 0, 3e8, 10c24d7e0) + 7c
 00000001069358e8 sltmarm (a00029810, 29810, 10c3f3ab0, 3f9, a00000000, 29810) + 88
 00000001069aa734 ltmdvp (8006689e, 3f9, 0, 10c55ba38, 10c3f8160, 10c3f34d0) + 154
 00000001068ff2a4 sslsstehdlr (e, 0, ffffffff7fffb570, 7fffff84, 10c3ed0d8, 10c24d7e0) + 224
 ffffffff7add7498 __sighndlr (e, 0, ffffffff7fffb570, 1068fcba0, 0, d) + c
 ffffffff7adcb02c call_user_handler (ffffffff7d300200, ffffffff7d300200, ffffffff7fffb570, c, 0, 0) + 3e0
 ffffffff7adcb238 sigacthandler (0, 0, ffffffff7fffb570, ffffffff7d300200, 0, ffffffff7af3e000) + 68
 --- called from signal handler with signal 0 (SIGEXIT) ---
 ffffffff7addad48 ioctl (10c3f80c0, bb8, 400, 10c426810, 10c6aae90, 2001420c) + c
 0000000109e47668 nteveque (10c40c940, bb8, ffffffff7fffca98, 1afbfb85a4, 1c, 98) + 28
 0000000109e3f0c0 ntevque (7, bb8, 10c2cbfd0, 10c40c940, ffffffff7fffca98, 10c2cbfd0) + 80
 0000000109d8e738 nsevwait (0, 0, 10c25cc00, 0, 10c25cc04, 10c3f7a60) + 1b8
 000000010092e7b4 ksnwait (10c25cc00, 6, 10c403fb0, 10c25c000, 10c25c, 10c000) + 54
 000000010072060c ksliwat (0, ffffffff7fffd8e8, 1770, 10c25b, 10c000, 0) + 140c
 0000000100704b28 kslwait (1770, ffffffff7fffd8e8, ffffffff7fffd8e8, ffffffff7fffd8e8, 0, 0) + e8
 00000001065707a0 kmdmai (1b1bfffe00, 10c2628e8, 1b02faf258, 10c26c190, 10c25b, 38000d000) + e40
 00000001063b0400 opirip (10a726000, 0, 380002, 380000, 38002a000, 38002a) + a80
 00000001035c59cc opidrv (32, 4, ffffffff7ffff590, 1ebb90, ffffffff7af45050, ffffffff7ffff9a0) + 30c
 000000010474117c sou2o (ffffffff7ffff568, 32, 4, ffffffff7ffff590, 10c000, 10b800) + 5c
 0000000100604f64 opimai_real (3, ffffffff7ffff838, ffffffff7ffffb60, ffffffff7ffffbb5, 0, 0) + 204
 0000000104757380 ssthrdmain (10c000, 3, 44dc00, 100604d60, 10c27c000, 10c27c) + 140
 0000000100604c74 main (3, ffffffff7ffff948, 0, ffffffff7ffff840, ffffffff7ffff950, ffffffff7d300200) + 134
 0000000100604b1c _start (0, 0, 0, 0, 0, 0) + 17c

此过程用于调度来自客户端的请求.在发布期间，无法再发送任何请求，并且此过程消耗了许多SYS CPU.

this process is used to dispatch request from client. During the issue, no more request can be sent in and this process consumed many SYS cpu.

man ioctl，我将在系统调用中获得ioctl的原型.但我认为它与ioctl不同. pstack输出中的ioctl应该是userland中的一个函数.

man ioctl, I will get the prototype of ioctl in system call. but I don't think it is same as the ioctl. The ioctl in the output of pstack should be a function in userland.

在pstack中:

--- called from signal handler with signal 0 (SIGEXIT) ---
ffffffff7addad48 ioctl (10c3f80c0, bb8, 400, 10c426810, 10c6aae90, 2001420c) + c

我写了一个小的dtrace脚本.

I wrote a small dtrace script.

pid$target::ioctl:entry
{
        printf("%s", probemod)
}

我知道

3  82218                      ioctl:entry libc.so.1

所以我认为这个ioctl来自libc.so.

so I think this ioctl came from libc.so.

但是我无法从libc.so获得ioctl的手册.

But I can't get the manual for ioctl from libc.so.

1在哪里可以找到solaris的libc中的ioctl手册?

1 where can I get the manual for ioctl in libc of solaris?

2据说SIGEXIT是伪信号.如何为此设置信号句柄?如何发送一个进程的SIGEXIT信号?最后，我们将获得以下堆栈?

2 it is said that SIGEXIT is a pseudo signal. how to set up signal handle for this? how to sent SIGEXIT signal for a process? and at the last, we will have the following stack?

  ...  my_handle_signal .... 
  --- called from signal handler with signal 0 (SIGEXIT) ---
  ... xxxx

推荐答案

您在/devices/pseudo/poll@0:poll设备(或/dev/pool)上的ioctl似乎是由common/io/devpoll.c文件(在线副本- http://fxr.watson.org/fxr/source /common/io/devpoll.c?v=OPENSOLARIS )

Your ioctl on /devices/pseudo/poll@0:poll device (or /dev/pool) seems to be handled by kernel function from common/io/devpoll.c file (online copy - http://fxr.watson.org/fxr/source/common/io/devpoll.c?v=OPENSOLARIS)

更精确地，通过dpioctl函数:

 692 dpioctl(dev_t dev, int cmd, intptr_t arg, int mode, cred_t *credp, int *rvalp)

zhihuifan，检查完堆栈跟踪后，我看到您的程序已执行:

zhihuifan, after checking your stacktrace I see that you program had executed:

main() -> ... nteveque() -> ioctl()

然后调用了信号处理程序..我没有从dpioctl发送信号，所以我认为该信号是由某些外部函数(或程序或用户)发送的:

Then the signal hanlder was called.. I see no sending of signals from dpioctl, so I think the signal was send by some external function (or program or by user):

--- called from signal handler with signal 0 (SIGEXIT) ---

然后将用户空间信号处理程序称为:

Then the user-space signal handler was called:

sigacthandler ->     call_user_handler ->     __sighndlr 
-> sslsstehdlr 

sslsstehdlr做了很多操作，并且根据我的知识和POSIX标准((来自开放组基本规范第6期； IEEE Std 1003.1，2004年版)，信号处理程序只能(直接或间接)调用表

The sslsstehdlr did many actions, and according to my knowledge and POSIX standards ("2.4 Signal Concepts" from The Open Group Base Specifications Issue 6; IEEE Std 1003.1, 2004 Edition), the signal handler may only call (directly or indirectly) functions listed in table

下表定义了一组功能，这些功能应可重入或不可被信号中断，并且应是异步信号安全的.因此，应用程序可以不受限制地从信号捕获功能中调用它们:

The following table defines a set of functions that shall be either reentrant or non-interruptible by signals and shall be async-signal-safe. Therefore applications may invoke them, without restriction, from signal-catching functions:

...庞大的清单，但是这里没有ptherad_sigmask ...

... huge list but there is no ptherad_sigmask here...

上表中未列出的所有功能均被视为对信号不安全. ....当信号中断不安全功能而信号捕捉功能调用不安全功能时，行为是不确定的.

All functions not in the above table are considered to be unsafe with respect to signals. .... when a signal interrupts an unsafe function and the signal-catching function calls an unsafe function, the behavior is undefined.

这篇关于solaris libc中的ioctl原型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！