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

Python C API call to error() binds to libc implementation instead of a local one

已编辑

请参阅 post 末尾的编辑以回应 的评论

免责声明

在继续之前,我知道将函数命名为 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 输出

这是使用 python3 -c "import Test; Test.error()"

在 GDB 中导入 运行 上述代码的输出
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);
}

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

如果您有此 third_party 软件的源代码,您可以对其进行编辑,或使用宏技巧重命名函数,例如-Derror=foo_error.

如果您只有存档库,请使用 objcopy --redefine-symbol ...

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

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

有点。发生的事情是动态加载器将对 error 的引用解析为该函数最早的 exported 定义。

当您 link error 进入主 a.out 时,该定义是 linker 搜索顺序中的第一个,因此它 "wins"。

当您使用 dlopen 加载包含 errorlibfoo.so(这是 Python 对 import 所做的)时,该库被加载 after libc.so.6,表示libc.so.6在loader搜索顺序中出现较早,其定义为"wins".

你不需要 Python 看到这个:写一个使用 dlopen 的简单测试,同样的问题会出现在里面。

更新:

I had written a small test case

您的测试用例确实证实了我的回答。您可能没有正确构建它。

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

这里调用了"wrong" error 因为库加载的顺序是:a.out, libc.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