如何在 C++ 中获取调试执行流程
我负责一个支持许多用户的全球交易系统。每个用户都可以预订、修改、编辑、删除交易。该系统由中央交易捕获服务监管。交易捕获服务会通知所有用户发生的任何更新。
当我们发生崩溃时，问题就出现了，因为生产环境不可能在测试系统上重新创建，我必须依赖崩溃转储和日志文件。
然而，这并没有告诉我用户一直在做什么。
我想要一个能够（在崩溃时）转储用户所做操作的历史记录的系统。我添加的任何内容都必须进入实时环境，因此不会对性能产生太大影响。
明智的想法是，我在每个函数的顶部考虑一个宏，它的作用类似于堆栈跟踪（只有我可以提供额外的用户信息，如交易 ID、用户对话框选择等。）系统将记录堆栈跟踪（在每个线程）并将历史记录保存在循环缓冲区中（大小不同，具体取决于您想要捕获的历史记录量）。然后在崩溃时，我可以转储这个历史堆栈。
我真的很想听听是否有人有更好的解决方案，或者是否有人知道现有的框架？
谢谢 富有的
I work on a global trading system which supports many users. Each user can book,amend,edit,delete trades. The system is regulated by a central deal capture service. The deal capture service informs all the user of any updates that occur.
The problem comes when we have crashes, as the production environment is impossible to re-create on a test system, I have to rely on crash dumps and log files.
However this doesn't tell me what the user has been doing.
I'd like a system that would (at the time of crashing) dump out a history of what the user has been doing. Anything that I add has to go into the live environment so it can't impact performance too much.
Ideas wise I was thinking of a MACRO at the top of each function which acted like a stack trace (only I could supply additional user information, like trade id's, user dialog choices, etc ..) The system would record stack traces (on a per thread basis) and keep a history in a cyclic buffer (varying in size, depending on how much history you wanted to capture). Then on crash, I could dump this history stack.
I'd really like to hear if anyone has a better solution, or if anyone knows of an existing framework?
Thanks
Rich
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您的解决方案听起来相当合理，但也许您可以触发它使用 atexit() 处理程序打印，而不是依赖于在调试器中查看审核跟踪。像一堆包含 __FILE__、__LINE__、pthread_self() 的字符串这样简单的东西可能就足够了
您可以使用一些现有的撤消框架，因为它类似于审计跟踪，但它会比您想要的更重量级。它可能基于命令模式并期望您实现execute() 方法，尽管我认为您可以将它们留空。
Your solution sounds pretty reasonable, though perhaps rather than relying on viewing your audit trail in the debugger you can trigger it being printed with atexit() handlers. Something as simple as a stack of strings that have __FILE__,__LINE__,pthread_self() in them migth be good enough
You could possibly use some existing undo framework, as its similar to an audit trail, but it's going to be more heavyweight than you want. It will likely be based on the command pattern and expect you to implement execute() methods, though I suppose you could just leave them blank.
交易系统通常不会受到该级别工具的性能影响。特别是基于 C++ 的系统，往往会为了性能而牺牲调试的简便性。否则，将会有更多的公司使用 Java/C# 开发此类系统。
我会避免尝试将堆栈跟踪引入 C++。我也不相信您可以以一种不会以某种方式影响程序行为（例如，影响线程行为）的方式引入这样的系统。
恕我直言，记录外部输入（例如，用户 GUI 操作和消息流量）可能比尝试捕获程序内部的内容更好。在这种情况下，您可能有更好的机会复制故障并进行调试。
您当前是否记录了进出客户端的所有网络流量？许多基于 FIX 的系统都会出于监管目的记录这一点。您可以轻松记录您的 I/O 吗？
Trading systems usually don't suffer the performance hit of instrumentation of that level. C++ based systems, in particular, tend to sacrifice the ease of debugging for performance. Otherwise, more companies would be developing such systems in Java/C#.
I would avoid an attempt to introduce stack traces into C++. I am also not confident that you could introduce such a system in a way that would not affect the behavior of the program in some way (e.g., affect threading behavior).
It might, IMHO, be preferable to log the external inputs (e.g., user GUI actions and message traffic) rather than attempt to capture things internally in the program. In that case, you might have a better chance of replicating the failure and debugging it.
Are you currently logging all network traffic to/from the client? Many FIX based systems record this for regulatory purposes. Can you easily log your I/O?
我建议创建另一个包含您的详细信息的（循环）日志文件。请注意，与其他文件相比，该文件将呈指数级增长。
另一种方法是保存最后 N 笔交易。编写一个程序来读取事务日志并将数据输入到您的虚拟应用程序中。这可能有助于创造原因。我以前曾在嵌入式系统中使用过这种技术。
I suggest creating another (circular) log file that contains your detailed information. Beware that this file will grow exponentially compared to other files.
Another method is to save the last N transactions. Write a program that reads the transaction log and feeds the data into your virtual application. This may help create the cause. I've used this technique with embedded systems before.