c - 远程基于 C 的 CGI 脚本在 __libc_start_main() 中崩溃

Question

我有一个用 C 语言编写的 CGI 脚本。我知道这在当今时代是非正统的，但我有我的理由。此外，它是使用 -static 编译的，因此我不必担心我的 Web 提供商上的共享库。该脚本已经运行一年多了，但最近坏了。调试问题也是出了名的困难，因为脚本在我的 Web 提供商的服务上崩溃了，而且我看不到太多信息。但我确实得到了核心转储。

我看到的问题是: 在远程服务器上，CGI 脚本崩溃并且错误显然来自启动代码，即在我的 main() 函数之前执行的内容是曾经达到(__libc_start_main())。

我创建了一个 SSCCE这说明了问题，名为 hey.c:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
  printf("Content-type: text/plain\n\n");
  printf("Hey, is this thing on?\n");
  printf("query string: '%s'\n", getenv("REQUEST_URI"));
  return 0;
}

在 64 位 Linux 上使用 gcc 编译:

gcc -g -Wall hey.c -o hey.cgi -static

在提示下运行良好:

$ REQUEST_URI="q=querystring" ./hey.cgi
Content-type: text/plain

Hey, is this thing on?
query string: 'q=querystring'

当我在 Apache 安装上本地运行它时(例如，http://localserver/cgi-bin/hey.cgi?q=query)，网页显示:

Hey, is this thing on?
query string: '/cgi-bin/hey.cgi?q=query'

但是，当我将此二进制文件放入我的 Web 提供商的 Apache cgi-bin 目录时，我收到了 500 内部服务器错误。服务器在崩溃后留下编号的核心转储，然后我下载并使用 gdb 检查:

Core was generated by `hey.cgi'.
Program terminated with signal 11, Segmentation fault.
#0  0x000000000041b763 in __syscall_error ()
(gdb) bt
#0  0x000000000041b763 in __syscall_error ()
#1  0x0000000000402569 in __libc_message ()
#2  0x000000000040283c in __libc_fatal ()
#3  0x0000000000401355 in __libc_start_main ()
#4  0x0000000000401081 in _start ()

我知道有很多低级别的细节，但希望 Stack Overflow 上的某个人可以清楚地知道这个问题。谢谢。

更多细节，根据评论:我用一个简单的 Python CGI 脚本(和 os.environ[])验证了 REQUEST_URI 已定义。我认为这是 CGI 协议(protocol)的核心，但我不是专家。

file 报告 x86-64 静态链接二进制文件； ldd 报告“不是动态可执行文件”。 Libtool 从未发挥作用——我使用单个 gcc 命令调用来构建整个脚本。

最好在服务器上编译脚本。如果我有那种访问权限，我可能会有足够的灵 active 来避免这种方法。我不担心保护来源；这只是我能找到的解决问题的最佳方法。所讨论的程序是我网站的自定义搜索引擎，由大约 20 行 C 代码组成，用于与名为 SWISH-E 的库进行交互。我的网络提供商没有提供太多设施，但我能够完成这项工作。

其他解决方案包括:转移到不同的主机(很麻烦)；寻找我的主机支持的纯基于 PHP 的解决方案(我正在通过 mnoGoSearch 对此进行调查)。

Answer 1

我找到了一个解决方案并想发布它，因为这些 Stack Overflow 问题可以在 Google 搜索结果中排名靠前。

最终，我计划通过将这一点功能移动到我具有更好调试可见性的不同服务器或平台来解决这个问题。与此同时，我决定，由于问题似乎是使用-static编译的表现，并且因为我无法将必要的共享库安装到共享主机系统的标准lib目录中，相反，我会采取动态的方法。我将必要的共享对象上传到与编译脚本相同的目录中，并重新编写了基于 C 的 CGI 脚本以使用 dlopen/dlsym 动态打开共享对象、获取所需的函数指针并调用这些指针。

在我研究其他解决方案的同时，这种方法行得通(尽管我一直祈祷它不会再次神秘地崩溃)。如果其他人遇到这种奇怪的问题组合，也许这会有所帮助。