randy@uokmax.UUCP (Longshot) (06/29/89)
Conquer v4 is core-dumping rather nastily when making a new world (conqrun -m). Anyone else gotten this, and fixed it? Randy -- Randy J. Ray University of Oklahoma, Norman, Oklahoma (405)/325-5370 !texsun!uokmax!randy randy@uokmax.uucp randy@uokmax.ecn.uoknor.edu Philosophy is written in this book - I mean universe - which stands continually open to our gaze... -Galileo
adb@bu-cs.BU.EDU (Adam Bryant) (06/29/89)
In article <3448@uokmax.UUCP> randy@uokmax.UUCP (Longshot) writes: > Conquer v4 is core-dumping rather nastily when making a new world > (conqrun -m). Anyone else gotten this, and fixed it? > > Randy I think the makeworld actually completes properly before the dump. So the data file should be valid, and continuing on from there should work. If this is not the case, please let me know. I believe the dump is being caused by the isonfile variable being changed somewhere within the makeworld() function. I have not traced the cause of this yet [probably some memory overwrite within the makeworld() routine]. The patch below should avoid the dump altogether. adam ps. This is not an official patch, just a little one to avoid the dump for now... *** oadmin.c Wed Jun 28 19:32:04 1989 --- admin.c Sun Jun 18 18:11:41 1989 *************** *** 122,130 **** exit(FAIL); } if((mflag)||(rflag)) { - makeworld(rflag); sprintf(string,"%sup",isonfile); unlink(string); exit(SUCCESS); } --- 122,130 ---- exit(FAIL); } if((mflag)||(rflag)) { sprintf(string,"%sup",isonfile); unlink(string); + makeworld(rflag); exit(SUCCESS); }
joel@dtscp1.UUCP (Joel Rives) (06/29/89)
In article <3448@uokmax.UUCP> randy@uokmax.UUCP (Longshot) writes: >Conquer v4 is core-dumping rather nastily when making a new world (conqrun -m). >Anyone else gotten this, and fixed it? Yes, i have seen this problem also. The following is a copy of the stack trace from dbx: verify_ntn(__file__ = 0x61cbe "makeworl.c", __line__ = 128), line 53 in "check.c" verifydata(__file__ = 0x61cbe "makeworl.c", __line__ = 128), line 133 in "check.c" makeworld(rflag = 0), line 128 in "makeworl.c" main(argc = bad data address Note, the bad address for argc in the last line. It looks as if something is tromping all over the data address space. The following is the source line and variable information at the spot in verify_ntn() where 'conqrun' dies: Source line where execution halts: if( sct[a->xloc][a->yloc].altitude==PEAK ) Value of the variable "a" at time of halt: *`check`verify_ntn`a = { unittyp = 3 xloc = '"' yloc = '&' smove = '\0' sold = 187 stat = '^C' } However, although subsequent runs always die at the same line, the values for the "xloc" and "yloc" fields in the structure pointed to by the variable "a" vary from run to run. I really don't have time to track this down any further. Joel Rives
jonathan@cs.keele.ac.uk (Jonathan Knight) (06/30/89)
From article <3448@uokmax.UUCP>, by randy@uokmax.UUCP (Longshot):
> Conquer v4 is core-dumping rather nastily when making a new world (conqrun -m).
Nope. I did however fix 1 bug and a problem for Ultrix.
The newlogin.c program can't be run twice. On the second invocation
it complains about not being able to create a nation. Simple
fix: the loop which looks for a nation that isn't in use uses the
test (ntn[i].active == INACTIVE). I changed this to (!isntn(ntn[i].active).
Secondly in extcmds.c at line 111 the mega conditional is too long
for our little C compiler. I just had to split it in two.
Now for a new bug:
Conquer seems to forget some passwprds. If I add 3 people on
to the game at startup time, the first person can't get in to the
game. Also the password for 'god' doesn't work.
--
______ JANET :jonathan@uk.ac.keele.cs Jonathan Knight,
/ BITNET:jonathan%cs.kl.ac.uk@ukacrl Department of Computer Science
/ _ __ other :jonathan@cs.keele.ac.uk University of Keele, Keele,
(_/ (_) / / UUCP :...!ukc!kl-cs!jonathan Staffordshire. ST5 5BG. U.K.bernd@pfm.UUCP (Bernd Hennig) (06/30/89)
randy@uokmax.UUCP (Longshot) writes: >Conquer v4 is core-dumping rather nastily when making a new world (conqrun -m). >Anyone else gotten this, and fixed it No but we have the same problem on 3 machines (2 Microport 386 3.0 and 1 Microport 286 2.4 !) ? -- __ / ) / uucp: uunet!mcvax!unido!pfm!bernd /--< _ __ ____ __/ PFM: *49 711 3700978 300/1200/2400 Bd 24h /___/_</_/ (_/ / <_(_/_ *49 711 3701830 1200-19200 Bd (PEP) 20-08h
phil@killer.DALLAS.TX.US (Phil Meyer) (06/30/89)
invocation! Much to the dismay of my employers... Otherwise everything looks good. B-)
perry@key.COM (Perry The Cynic) (06/30/89)
In article <3448@uokmax.UUCP> randy@uokmax.UUCP (Longshot) writes: >Conquer v4 is core-dumping rather nastily when making a new world (conqrun -m). >Anyone else gotten this, and fixed it? Check out newworl.c, the declaration of newstring[40]. The [40] is grievously too small, causing a sprintf to it to overflow and spill dirt onto the stack. Upon return, this garbles the frame pointer, and things get extremely random from then on. Make newstring larger (1000 should do), and THIS bug goes away. Stupid, really; how could this ever work? -- perry -- ------------------------------------------------------------------------ Perry The Cynic (Peter Kiehtreiber) perry@arkon.key.com ** What good signature isn't taken yet? ** ...!pacbell!key!perry
adb@bu-cs.BU.EDU (Adam Bryant) (06/30/89)
Okay, I have already received a number of bug fixes
and have done a little work on my own. Since the memory
overwriting bug seems to be a stickler [caused by too
small of an array size for a general use string], I will
be posting a patch either tomorrow evening [Friday] or
Saturday.
(of course, even as I write this it becomes tomorrow..)
adam
Things done:
newlogin() bugs gone over.
the above string increased in size and variable other
little changes.
Might also release a new makefile.
--
Adam Bryant || ARPANET: adb@bu-it.bu.edu
40 Chester Street Apt. 9 || BITNET: adb@buenga
Allston, MA 02134 || UUCP: ..!harvard!bu-cs!bucsf!adb
(617) 353-9249 || CSNET: adb%bucsf@bu-ittpo@dde.dk (Thomas Peter Sonne Olesen) (06/30/89)
randy@uokmax.UUCP (Longshot) writes: >Conquer v4 is core-dumping rather nastily when making a new world (conqrun -m). >Anyone else gotten this, and fixed it? Yes, I traced it down to be a stack error, and it disapeared when I changed the size of the newstring[40] in routine makeworld in module makeworl.c to newstring[80]. Or in patch format: *** makeworl.c.ori --- makeworl.c ************** *** 45,51 int rflag; /* TRUE if you wish to read in a map from mapfiles */ { char passwd[PASSLTH+1],*getpass(); ! char newstring[40]; FILE *fopen(); /*abort if datafile currently exists*/ --- 45,51 ----- int rflag; /* TRUE if you wish to read in a map from mapfiles */ { char passwd[PASSLTH+1],*getpass(); ! char newstring[80]; FILE *fopen(); /*abort if datafile currently exists*/ /Thomas -- ***************************************************************************** Thomas P.S. Olesen Dansk Data Elektronik A/S E-mail: ..!uunet!mcvax!dkuug!dde!tpo System Software Department or tpo@dde.dk
rjc@aipna.ed.ac.uk (Richard Caley) (06/30/89)
In article <645@kl-cs.UUCP> jonathan@cs.keele.ac.uk (Jonathan Knight) writes: > Conquer seems to forget some passwprds. If I add 3 people on >to the game at startup time, the first person can't get in to the >game. Also the password for 'god' doesn't work. Appending an 'n' works for me. I.e. if your god-password was 'fred' then use 'fredn'. No, I have no idea. I found this oput by running dbx on the thing, something is stepping on the end of the god-password in makeworld(). -- rjc@uk.ac.ed.aipna Vote Monster Raving Loonie Party --
joel@dtscp1.UUCP (Joel Rives) (06/30/89)
In article <905@key.COM> perry@arkon.key.COM (Perry The Cynic) writes: > >Check out newworl.c, the declaration of newstring[40]. The [40] is grievously >too small, causing a sprintf to it to overflow and spill dirt onto the stack. >Upon return, this garbles the frame pointer, and things get extremely random >from then on. > >Make newstring larger (1000 should do), and THIS bug goes away. Stupid, really; >how could this ever work? > -- perry Yo perry! Is this a joke or what? I mean, here you go spouting off about the stupidity of someone elses coding -- all the while, making reference to a source file in this persons distribution that doesn't even exist. Are we suppose to believe you did this ON PURPOSE :-) Pretty funny, if you ask me! Joel
akobayas@cvbnet2.UUCP (Andrew Kobayashi) (07/06/89)
From article <3448@uokmax.UUCP>, by randy@uokmax.UUCP (Longshot): > Conquer v4 is core-dumping rather nastily when making a new world (conqrun -m). > Anyone else gotten this, and fixed it? > > Randy I bumped the size of the char array "newstring" in routine makeworld() (in makeworl.c) to 256 from whatever it was (40 i think). I was storing things in my home directory which has a long path that didn't fit. Anyway, when i bumped the size the problem went away. --Andrew Kobayashi <@en-c06.prime.com:akobayas@spica2>
seebachp@thor.acc.stolaf.edu (--SeebS--) (07/09/89)
The following showed up in my mailbox - BITNET has a hard time with posting, or so it seems... Don't reply to me, reply to him... From GA7779%SIUCVMB.BITNET@BUACCA.BU.EDU Sat Jul 8 13:21:55 1989 Received: from BU-CS.BU.EDU by thor.acc.stolaf.edu; Sat, 8 Jul 89 13:21:45 -0500 Received: from BUACCA.BU.EDU by bu-cs.BU.EDU (5.58/4.7) id AA19933; Sat, 8 Jul 89 14:11:53 EDT Message-Id: <8907081811.AA19933@bu-cs.BU.EDU> Received: from SIUCVMB.BITNET by buacca.bu.edu (Mailer X1.25) with BSMTP id 4060; Sat, 08 Jul 89 14:14:32 EDT Received: by SIUCVMB (Mailer X1.25) id 4431; Sat, 08 Jul 89 13:12:03 CST Date: Sat, 08 Jul 89 13:08:27 CDT From: GA7779%SIUCVMB@buacca.BU.EDU To: conquer-news@bu-cs.bu.edu Subject: Conquer 4.0 on uport V2.4 286 Status: RO Anybody out there been able to get conquer to compile using uPort SysV Release 2.4 on a 286? I feed it in and end up with a segment overflow - get help message in npc.c (unless I uncomment, rather undefine NPC) also in misc.c. Did my incoming mail get bombed to the point that I can't recognize the problem or is there a problem? Any help truly appreciated. I like to try out this game. Dan Ellison Molecular Science Program SIU-C BITNET Bound: GA7779@SIUCVMB --SeebS--