linux 上不可见的 SIGSEGV 不会在 Windows 上发生？

【问题标题】：Invisiable SIGSEGV on linux that does not happen on windows?linux 上不可见的 SIGSEGV 不会在 Windows 上发生？
【发布时间】：2011-11-05 10:09:48
【问题描述】：

简介

我有一个共享库形式的TCP/HTTP server that supports plugins（DLL 和.so）。它通过premake 具有make 和.sln 文件构建系统。当我启动我的应用程序时，我向它提供了一个这样的配置文件，其中描述了哪些库服务器将用作插件以及它将传递给 tham 的参数。有一段时间我有 2 个插件，一切都很好。如果我像this一样向我的服务器配置文件提供数据，即使现在也可以正常工作。但是现在我有了正在开发的新插件，所以new config file。

设置

在 linux 上设置我的服务器所需的步骤非常简单

  • 下载构建脚本（来自here，如here 所述）
  • ./cloud_server_net_setup.sh，不需要超级用户，需要 curl、make 和 g++ 在常规情况下（不是开发就足够了 - 它会得到提升，它需要的其他库进入本地文件夹，它将构建所有内容，以发布形式构建服务器）
  • 现在你可以 cd 进入cloud_server/install-dir/
  • 致电export LD_LIBRARY_PATH=./:./lib_boost
  • 并运行我们的服务器./CloudServer

但是我们需要调试版本所以在我们调用脚本之后我们

  • cd cloud_server/CloudServer/projects/linux-gmake/
  • make
  • cd bin/debug
  • export LD_LIBRARY_PATH=./:(place from where we called our script)/cloud_server/install-dir/lib_boost

问题

  • 现在，我们终于可以调用 gdb了。

所以我们称之为。这就是我们所看到的：

 gdb ./CloudServer

GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 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".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/ole_jak/cloud_server/CloudServer/projects/linux-gmake/bin/debug/CloudServer...done.
(gdb) r
Starting program: /home/ole_jak/cloud_server/CloudServer/projects/linux-gmake/bin/debug/CloudServer
[Thread debugging using libthread_db enabled]
Cloud Server v0.5
Copyright (c) 2011 Cloud Forever. All rights reserved.

Type 'help' to see help messages.
Config file path: config.xml
[New Thread 0x7ffff5967700 (LWP 11516)]
[New Thread 0x7ffff5166700 (LWP 11517)]
[New Thread 0x7ffff4965700 (LWP 11518)]
[New Thread 0x7ffff4164700 (LWP 11519)]
[New Thread 0x7ffff3963700 (LWP 11520)]
[New Thread 0x7ffff3162700 (LWP 11521)]
[New Thread 0x7ffff2961700 (LWP 11522)]
[New Thread 0x7ffff2160700 (LWP 11523)]
[New Thread 0x7ffff195f700 (LWP 11524)]
[New Thread 0x7ffff115e700 (LWP 11525)]
[New Thread 0x7ffff095d700 (LWP 11526)]
[New Thread 0x7fffebfff700 (LWP 11527)]
[New Thread 0x7fffeb7fe700 (LWP 11528)]
[New Thread 0x7fffeaffd700 (LWP 11529)]
[New Thread 0x7fffea7fc700 (LWP 11530)]
[New Thread 0x7fffe9ffb700 (LWP 11531)]
Library libFileService.so opened.
[New Thread 0x7fffe953c700 (LWP 11532)]
Library libUsersFilesService.so opened.

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) x/i $pc
0x0:    Cannot access memory at address 0x0

我是 Linux nube，我从 wikipedia 知道的关于分段错误的所有信息，但我还知道关于我的服务器和我正在创建的这项新服务的另一件事 - 它在 Windows 上编译和运行，完全没有错误（ VS2008、2010 解决方案可以使用相同的预制脚本创建）。

所以我想知道在这两个文件.cpp 和.h 中如何以及在哪里创建了一个错误，该错误不会在 Windows 上显示，而在 Linux 上却如此显着地显示？它是可修复的，还是对新鲜的眼睛可见？

更新： Valgrind 输出

