AIX 库调用以获取线程信息/状态
我可以在 AIX 上的 C++ 中使用任何 AIX 运行时库调用来监视与正在运行的进程关联的线程的状态吗?我正在尝试解决关闭时崩溃的问题,我认为该问题是由程序在所有线程加入之前退出引起的。
我很欣赏,在多线程环境中,准确记录线程的状态并不容易,因为它们很可能在读取状态和显示状态之间发生了变化,但任何东西 - 无论多么粗糙 - 作为第一步都是有用的追踪此事。
Are there any AIX runtime library calls that I can use in C++ on AIX to monitor the status of threads associated with the running process? I'm trying to resolve a crash-on-shutdown problem that I believe is being caused by the program exiting before all threads have joined.
I appreciate that in a multithreaded environment, it's not going to be easy to accurately log the status of the threads as they may well have changed between reading the status and displaying it, but anything - however crude - would be useful as a first step in tracking this down.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
你说“关机时崩溃”......你的意思是系统崩溃并带有故障转储吗?如果是这样,那么你就有大量数据。如果需要,我会使用大缓冲区启动系统跟踪。系统崩溃并重新启动后,您可以使用 trcdead 从转储中获取跟踪缓冲区,而且您还
可以了解系统的状态。
You said "crash-on-shutdown'... do you mean a system crash with a crash dump? If so, then you have tons and tons of data. If you need, I would start a system trace with a large buffer. After the system crash and reboot, you can suck the trace buffer from the dump using trcdead. Plus you have the state of the system.
It should not be that goofy threads cause a system crash.
首先,有一个系统跟踪工具。我没有在应用程序中多次使用它(任何?),但它是线程安全的。
http://pic.dhe.ibm.com/infocenter/aix/v6r1/topic/com.ibm.aix.genprogc/doc/genprogc/trace_facility.htm#yg3100thri
和
http://pic.dhe.ibm.com/infocenter/aix/v6r1/topic/com.ibm.aix.genprogc/doc/genprogc/tracing.ht m?结果=%22%61%70%70%6c%69%63%61%74%69%6f%6e%22%20%22%61%70%70%6c%69%63%22%20 %22%74%72%61%63%65%22%20
如果这是一个非常复杂的应用程序,我将连接真正的跟踪挂钩并开发一个跟踪格式文件。花时间是值得的。下面介绍的是一种比较粗暴的方法。
我可能追踪这个问题的方法是连接一个自制的跟踪或日志设施。在代码中,添加对日志例程的调用。然后返回并检查核心文件,挖掘日志缓冲区,这将告诉您所命中的日志点的顺序。
这可能是一个迭代过程,您添加几个点,然后找出代码的特定部分需要更多点,并在那里添加日志点。再试一次。重复。
日志例程实际上非常简单,并且利用了原子操作之一。我正在使用 fetch_and_add。
第一个参数的技巧是,当您获取核心文件并转储数组时,您可以将其转储为十六进制和文本。从文本输出中,您可以快速查看正在调用哪些日志点。如果您有 64 位应用程序,则可以使用 8 个字符,而不是限制为 4 个字符。
请注意,索引的值是核心文件中的关键。这会告诉您最后一个被命中的日志点。然后向后浏览日志数组以查看之前的日志点。
First, there is a system trace facility. I have not used it much (any?) from an application but it is thread safe.
http://pic.dhe.ibm.com/infocenter/aix/v6r1/topic/com.ibm.aix.genprogc/doc/genprogc/trace_facility.htm#yg3100thri
and
http://pic.dhe.ibm.com/infocenter/aix/v6r1/topic/com.ibm.aix.genprogc/doc/genprogc/tracing.htm?resultof=%22%61%70%70%6c%69%63%61%74%69%6f%6e%22%20%22%61%70%70%6c%69%63%22%20%22%74%72%61%63%65%22%20
If this is a very complex application, I would wire up real trace hooks and develop a trace format file. It will be worth the time spent. What follows below is a cruder method.
The way I would probably track this down is to wire up a home grown trace or log facility. In the code, sprinkle calls to the log routine. Then go back and examine the core file, dig out the log buffer, and that will tell you the sequence of log points that you hit.
This will likely be an iterative process where you add a few points, then figure out you need more points in a particular part of the code and add log points there. Try again. repeat.
The log routine is very simple actually and leverages one of the atomic ops. I'm using fetch_and_add.
The trick of the first argument is so that when you get your core file and dump out array, you can dump it out as hex and also as text. From the text output you can quickly see which log points are being called. If you have a 64 bit application, instead of limiting yourself to 4 characters, you get to use 8.
Note that the value of index is key in the core file. That tells you the last log point that was hit. Then step backwards through the log array to see the previous log points.