Date: Sun, 26 Nov 2000 14:37:08 -0800 From: Michael Han <mikehan@mikehan.com> To: Terry Dwyer <tdwyer@bigpond.com> Cc: ports@freebsd.org Subject: Re: Internet Movie Database (ports/misc/moviedb dumps core during title display Message-ID: <20001126143708.E8913@giles.mikehan.com> In-Reply-To: <3A120602.9F2124BB@bigpond.com>; from tdwyer@bigpond.com on Wed, Nov 15, 2000 at 11:41:54AM %2B0800 References: <3A120602.9F2124BB@bigpond.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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} <repeats 3975 times>}, ...
^!!!!!!!!!!!!!!!!!!^
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001126143708.E8913>