linux-kernel - Re: oops in :snd_pcm_oss:resample

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0609260205290.4825@erda.mds>
Date:	Tue, 26 Sep 2006 02:59:43 +0200 (CEST)
From:	Jean-Marc Saffroy <saffroy@...il.com>
To:	Vivek Goyal <vgoyal@...ibm.com>
cc:	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
	Jaroslav Kysela <perex@...e.cz>, Takashi Iwai <tiwai@...e.de>,
	Dave Anderson <anderson@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: 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@...il.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/