Python C API对error()的调用绑定到libc实现,而不是本地的

2024-05-13 08:14:55 发布

您现在位置:Python中文网/ 问答频道 /正文

编辑

请参见文章结尾处,以获得对Employed Russian评论的编辑

免责声明

在继续之前,我知道命名一个函数error通常是不好的做法,因为它可能会与libc中的类似函数冲突,但这是我在一些我几乎无法控制的第三方软件中遇到的问题。 另外,我很想知道这个错误是从哪里来的:-)

问题

我遇到的问题是,当下面的代码通过Python解释器执行而不是调用error函数的本地实现时,实际上是调用libC的error函数(如下面GDB的堆栈跟踪所示)。你知道吗

当在另一个C程序中简单地编译相同的代码时,我没有这样的问题。有人知道这是从哪里来的吗?这与Python加载共享库的方式有关吗?你知道吗

MCVE公司

#include <stdio.h>
#include <Python.h>

static PyObject* call_error(PyObject *self, PyObject *args);
static PyMethodDef module_methods[] = {
     {"error", call_error, METH_NOARGS, "call error"},
     {NULL, NULL, 0, NULL}
};

static struct PyModuleDef module_defs = {
     PyModuleDef_HEAD_INIT,
     "Test", "Test", -1, module_methods, NULL, NULL, NULL, NULL};

PyObject* PyInit_Test(void)
{
     PyObject *module = PyModule_Create(&module_defs);
     return module;
}

void error(const char* fmt, ...);

PyObject* call_error(PyObject *self, PyObject *args)
{
     error("Error!");
     Py_RETURN_NONE;
}

void error(const char* fmt, ...)
{
     va_list ap;
     va_start(ap, fmt);
     vprintf(fmt, ap);
     va_end(ap);
}

GDB输出

下面是在GDB中使用python3 -c "import Test; Test.error()"导入并运行上述代码的输出

GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from python3...(no debugging symbols found)...done.
(gdb) r -c 'import Test; Test.error()'
Starting program: /usr/bin/python3 -c 'import Test; Test.error()'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
/usr/bin/python3:
Program received signal SIGSEGV, Segmentation fault.
__strchrnul_sse2 () at ../sysdeps/x86_64/multiarch/../strchr.S:32
32  ../sysdeps/x86_64/multiarch/../strchr.S: No such file or directory.
(gdb) where
#0  __strchrnul_sse2 () at ../sysdeps/x86_64/multiarch/../strchr.S:32
#1  0x00007ffff6c2c432 in __find_specmb (format=0x4 <error: Cannot access memory at
#     address 0x4>) at printf-parse.h:108
#2  _IO_vfprintf_internal (s=0x7fffffffae60, format=0x4 <error: Cannot access memory at 
#     address 0x4>, ap=0x7fffffffd5b0) at vfprintf.c:1320
#3  0x00007ffff6c2f680 in buffered_vfprintf (s=s@entry=0x7ffff6fbd680 <_IO_2_1_stderr_>,
#     format=format@entry=0x4 <error: Cannot access memory at address 0x4>,
#     args=args@entry=0x7fffffffd5b0) at vfprintf.c:2329
#4  0x00007ffff6c2c726 in _IO_vfprintf_internal (s=0x7ffff6fbd680 <_IO_2_1_stderr_>,
#     format=format@entry=0x4 <error: Cannot access memory at address 0x4>, 
#     ap=ap@entry=0x7fffffffd5b0) at vfprintf.c:1301
#5  0x00007ffff6cef9bb in error_tail (status=status@entry=-161613509, 
#     errnum=errnum@entry=0, message=message@entry=0x4 <error: Cannot access memory at 
#     address 0x4>, args=args@entry=0x7fffffffd5b0) at error.c:271
#6  0x00007ffff6cefb3d in __error (status=-161613509, errnum=0, message=0x4 
#     <error: Cannot access memory at address 0x4>) at error.c:321
#7  0x00007ffff65df82e in call_error (self=0x7ffff67f3548, args=0x0) at test.c:24
#8  0x00000000004c5352 in _PyCFunction_FastCallKeywords ()
#9  0x000000000054ffe4 in ?? ()
#10 0x00000000005546cf in _PyEval_EvalFrameDefault ()
#11 0x000000000054fbe1 in ?? ()
#12 0x0000000000550b93 in PyEval_EvalCode ()
#13 0x000000000042c4ca in PyRun_SimpleStringFlags ()
#14 0x0000000000441918 in Py_Main ()
#15 0x0000000000421ff4 in main ()

编辑

我确实考虑过导入Python模块的dlopen问题,实际上下面的代码编译并运行得很好,可以打印出来:

> ./main
Hi there

main.c

#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>
#include <errno.h>
#include <stdarg.h>

typedef void*(*arbitrary)();

extern void error(const char* fmt, ...);

int main(int argc, char **argv)
{
     void *handle;
     arbitrary my_function;

     handle = dlopen("./libtest.so", RTLD_LAZY | RTLD_GLOBAL);
     if (!handle) {
      fprintf(stderr, "%s\n", dlerror());
      exit(EXIT_FAILURE);
     }

     dlerror();    /* Clear any existing error */

     *(void**)(&my_function) = dlsym(handle,"foo");
     (void) my_function();

     // Note: binding using dlsym(handle, "error") works too

     dlclose(handle);
     exit(EXIT_SUCCESS);
}

test.c

#include <stdio.h>
#include <stdarg.h>

extern void error(const char* fmt, ...);
extern void foo(void);

void foo(void)
{
     error("Hi there\n");
}

void error(const char* fmt, ...)
{
     va_list ap;
     va_start(ap, fmt);
     vprintf(fmt, ap);
     va_end(ap);
}

Tags: intestincludeargserrornullatap
1条回答
网友
1楼 · 发布于 2024-05-13 08:14:55

this is an issue I have with some third-party software on which I have little control.

如果您有这个第三方软件的源代码,您可以编辑它们,或者使用宏技巧重命名函数,例如-Derror=foo_error。你知道吗

如果只有存档库,请使用objcopy redefine-symbol ...。你知道吗

如果你只有一个共享库,我不知道一个可行的解决方案。你知道吗

Does it have to do with the way Python loads shared libraries ?

差不多吧。现在的情况是,动态加载程序将对error的引用解析为该函数最早的导出的定义。你知道吗

当您将error链接到主a.out时,该定义是链接器搜索顺序中的第一个定义,因此它“获胜”。你知道吗

当您使用dlopen加载libfoo.so时,它包含error(这是Python为import所做的),这个库被加载在libc.so.6之后,这意味着libc.so.6出现在加载程序搜索顺序的前面,它的定义是“wins”。你知道吗

您不需要Python就能看到这一点:编写一个使用dlopen的普通测试,同样的问题也会出现在其中。你知道吗

更新:

I had written a small test case

你的测试案例证实了我的答案。您可能没有正确构建它。你知道吗

$ gcc -fPIC -shared -o libtest.so test.c
$ gcc main.c -ldl 

这里调用“错误的”error,因为库加载的顺序是:a.outlibc.so.6然后libtest.so

$ ./a.out
./a.out: UH��H�=�: Unknown error 640192728

但你可能做的是:

$ gcc main.c ./libtest.so -ldl

这里库加载的顺序是a.outlibtest.so(因为a.out直接依赖于libtest.so),然后libc.so.6,然后调用“right”error

$ ./a.out
Hi there

相关问题 更多 >