From owner-freebsd-hackers Mon Apr 12 15: 3:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 5F51F14CF8 for ; Mon, 12 Apr 1999 15:03:06 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.9.2/8.9.2) id RAA43380; Mon, 12 Apr 1999 17:00:45 -0500 (CDT) (envelope-from dan) Date: Mon, 12 Apr 1999 17:00:45 -0500 From: Dan Nelson To: "David E. Cross" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ypserv Message-ID: <19990412170045.B42830@dan.emsphone.com> References: <199904122143.RAA25814@cs.rpi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <199904122143.RAA25814@cs.rpi.edu>; from "David E. Cross" on Mon Apr 12 17:43:30 GMT 1999 X-OS: FreeBSD 3.1-STABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Apr 12), David E. Cross said: > > ypserv is compiled with debugging information, not stripped, and is > compiled statically. The reference that I am referring to is not in > a backtrace in GDB it is the result of "print *functionpointer", > where functionpointer is later used to call a function with arguments > that do not match that function. For example, I see the following in > the code: > > *(dbp->seq)(dbp, &ldata, &lkey, ...,...); > > I do "print dbp->seq" and I see "<__hash_open+14541>" (number made > up). If I then look at __hash_open, I see it takes char *filename, > ... (things I forget). So the parameters that are being passed > clearly do not match what the function is expecting, but I doubt it > is calling that function at all. Aah, but are you linking in a debugging libc? :) dbp->seq is function pointer into the Berkeley DB code in libc.a. The nearest user-visible function in the library is hash_open(), go that's what gdb printed. Try setting DEBUG_FLAGS=-g, then rebuild libc and relink your program. That should let you see into the DB functions. But if you're crashing there, chances are your problem is elsewhere. All dbp->seq() does is walk through a .db database one record at a time. I don't think there are any overflow problems assosicated with the functions themselves. -Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message