RE: Ooops

Joseph Gooch (mrwizard@psu.edu)
Tue, 16 Mar 1999 22:04:02 -0500

That makes sense. I'm just thinking if it's actual code, and being executed
it should probably be part of a function. Then again, the stack includes
parameters, they're probably that. Okay brain fart.

My next question is, how big can the arp table be in 2.2? I can't find an
arpd for it.

fetcho(root):/usr/src# arp -a |wc
229 1607 12288
Segmentation fault

I have a few entries. :)

I'm not on the list guys so do as he did and CC: me please.

Thanks,
Joe Gooch

> -----Original Message-----
> From: Keith Owens [mailto:kaos@ocs.com.au]
> Sent: Tuesday, March 16, 1999 6:33 PM
> To: Joseph Gooch
> Cc: linux-kernel@vger.rutgers.edu
> Subject: Re: Ooops
>
>
> On Tue, 16 Mar 1999 02:43:18 -0500,
> "Joseph Gooch" <mrwizard@psu.edu> wrote:
> >It's actually kind of
> >interesting that timer_bug_msg is referenced in the trace
> since that's a
> >const char [] definition in net/ipv4/tcp_timer.c. One would
> think that
> >wouldn't be an executable area. And also in my System.map :
> >
> >c01de1c0 r rta_max
> >c01de2e5 r prio2band
> >c01e0200 R timer_bug_msg
> >c01e13b0 r msstab
> >c01e1cc0 R ide_pio_timings
> >c01e1f83 r ide_hwif_to_major
> >
> >It's a much bigger area than the 86 bytes allocated to it in
> the .o file.
>
> Both the kernel and ksymoops have to guess at what *might* be a return
> address when dumping the stack. The kernel prints any addresses that
> even look as if they fall within kernel or module space. ksymoops
> takes those addresses and finds the nearest external symbol.
>
> If you browse vmlinux and look for the text of timer_bug_msg, you will
> find it in read only storage. Either side of timer_bug_msg are a lot
> more text strings but, because these strings come from printk formats
> and string assignments, they are not declared as external symbols.
> Therefore there are gaps in the System.map, as you found above.
>
> It is left for a sensible human to decide if the stack trace and
> mapping to external symbols is sensible. IMHO it is better for the
> kernel and ksymoops to provide as much info as possible, even if some
> of it might be a little misleading.
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/