ole_jak@dspproc:~/cloud_server/CloudServer/projects/linux-gmake/bin/debug$ valgrind ./CloudServer
==11682== Memcheck, a memory error detector
==11682== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==11682== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==11682== Command: ./CloudServer
==11682==
Cloud Server v0.5
Copyright (c) 2011 Cloud Forever. All rights reserved.

Type 'help' to see help messages.
Config file path: config.xml
Library libFileService.so opened.
Library libUsersFilesService.so opened.
==11682== Jump to the invalid address stated on the next line
==11682==    at 0x0: ???
==11682==    by 0x4D49BE: sqlite3_free (sqlite3.c:18155)
==11682==    by 0x102242D5: sqlite3OsInit (sqlite3.c:14162)
==11682==    by 0x1029EB28: sqlite3_initialize (sqlite3.c:107299)
==11682==    by 0x102A159F: openDatabase (sqlite3.c:108909)
==11682==    by 0x102A1B29: sqlite3_open (sqlite3.c:109156)
==11682==    by 0x1021CAB0: sqlite3pp::database::connect(char const*) (sqlite3pp.cpp:89)
==11682==    by 0x1021C6E3: sqlite3pp::database::database(char const*) (sqlite3pp.cpp:74)
==11682==    by 0x1020DDDF: users_files_service::create_files_table(std::string) (users_files_service.cpp:171)
==11682==    by 0x1020BAFC: users_files_service::apply_config(boost::shared_ptr<boost::property_tree::basic_ptree<std::string, std::string, std::less<std::string> > >) (users_files_service.cpp:38)
==11682==    by 0x4B5432: server_utils::parse_config_services(boost::property_tree::basic_ptree<std::string, std::string, std::less<std::string> >) (server_utils.cpp:156)
==11682==    by 0x4B6436: server_utils::parse_config(boost::property_tree::basic_ptree<std::string, std::string, std::less<std::string> >) (server_utils.cpp:208)
==11682==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==11682==
==11682==
==11682== Process terminating with default action of signal 11 (SIGSEGV)
==11682==  Bad permissions for mapped region at address 0x0
==11682==    at 0x0: ???
==11682==    by 0x4D49BE: sqlite3_free (sqlite3.c:18155)
==11682==    by 0x102242D5: sqlite3OsInit (sqlite3.c:14162)
==11682==    by 0x1029EB28: sqlite3_initialize (sqlite3.c:107299)
==11682==    by 0x102A159F: openDatabase (sqlite3.c:108909)
==11682==    by 0x102A1B29: sqlite3_open (sqlite3.c:109156)
==11682==    by 0x1021CAB0: sqlite3pp::database::connect(char const*) (sqlite3pp.cpp:89)
==11682==    by 0x1021C6E3: sqlite3pp::database::database(char const*) (sqlite3pp.cpp:74)
==11682==    by 0x1020DDDF: users_files_service::create_files_table(std::string) (users_files_service.cpp:171)
==11682==    by 0x1020BAFC: users_files_service::apply_config(boost::shared_ptr<boost::property_tree::basic_ptree<std::string, std::string, std::less<std::string> > >) (users_files_service.cpp:38)
==11682==    by 0x4B5432: server_utils::parse_config_services(boost::property_tree::basic_ptree<std::string, std::string, std::less<std::string> >) (server_utils.cpp:156)
==11682==    by 0x4B6436: server_utils::parse_config(boost::property_tree::basic_ptree<std::string, std::string, std::less<std::string> >) (server_utils.cpp:208)
==11682==
==11682== HEAP SUMMARY:
==11682==     in use at exit: 124,050 bytes in 1,083 blocks
==11682==   total heap usage: 1,814 allocs, 731 frees, 183,517 bytes allocated
==11682==
==11682== LEAK SUMMARY:
==11682==    definitely lost: 0 bytes in 0 blocks
==11682==    indirectly lost: 0 bytes in 0 blocks
==11682==      possibly lost: 46,248 bytes in 799 blocks
==11682==    still reachable: 77,802 bytes in 284 blocks
==11682==         suppressed: 0 bytes in 0 blocks
==11682== Rerun with --leak-check=full to see details of leaked memory
==11682==
==11682== For counts of detected and suppressed errors, rerun with: -v
==11682== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
Убито
ole_jak@dspproc:~/cloud_server/CloudServer/projects/linux-gmake/bin/debug$

