From owner-freebsd-hackers Thu Oct 8 18:54:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA19567 for freebsd-hackers-outgoing; Thu, 8 Oct 1998 18:54:54 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dt053nb4.san.rr.com (dt053nb4.san.rr.com [204.210.34.180]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA19514 for ; Thu, 8 Oct 1998 18:54:33 -0700 (PDT) (envelope-from Studded@gorean.org) Received: from gorean.org (Studded@localhost [127.0.0.1]) by dt053nb4.san.rr.com (8.8.8/8.8.8) with ESMTP id SAA00965; Thu, 8 Oct 1998 18:53:13 -0700 (PDT) (envelope-from Studded@gorean.org) Message-ID: <361D6C89.F76B1755@gorean.org> Date: Thu, 08 Oct 1998 18:53:13 -0700 From: Studded Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.5b2 [en] (X11; I; FreeBSD 2.2.7-STABLE-0929 i386) X-Accept-Language: en MIME-Version: 1.0 To: Mike Smith CC: Archie Cobbs , FreeBSD-Hackers@FreeBSD.ORG Subject: Re: mail in free(): warning: junk pointer, too high to make sense. References: <199810090046.RAA01827@dingo.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: > > > Mike Smith wrote: > > > > > It means that there are two instances of 'msgvec' with global scope, > > > and the other one needs to be found too. > > > > > > You could probably just change the 'msgvec' in lex.c to be static in > > > order to achieve that goal; then you need to work out which object(s) > > > are exporting 'msgvec' as globals. > > > > > > Any chance of you doing that? Have a look at the output of 'nm' on each > > > of the .o files, and see which (if any) export or reference _msgvec. > > > > ok, when I use the version of lex.c which has msgfoo declared static I > > get no _msgvec in any .o file. When I restore the original lex.c file, > > then declare msgvec static here is what I get: > > > > 55# for FILE in `ls -1 *.o`; do echo $FILE; nm *.o | grep _msgvec | > > \more; done > > aux.o > > 00001354 b _msgvec > > > > and identical output for the following files: > > That's because there's a bug in your command; you should be passing > $FILE to nm, not "*.o" Well don't I fell silly. I swapped too many things around. With the stock sources: 105# for FILE in `ls -1 *.o`; do echo $FILE; nm $FILE | grep _msgvec; done lex.o 00000004 C _msgvec With msgvec declared static in lex.c: lex.o 00001354 b _msgvec > > However, looking at the files where msgvec is used, the only place it's > > declared globally is lex.c. When I tested the binary compiled with the > > static declaration in lex.c using gdb + AJ -> malloc.conf it didn't > > core, and there were no error messages. So perhaps making it static in > > lex.c is the answer after all? > > I'm still wondering how it gets corrupted. Making it static will have > the effect of moving it around. The fact that it was corrupted with > something that looks very much like ASCII has me wondering whether > there's not a buffer overflow going on. > > Can you try 'nm mail | sort | more' and look at the symbols directly > before msgvec? I'd be inclined to suspect that there's a fixed-size > character buffer there that's just not big enough for something on your > system. Well, I do have 16 character usernames on my 2.2.7 system, and my normal user is a 16 char name. However the sources for mail are the same in -Stable and -Current, so I don't think it's a -Stable problem. However, when I log in as a user with a 5 character username, I don't get the warning with stock sources so it definitely sounds like a buffer overflow. With stock sources: 00015ae0 B _tempQuit 00015af8 B _string_stack 00015b00 B _lexstring 00015f00 D __CurrentRuneLocale 00015f04 B _loading 00015f08 B _wait_status 00015f0c B _tempMesg 00015f24 B _srbuf 00015f48 B _tempMail 00015f60 B _hdrjmp 00015f84 B _groups 00016070 B _tempEdit 00016088 D __DefaultRuneLocale 00016cdc B _message 00016ce0 D ___sF 00016de8 B _lexnumber 00016dec B _prevfile 000171ec B _lastbang 0001726c B _environ 00017270 B _regretstack 00017278 B _ignore 00017458 B _tempResid 00017470 B _rcvmode 00017474 B _image 00017478 B _msgvec The culprit would seem to be one or more of: char tempMail[24]; char tempQuit[24]; char tempEdit[24]; char tempResid[24]; char tempMesg[24]; from temp.c, however in my testing I couldn't figure out which one. Also, to make matters more exciting I have TMPDIR set to /home/my16charusername/.temporary_dir. The TMPDIR variable is referenced in the same part of the code in temp.c. Hoping we're narrowing this down, Doug -- *** Chief Operations Officer, DALnet IRC network *** Go PADRES! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message