From owner-freebsd-hackers  Thu Dec  2 19:33: 1 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226])
	by hub.freebsd.org (Postfix) with ESMTP id 4313014BC8
	for <freebsd-hackers@freebsd.org>; Thu,  2 Dec 1999 19:32:57 -0800 (PST)
	(envelope-from dgilbert@trooper.velocet.net)
Received: (from dgilbert@localhost)
	by trooper.velocet.net (8.9.3/8.9.3) id WAA66379;
	Thu, 2 Dec 1999 22:32:44 -0500 (EST)
	(envelope-from dgilbert)
From: David Gilbert <dgilbert@velocet.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14407.14812.812358.220983@trooper.velocet.net>
Date: Thu, 2 Dec 1999 22:32:44 -0500 (EST)
To: freebsd-hackers@freebsd.org
Subject: Inverting a gdb -k mapping?
X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs  Lucid
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

I can grep through the vmcore.x file and find the offset of the string 
I put on the stack by

strings -t x <vmcore.9 | grep dgilbert_

... but how do I associate that back with an address inside gdb -k?

My problem is that vinum (or something related to it) is trashing the
stack and trying to return to 0x0 is panic'ing the kernel (of course).

... now... bt in gdb -k on this shows the series of trap calls and
ends with frame 5 as:

#5  0x0 in ?? ()

Which is not helpful.  My first plan of attack here is to add large
string variables to the stack by

foo()
{
   char top[]="dgilbert_raid5_top";
   /* other variables */
   char bot[]="dgilbert_raid5_bot";

   /* rest of function */
}

... in the vague hope that the stack corruption os limited in scope
and that I can find the remanents of the stack by virtue of the fact
that these functions are still hanging around on the stack somewhere
with my strings.

... indeed, this bug rears it's head at a slightly different point in
the experiment with these changes, which is encouraging (I have also
installed functions at each exit point to check the stack variables
for corruption --- I'm tempted to keep growing their size, but I also
suspect that the corruption could be in the function's arguments which 
are closer to the return address).

At any rate... I'm keen to track this down, but I need some advice
on either how to relate vmcore.x file offsets with addresses in gdb
_or_ another way of attacking this problem.

Dave.

-- 
============================================================================
|David Gilbert, Velocet Communications.       | Two things can only be     |
|Mail:       dgilbert@velocet.net             |  equal if and only if they |
|http://www.velocet.net/~dgilbert             |   are precisely opposite.  |
=========================================================GLO================


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message