[Crash-utility] Degradation with crash 5.0.0 on x86 -- [PATCH]

[Dave Anderson]

----- "Dave Anderson" <anderson at redhat.com> wrote:

> ----- "Shahar Luxenberg" <shahar at checkpoint.com> wrote:
> 
> > Hi,
> > 
> > 
> > 
> > Environment: Red Hat Enterprise Linux Server release 5.2 (Tikanga),
> > x86, 2.6.18-92.el5
> > 
> > I’ve installed crash 5.0.0 and noticed lots of error messages during
> > startup of the form:
> > 
> > ‘crash: input string too large: "804328c4:" (9 vs 8)’
> > 
> > This doesn’t happen with crash 4.1.2
> > 
> > 
> > 
> > While debugging it a little, I’ve noticed that BUG_x86 is calling gdb
> > with the x/i command:
> > 
> > sprintf(buf1, "x/%ldi 0x%lx", spn->value - sp->value, sp->value);
> > 
> > The return buffer (buf2) is: 0x80430800: push %ebp
> > 
> > On 4.1.2, the return buffer (buf2) is: 0x80430800 <do_exit>: push %ebp
> > 
> > This explains the problem since parse_line will parse the line
> > differently returning ‘0x80430800:’ on arglist[0] and nothing on
> > arglist[2] (crash 5.0.0) while returning 0x80430800 on arglist[0] and
> > ‘push’ on arglist[2].
> > 
> > Have you noticed this kind of problem?
> 
> I see it now, at least on 2.6.18-era kernels.  It doesn't seem to happen
> with earlier RHEL4 (2.6.9-era) vmlinux files for some reason.  And on anything
> later than 2.6.20, the code in question isn't run.  Anyway, as you tracked
> it down, the x86 code disassembly output is different, but should be trivial
> to fix.  
> 
> Thanks for the report,
>   Dave

Patch attached, and queued for the next release.

Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel.c.patch
Type: text/x-patch
Size: 619 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20100111/00c40c66/attachment.bin>