bob@rush.cts.com (Bob Ames) (08/03/89)
In article <211@comhex.UUCP> sysop@comhex.UUCP (Joe E. Powell) writes: >Has anyone else ever noticed that very large (over 300K) files >sometimes tend to core dump when they are invoked? They usually >work fine, but every now and again, the program will just refuse >to start up. Is it just me or have other people had this happen? > >I've noticed this occasionally on nethack and moria, but more >often with gcc (esp gcc 1.35). > >I'm running 3.51a, with a 40 MB drive and 2.5 MB of RAM. I don`t have gcc, but I have the same thing happen on moria. I have never seen nethack2.2 have a problem. On a slightly related subject, I`ve been trying, for about 1 YEAR, to get a version of nethack higher than 2.2. I`ve never seen kitchen sinks... Does *anybody* have a working 2.3x version that wouldn`t be too hard to the unix-pc? I can now FTP, I think, if provided exact instructions after the 'ftp site.name.xxf.fgr' command... Or I could call you... Or I could send disks with SASE... Or I could .... Or I could .... Also, What`s happened to killer? I finally got a DOS card for this beast and now can`t get to killer to get ibm-pc archives |-( Sorry for all these subjects, I only get unix-pc.all currently. Bob Ames Bob Ames The National Organization for the Reform of Marijuana Laws, NORML "Pot is the world's best source of complete protein, alcohol fuel, and paper, is the best fire de-erosion seed, and is america's largest cash crop." - USDA bob@rush.cts.com or ncr-sd!rush!bob@nosc.mil or rutgers!ucsd!ncr-sd!rush!bob 619-741-UN2X "We each pay a fabulous price for our visions of paradise," Rush
jcm@mtunb.ATT.COM (was-John McMillan) (08/03/89)
In article <211@comhex.UUCP> sysop@comhex.UUCP (Joe E. Powell) writes: >Has anyone else ever noticed that very large (over 300K) files >sometimes tend to core dump when they are invoked? They usually >work fine, but every now and again, the program will just refuse >to start up. Is it just me or have other people had this happen? A final (HAhahaha...) muttering from me on this: 1) While I posted (or E-mailed) earlier that this sounds like classic outta-SWAP trouble, another possibility occured to me. 2) Until approx. the 3.51C kernel, there was an error in the 'getcontext()' code. Despite mis-leading COMMENTS, the code failed to properly change context between two processes. Specifically, if the OUTGOING process had SHARED MEMORY [SHM], it was left mapped-in in the 'MMU'. This caused gross pain when that SHM was at a low enough address that another process attempted to use the same Virtual Address [VA] space. Since the 'MMU' indicated the page was PRESENT, the new process didn't fault-in its own page on 1st access -- ie., start-up, usually. Since it's typically difficult to execute another programs shared data, death by illegal- instruction was common if the new program had a LARGE TEXT image. The error remained as long as it did because: a) the coincidence of low-VA SHM & concurrent large TEXT process is rare; b) the kernel code was 'correct' and the comments were mis-leading: the CONCEPT was flawed because the stated process was not 'in-context' when the code was executing; c) the entire, creaking/ancient VM base for the 3B1 -- based on some Berkeley model -- is obscure and barely even patchable due to its anomalies. In brief, there are SOME cases where program start-up failures may reflect the above problem. I presume IPCS(1) would indicate if you've SHM in use, but WHERE it's mapped is another Q. john mcmillan -- att!mtunb!jcm
student@unf7.UUCP (student account) (08/07/89)
In article <1586@mtunb.ATT.COM>, jcm@mtunb.ATT.COM (was-John McMillan) writes: >> In article <211@comhex.UUCP> I write: >> [ description about large programs dumping core on startup -- deleted ] > [ description of shared memory page conflict deleted ] That was it! I took out all the programs that were using shared memory and everything is working fine now. You say the problem has been fixed? I assume we'll see the fixes in the upcoming fix disk? -- Joe E. Powell unf7!comhex!sysop@bikini.cis.ufl.edu
jcm@mtunb.ATT.COM (was-John McMillan) (08/08/89)
In article <212@unf7.UUCP> unf7!comhex!sysop@bikini.cis.ufl.edu writes: > >That was it! I took out all the programs that were using shared memory >and everything is working fine now. > >You say the problem has been fixed? I assume we'll see the fixes in the >upcoming fix disk? I say: the problem is fixed in currently available fix-disk -- to the best of MY recollection. Regardless, the fixed source has been submitted & accepted, so far as I know. If this is a problem, and you will accept a *3.51* experimental kernel, submit an E-mail address to moi: ^^^^^^^^^^^^ att!mtunb!jcm john mcmillan -- as above -- Growling on forever....