[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ksymoops-2.4.9 and binutils-2.14 produce a crash

From: Stuart MacDonald
Subject: ksymoops-2.4.9 and binutils-2.14 produce a crash
Date: Tue, 10 Feb 2004 11:03:23 -0500

If I've sent this to the wrong place, please point me at the right

I'm not sure which program is at fault. Here's my situation:

I'm building a cross-system ksymoops for debugging oops from a new
board we're making. My development box is a RedHat 7.2 install. The
new board is Motorola Coldfire 5272 based, running
uClinux-dist-2002-0927 and built with the corresponding
Tool chain:

The ksymoops that is native to RH 7.2 handles only i86 code. So I
downloaded and built binutils and ksymoops by hand.

binutils was made with:
# configure --enable-targets=all
# make
# mkdir lib
# cd lib
# for i in ../*/*.a; do
> ln -s $i `basename $i`
> done

The extra step with the lib directory is to make it easy for ksymoops
to compile.

ksymoops was made with some changes to the makefile, and later some
debugging (patch attached), and:
# make

Running ksymoops (script attached) on my oops produced a segfault:
# ./dooops oops.1
/dooops: line 15: 24993 Segmentation fault
/root/ksymoops/ksymoops-2.4.9/ksymoops -v /usr/src/uClinux/linux-2.4.x/linux -K
-L -O -m /usr/src/uClinux/linux-2.4.x/System.map -t elf32-m68k -a m68k $1

I turned on ksymoops' internal debugging, and then added some of my
own. I tried to turn on libbfd's internal debugging, but it's
apparently not used by the developers as it caused massive compile
failures. So I hacked in a little extra debugging in ksymoops for the
bfd pointer checks.

(So really this is two bug reports: binutils-2.14 needs some cleanup
so that the DEBUG_BFD_SEND macro in bfd-in2.h compiles cleanly.)

The pointer checks look good, but...  I wasn't getting anywhere and
decided to try an older binutils, as the crash was definitely coming
from there. I compiled exactly as above, and now ksymoops
works. I left the debugging on...  ...and the pointer checks look
good. Comparing them against the bad output from before, it seems
obvious to me now that the message pointer is wrong (too short and in
the wrong area for a real pointer).

The question is, where does that bad pointer come from? This is where
I left the problem, as my immediate problem was solved.

I hope this helps. I'm willing to test patches, or do further
debugging. Also, I can re-post with inline patches/attachments; I
haven't right now because Outlook damages tabs.


Attachment: oops.1
Description: Binary data

Attachment: dooops
Description: Binary data

Attachment: patch-1-debug
Description: Binary data

Attachment: oops.1.decode.
Description: Binary data

Attachment: oops.1.decode.2.14
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]