首页 > 应用开发 > IT综合 > DebuggingCoreFile(转)


原创 IT综合 作者:post0 时间:2007-08-24 17:12:55 0 删除 编辑

  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

来自 “ ITPUB博客 ” ,链接:,如需转载,请注明出处,否则将追究法律责任。

上一篇: PythonTips(转)
下一篇: 配置openvpn(转)
请登录后发表评论 登录
  • 博文量
  • 访问量