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

Question

已编辑

请参阅文章末尾的编辑以回应 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输出

这是使用 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);
}

Answer 1

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 加载包含 error 的 libfoo.so 时(这是 Python 为 import)，该库在 libc.so.6 之后加载，这意味着 libc.so.6 在加载程序搜索顺序中出现较早，及其定义“获胜”。

您不需要 Python 也能看到这一点:编写一个使用 dlopen 的简单测试，同样的问题会出现在其中。

更新:

I had written a small test case

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

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

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

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

但你可能做的是这样的:

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

这里加载库的顺序是a.out，libtest.so(因为a.out 直接 取决于 libtest.so)，then libc.so.6，“正确的”error 得到称为:

$ ./a.out
Hi there