DebuggingCoreFile

王朝other·作者佚名  2008-05-18
窄屏简体版  字體: |||超大  

How to debug a core file?

Usually you have two choices of debuggers: dbx or gdb

.dosu dbx application_that_produces_this_core core

.dosu gdb application_that_produces_this_core core

The command `strings core | head -2` will tell you what

application produces this core (line 1) including the full

path of the application (line 2).

Apparently that above command (strings core | head -2) only

works on Irix. On Linux, you need to do something else.

On Irix, you need to do

.dosu strings core | head -10

to get the name of the executable somewhere in the middle.

Within a debugger while dissecting a core file:

p (curr_pat)pdata

This will get you information about patid, envid, etc.

What about multi-threaded core files?

Here's the explanation of core files in multi threaded apps. This is

from an old FAQ, but I think it's still applicable:

G.2: Does it work with post-mortem debugging?

Not very well. Generally, the core file does not correspond to the

thread that crashed. The reason is that the kernel will not dump core

for a process that shares its memory with other processes, such as the

other threads of your program. So, the thread that crashes silently

disappears without generating a core file. Then, all other threads of

your program die on the same signal that killed the crashing thread.

(This is required behavior according to the POSIX standard.) The last

one that dies is no longer sharing its memory with anyone else, so the

kernel generates a core file for that thread. Unfortunately, that's not

the thread you are interested in.

G.3: Any other ways to debug multithreaded programs, then?

Assertions and printf() are your best friends. Try to debug sequential

parts in a single-threaded program first. Then, put printf() statements

all over the place to get execution traces. Also, check invariants often

with the assert() macro. In truth, there is no other effective way (save

for a full formal proof of your program) to track down concurrency bugs.

Debuggers are not really effective for subtle concurrency problems,

because they disrupt program execution too much.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
© 2005- 王朝網路 版權所有  導航