【问题讨论】：

  • 首先要做的是下载valgrind，（你应该可以通过你的linux发行版下载它），然后运行'valgrind./CloudServer'。它应该能给你发生段错误时的调用堆栈。此外，仅仅因为您的 Windows 构建没有段错误，并不意味着它没有错误。它可能会在静默中遭受痛苦。
  • 另外，只是从您的输出中快速猜测，但您可能在引用 NULL 指针。
  • 似乎现在正在阅读它我开始看到问题...谢谢大家！）
  • 根据 gdb 输出，您正在取消引用 NULL 指针。您应该使用 gdb 找出为什么会这样。
  • AS @DarcyRayner 说 valgrind 会找到这个错误。但这看起来像是使用了一个未分配的指针。一种快速简便的方法是打开警告并将编译器设置为将警告视为错误（这应该可以帮助您找到问题）。请注意，您也应该在 DevStudio 中的 Windows 上执行此操作（将警告级别提高一级）。警告应被视为代码中的逻辑错误，并且您的代码应以零警告编译。

标签： c++ linux gcc cross-platform segmentation-fault


【解决方案1】：

这是一个讨厌的。我不确定确切的根本原因，但这似乎是与多线程相关的问题。问题的直接原因是sqlite3Config.m.xSize函数指针在错误发生的地点和时间是NULL。

这个指针应该在第一次调用sqlite3_initialize() 时被初始化为指向一个正确的函数，这通常发生在你第一次打开 SQLite 数据库文件时。通过在 GDB 中设置断点和观察点，我能够验证指针是否已成功设置，但在分段错误时，其值为 NULL。

这可能意味着以下两种情况之一：

  • 新指针值未正确传播到所有线程。 SQLite3 应该是线程安全的，但是，线程可能是讨厌的小虫子......

  • 指针在初始化后会重置。我认为这不太可能，因为sqlite3Config 结构通常不会在初始化后修改。

我执行了一个简单的测试，顺便说一下，它可以用作临时解决方法：我添加了对sqite3_initialize() 的显式调用作为main() 中的第一条语句，允许在启动任何线程之前执行它。结果，分段错误消失了，我得到了你的服务器的 shell 提示，它指向两个备选方案中的第一个。请注意，这充其量只是一种解决方法，因为不应该显式调用sqite3_initialize()。问题的根本原因可能仍然存在并以其他方式为人所知 - 或者更糟糕的是，它可能会以微妙但难以检测的方式破坏事物。

由于 SQLite3 是 supposed to be thread-safe（并且 sqlite3_initialize() 函数的源代码在这方面似乎是正确的），我不确定发生了什么。这可能是 sqlite3pp 包装器或线程启动方式的问题。

【讨论】：

  • 好吧 - 线程安全无关紧要...）无论如何我们找到了解决它的方法...）请参阅commit。问题很简单——我们有主应用程序和 .so 都静态链接到 SQLite。当我们第一次从我们的主应用程序而不是从 SO 调用一些函数时，一切正常，但反之亦然，给出了 SIGSEGV。 （注意：SO 是在运行时加载的，这一切都发生在一个线程中）
【解决方案2】：

这是我的建议。

  1. 关闭优化。有时优化会导致错误。以 -O0 为例。
  2. 删除动态加载，尝试静态链接代码，看看问题是否仍然存在。
  3. 减少问题的大小。制作可以重现错误的最小程序，然后在此处发布。

谢谢， 迈克

【讨论】：

  • 有时优化会导致错误不太可能。优化更有可能在您的代码中暴露未定义的行为。
猜你喜欢
  • 2014-11-11
  • 2021-09-18
  • 1970-01-01
  • 2014-07-31
  • 1970-01-01
  • 2012-03-26
  • 2019-03-01
  • 1970-01-01
相关资源
最近更新 更多
热门标签
Java Python linux javascript Mysql C# Docker 算法 前端 SpringBoot Redis Vue spring 设计模式 .net core .net kubernetes c++ 数据库 数据结构 大数据 js 机器学习 微服务 Android Go 程序员 面试 JVM ASP.net core 云原生 人工智能 后端 PHP git CSS golang k8s Nginx Django mybatis 深度学习 多线程 React 架构 devops 爬虫 云计算 Spring Boot LeetCode