Re: oops in :snd_pcm_oss:resample_expand+0x19c/0x1f0

On Mon, 25 Sep 2006, Vivek Goyal wrote:

One thing I like *very much* in gdb is its ability to display function
params and local variables in any stack frame, and I haven't found out how
to do it with crash.

Agreed. AFAIK, crash does not display the function params and local
variables. gdb has got this advantage, though last time I looked
at local variables dispalyed by gdb, they seemed to be junk. Not very
sure why it was so?

Most probably this is due to compiler optimizations, eg. the register is reused for another purpose. Recently I was pleased to discover that gdb 6.5 is smart enough to tell the user that a variable has been optimized out (certainly with help from debug info produced by gcc).

I agree that gdb is sometimes very slow, but maybe it's easier to optimize gdb than to make crash smarter?

I beg to differ here. Not sure why it is easier to optimize gdb. If we try to optimize gdb by writing scripts, then IMHO, writing C program is easier and faster. If the idea is to optimize gdb by modifying gdb code then its no different than crash. In fact, why to reinvent the wheel if crash already does so many things for us. Yes, but probably we need to modify crash to be able to obtain function parameters and local variables.

Oh I only meant that *maybe* gdb deserved some optimizations that would be suitable for general use, but this is pure speculation. I agree that a custom modified gdb is in a way akin to crash.

For this particular problem (listing threads), the real fix would be to add the PT_NOTE entry that each thread deserves, then gdb would let you do "info threads" instead, and dump nice backtraces of each.

Displaying even the currently non executing threads using "info threads" and their backtraces is interesting. Crash can already do that. I am apprehensive about traversing through the task list and dumping every thread's register state after a crash. There is no gurantee that list is in a sane state. And in general, we are trying to make crash handler as small as possible to improve the reliability of dumping operation.

Register state of every non-executing thread is already present in the
vmcore and IMHO, we should write scripts to get info about other
threads then doing it in kernel.

This is exactly what I had in mind, for the very reasons you mentioned. :-)


--
saffroy@xxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: segmentation fault at the end of script
    ... >This script is launch by a script shell on an linux machine like this: ... Have you tried examining the core dump with gdb to give ... using a program that'll deliberately crash: ...
    (comp.lang.php)
  • Re: Xorg crashes FreeBSD 6.4
    ... serving as console machines with X and kde. ... the current xorg port, since on the other machine an older xorg works ... I am also seeing a repeatable crash inside libdrm after my last xorg ... but still working on catching the actual crash in gdb. ...
    (comp.unix.bsd.freebsd.misc)
  • Re: oops in :snd_pcm_oss:resample_expand+0x19c/0x1f0
    ... Currently we can use gdb but only for linearly mapped region. ... I mean kernel crash handler. ... we can write gdb scripts to implement ... Displaying even the currently non executing threads using "info threads" ...
    (Linux-Kernel)
  • Re: [PATCH][GIT PULL] tracing/wakeup: move access to wakeup_cpu into spinlock
    ... unable to handle kernel NULL pointer dereference at 0000000000000008 ... Some info from the dump using gdb & crash-utility. ... Hence, we crash. ... crash> sym ffffffff806f8264 ...
    (Linux-Kernel)
  • Re: Open-source CableServer for Impact on sourceforge.net
    ... If server stops, Impact GUI will ... To avoid this you must disconnect server from GUI using ... crash of cblsrc: ...
    (comp.arch.fpga)