一个粘贴bug的方法 [英] Ways to corner a stickiness bug

问题描述

如果确定一块软件在停留时正在做什么，对用户输入无响应，而不更新其显示？

我已经尝试过oprofile，它记录了什么功能正在执行，但它没有给我足够的线索。它计算在运行期间发生的所有事情，当我需要看到只有当标本程序被卡住时才发生什么。

该问题可能涉及中断，等待网络套接字，定时器，GUI事件处理程序或谁知道什么。如何尽可能多地了解发生了什么，而不仅仅是每个线程的执行点？

感兴趣的软件在Linux上运行，使用gcc构建，大部分C ++，但可能涉及其他语言，包括解释的语言，例如蟒蛇。

现在关注的特殊情况是Firefox，我已经检出了源代码。 Firefox每次都会随机地暂停所有输入和屏幕输出，频繁地约5-10秒。即使有人把这个特殊问题的解决方案交给了一个银盘，我肯定会拿这个问题，但仍然在问。如果可能，我想学习适用于任何软件的一般技术，特别是我负责的内容。

解决方案

可以获取运行程序的堆栈跟踪。在命令行中，使用ps aux来查找程序的PID。假设是12345.然后运行：

  gdb --- pid = 12345 
  / pre> 
 
 
当程序停留在暂停（或做任何可疑）时，请在gdb中执行ctrl-C。 gdb中的bt命令打印堆栈，现在可以欣赏或粘贴到文本文件中以备后续学习。使用c继续执行程序（继续）。
 
 
 
本手册技术与使用oprofile或其他剖析器的主要优点是可以获得确切的调用顺序在感兴趣的时刻。几个样本在麻烦的时候，几个程序正常运行时应该提供有用的线索。
 
How to determine exactly what a piece of software is doing when it is stuck, unresponsive to user input  and not updating its display?   

I have tried oprofile, which records what function is executing, but it's not giving me enough clues.   It counts everything that happens during the time it's running, when I need to see what's happening only when the specimen program is stuck.  

The problem might involve interrupts, waiting on network sockets, timers, a GUI event handler, or who knows what.  How to find out as much as possible about what's going on, not just the execution points of each thread?

The soffware of interest runs on Linux, built using gcc, mostly C++ but may involve other languages including interpreted ones e.g. Python. 

The particular case of concern now is Firefox, for which I have checked out source.  Firefox pauses all input and screen output at random times, frequently, for about 5-10 seconds each time.  Even if someone handed me the solution to this particular problem on a silver platter, sure I'll take it but still be asking.  If possible, I'd like to learn general techniques that would apply to any software, especially stuff I'm responsible for.
解决方案
A stack trace can be obtained of a running program.  At a command line, use "ps aux" to find the program's PID.  Suppose it's 12345.  Then run:
gdb ---pid=12345
When the program is stuck in a pause (or when doing anything suspicious), do a ctrl-C in gdb.  The "bt" command in gdb prints the stack, which can be admired now or pasted into a text file for later study.  Resume execution of the program with "c" (continue).

The main advantage of this manual technique over using oprofile or other profilers, is I can get the exact call sequence during a moment of interest.  A few samples during times of trouble, and a few when the program is running normally, should give useful clues.

                        
这篇关于一个粘贴bug的方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！