我们将软件的构建版本发送给客户,客户在数据上运行代码,由于数据隐私,他们无法共享数据。因此,我们通常不能调试导致错误(表现为超时、异常和崩溃)的数据。相反,当错误发生时,我会得到一个异常地址,然后需要将其Map到代码位置。我们目前使用MSVC来编译C代码部分,但是MSVC不再允许创建Map文件,在该Map文件中我可以找到产生错误(How can I create a map file with line numbers in Visual C++ 2005?)的源代码行。是否有任何C编译器(适用于Windows、x86和x64)可以配置为生成具有准确行号的Map文件?
另外,我正在寻找Boost.stacktrace的解决方案,但我们遇到的另一个场景是,由于另一个线程超时,必须停止一个线程。我不确定我可以在Boost中为其他线程获取堆栈跟踪...
我尝试的第三件事是保留两个变量lastFile和lastLineNo,它们是使用__FILE__
和__LINE__
定义的。在代码中散布着对
#define SET_OP lastFile = __FILE__; lastLineNo = __LINE__;
字符串
这种方法的问题是,在DLL中引入了lastFile和lastLineNo,但它们当然应该是线程本地的(延迟加载的DLL不能很好地处理线程本地存储)。Thread有线程本地存储,但是我找不到在超时的情况下从另一个线程获取这些变量的方法。对SET_OP的许多调用都是在需要高性能的函数中进行的,所以我有点不好意思处理需要互斥锁的复杂事情。
我有一种感觉,我正在推动多线程场景中堆栈跟踪的可能性,但这是一个非常真实的的问题,已经让我头痛了几个星期,如果不是几个月的话。
2条答案
按热度按时间tzcvj98z1#
比起将单个地址转换为源代码位置的方法,我更喜欢能够生成完整堆栈跟踪的方法。我无法解决boost.stacktrace不能为其他线程中的无限循环生成堆栈跟踪的问题。虽然可以使用boost.stacktrace抛出带有堆栈跟踪的异常,但在很多情况下堆栈跟踪不可用。希望std::backtrace能让堆栈跟踪对所有异常都可用。在此之前,我选择遵循插装源代码的方法。它也不是完美的,因为我们的代码库太大,无法完全插装,而且第三方库也不支持这种插装。所以我想到了这个:
字符串
这将产生输出:
型
评论仍然非常受欢迎。
8xiog9wr2#
我知道这是一个已回答的问题,但我只想补充一下
https://github.com/JochenKalmbach/StackWalker
可能会有帮助。