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

[Jean-Marc Saffroy <saffroy@gmail.com>]

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@gmail.com