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

Jean-Marc Saffroy
2006-09-26T00:59:15Z

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.
:-)