From owner-freebsd-ports Sun Nov 26 15: 7:34 2000 Delivered-To: freebsd-ports@freebsd.org Received: from mikehan.com (giles.mikehan.com [63.201.69.194]) by hub.freebsd.org (Postfix) with ESMTP id 608FB37B479 for ; Sun, 26 Nov 2000 15:07:30 -0800 (PST) Received: (from mikehan@localhost) by mikehan.com (8.11.1/8.9.3) id eAQMb8W15523; Sun, 26 Nov 2000 14:37:08 -0800 (PST) (envelope-from mikehan) Date: Sun, 26 Nov 2000 14:37:08 -0800 From: Michael Han To: Terry Dwyer Cc: ports@freebsd.org Subject: Re: Internet Movie Database (ports/misc/moviedb dumps core during title display Message-ID: <20001126143708.E8913@giles.mikehan.com> References: <3A120602.9F2124BB@bigpond.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A120602.9F2124BB@bigpond.com>; from tdwyer@bigpond.com on Wed, Nov 15, 2000 at 11:41:54AM +0800 Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In my quest to fix the problem I've been having, I discovered this email, which I've snipped many pieces of. On Wed, Nov 15, 2000 at 11:41:54AM +0800, Terry Dwyer wrote: > > I thought I'd post the problem here with what I know about it > in the hope that someone else can tell me that it must be a > problem with my system (and how to fix it) or confirm it is a > real bug. I think so since I've been having the same problem. > Since a search of the mailing lists produces nothing but > unassigned bug reports containg my problem report and a > record of the conversations between the submitter and the > committer, I gather that no one has actually installed > the port but me 8-(. I've never installed the port (I just discovered it existed), but I'm running 3.14 locally, with munged paths similar to the ports layout. > > Program received signal SIGSEGV, Segmentation fault. > 0x280d79bc in strcmp () from /usr/lib/libc.so.4 > (gdb) bt > #0 0x280d79bc in strcmp () from /usr/lib/libc.so.4 > #1 0x8052118 in titleResultSort (e1=0x805a6a4, e2=0x805a5f0) at > display.c:903 > #2 0x280d68c3 in qsort () from /usr/lib/libc.so.4 > #3 0x80521dc in displayFilmographyListData (trec=0x805a000) at > display.c:933 > #4 0x8052b06 in displayTitleSearchRec (trec=0x805a000, tidy=1) at > display.c:1219 > #5 0x8052be6 in displayTitleSearchResults (tchain=0x805a000, > tidy=1) at display.c:1250 > ----------------------------------------------------------------- > > Can anyone help with this as I have now reached the limit of > my debugging skills. Well, using truss revealed that title begins returning errors like: open("/usr/local/share/imdb/names.index",0,0666) = 4 (0x4) open("/usr/local/share/imdb/names.key",0,0666) = 5 (0x5) fstat(4,0xbfbfee50) = 0 (0x0) lseek(4,0x0,1) = 0 (0x0) lseek(4,0x6e6000,0) = 7233536 (0x6e6000) read(0x4,0x805a000,0x2000) = 0 (0x0) lseek(4,0x6e6250,0) = 7234128 (0x6e6250) read(0x4,0x805a000,0x2000) = 0 (0x0) fstat(5,0xbfbfee50) = 0 (0x0) lseek(5,0x0,1) = 0 (0x0) lseek(5,0xffffffffffffe000,0) = -8192 (0xffffe000) read(0x5,0x805c000,0x2000) ERR#27 'File too large' lseek(5,0xffffffffffffffff,0) = -1 (0xffffffff) I'm assuming this accounts for the trec.entries array of structs getting clogged up with crap, as seen below: ..., {nameKey = 2462344, attrKey = 44108, name = 0x0, attr = 0x808f440 "(production assistant)", cname = 0x0, position = 255, lineOrder = 255, groupOrder = 255, subgroupOrder = 255}, { nameKey = 4294967295, attrKey = 16777215, name = 0x0, attr = 0x0, cname = 0x0, position = 0, lineOrder = 0, groupOrder = 0, subgroupOrder = 0} }, ... ^!!!!!!!!!!!!!!!!!!^ This is a snippet from gdb, 'print *trec'. When the title(1) proceeds to attempt to sort the trec.entries for display, it finds itself dealing with garbage data and proceeds to segfault. The seek errors appear to surface during: char *mapNameKeyToText ( NameID nameKey, FILE *nameKeyFp, FILE *nameIndexFp ) { char line [ MXLINELEN ] ; long offset ; (void) fseek ( nameIndexFp, 4 * nameKey, SEEK_SET ) ; offset = getFullOffset ( nameIndexFp ) ; (void) fseek ( nameKeyFp, offset, SEEK_SET ) ; (void) fgets ( line, MXLINELEN, nameKeyFp ) ; return ( duplicateField ( line ) ) ; } which begins at line 1044 in src/dbutils.c in the 3.14 sources. The getFullOffset function is at line 400 of same and looks like: long getFullOffset (FILE *stream) { long offset ; offset = fgetc ( stream ) & 255 ; offset |= fgetc ( stream ) << 8 ; offset |= fgetc ( stream ) << 16 ; offset |= fgetc ( stream ) << 24 ; return ( offset ) ; } Anyone got a clue what's going on here? I don't really understand things well enough to figure out where the problem lies... The bitwise math in getFullOffset() looks suspicious to me though. -- mikehan@mikehan.com http://www.mikehan.com/ coffee achiever San Francisco, California "I am not a number; I am a free man!" - Number Six To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message