battan@tc.fluke.COM (Jim Battan) (10/25/88)
Recently, I've noticed core dumps being left by inews. I ran it through
dbx, and traced it down to being caused by control messages. In control.c,
the code for c_cancel() runs through all newsgroups the article was posted to,
removing the files. However, once in a blue moon it runs off the end of the
string in the history file and indirects through memory location 1, causing
a segmentation violation on our Sun. I have no idea why I haven't seen
this before; it looks like it should always produce the core dump, but
I only have seen it recently. Anyway, here's a patch.
Disclaimer: This works for me; your mileage may vary.
Index: control.c
*** /tmp/,RCSt1a07965 Tue Oct 25 08:43:59 1988
--- control.c Thu Oct 20 12:03:12 1988
***************
*** 704,708
(void) unlink(nfilename);
! p = q+1;
}
#endif /* !NFSCLIENT */
--- 704,711 -----
(void) unlink(nfilename);
! if (q == NULL)
! break;
! else
! p = q+1;
}
#endif /* !NFSCLIENT */
--
Jim Battan (+1 206 356 6469)
battan@tc.fluke.COM || {sun,uw-beaver,decvax!microsoft}!fluke!battanbattan@tc.fluke.COM (Jim Battan) (10/26/88)
In article <5686@fluke.COM> (news.software.b), I write: > Recently, I've noticed core dumps being left by inews. I ran it through > dbx, and traced it down to being caused by control messages. > I only have seen it recently. [BTW: This is running B11.2.14] After I posted that message, I realized that the core dumps were all coming from the UUCP maps posted to comp.mail.maps. I found tons of .ina* and .ara* files sitting in the news directory, all of them UUCP maps from rutgers. Has anyone recently changed the way these maps are posted? Off-hand, I don't see any changes. -- Jim Battan (+1 206 356 6469) battan@tc.fluke.COM || {sun,uw-beaver,decvax!microsoft}!fluke!battan
pleasant@porthos.rutgers.edu (Mel Pleasant) (10/26/88)
There hasn't been any changes in the way maps are posted to comp.mail.maps
that I am aware of. Is anyone else seeing this behavior? If so, please
tell me right away.
--
Mel Pleasant
{backbone}!rutgers!pleasant pleasant@rutgers.edu mpleasant@zodiac.bitnetskip@claris.com (Brian Schipper) (10/26/88)
In article <5695@fluke.COM> battan@tc.fluke.COM (Jim Battan) writes: >After I posted that message, I realized that the core dumps were all >coming from the UUCP maps posted to comp.mail.maps. I found tons of >.ina* and .ara* files sitting in the news directory, all of them UUCP >maps from rutgers. Has anyone recently changed the way these maps are >posted? Off-hand, I don't see any changes. Hmmmm... After reading this I went and checked my news directory and I found the same thing. This explains the mysterious random failure of inews I asked about in news.software.b last week. The articles which failed to get sent by inews seem to correspond to the ones that are lying around in the news directory. Looks like I'll have to try this patch... (patch, patch, tinker, tinker....) -- Internet: skip@claris.com Applelink: SCHIPPER1 UUCP: {ames,apple,sun}!claris!skip Phone: 415-960-2618
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (10/26/88)
skip@claris.com (Brian Schipper) writes:
Hmmmm... After reading this I went and checked my news directory and I
found the same thing. This explains the mysterious random failure of
It would be mightily useful if those finding this problem would start
posting hardware/software configurations in use. I have just checked
my systems and have no problems (no defunct .[ai]* files in
/usr/spool/news). So it would seem to be a problem peculiar to
certain types of systems.
Pyramid 98x w/OSx 4.0 and 3B2/400 w/SysVRel3.0 are `clean.'
--Karlskip@claris.com (Brian Schipper) (10/27/88)
In article <25756@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >It would be mightily useful if those finding this problem would start >posting hardware/software configurations in use.... We're running a Sun 3/50 with Sun UNIX 4.2 Release 3.4. News software is 2.11, patchlevel 14. -- Internet: skip@claris.com Applelink: SCHIPPER1 UUCP: {ames,apple,sun}!claris!skip Phone: 415-960-2618
mem@zinn.MV.COM (Mark E. Mallett) (10/28/88)
In article <5695@fluke.COM> battan@tc.fluke.COM (Jim Battan) writes: >...I found tons of >.ina* and .ara* files sitting in the news directory, all of them UUCP >maps from rutgers. Has anyone recently changed the way these maps are >posted? Over the last 2-3 weeks I, too, have been seeing lots of .ina* and .ara* files sitting in the news directory, all of which are uucp maps from rutgers. I haven't yet gone looking for the bug, opting for housecleaning for now. Anyone know the story? -mm- -- Mark E. Mallett Zinn Computer Co/ PO Box 4188/ Manchester NH/ 03103 Bus. Phone: 603 645 5069 Home: 603 424 8129 uucp: mem@zinn.MV.COM ( ...{decvax|elrond|harvard}!zinn!mem ) BIX: mmallett
jim@eda.com (Jim Budler) (10/28/88)
In article <25756@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >It would be mightily useful if those finding this problem would start >posting hardware/software configurations in use. I have just checked >my systems and have no problems (no defunct .[ai]* files in >/usr/spool/news). So it would seem to be a problem peculiar to >certain types of systems. Sun 386i SunOS 4.0 News 2.11 Patchlevel 14 jim -- uucp: {decwrl,uunet}!eda!jim Jim Budler internet: jim@eda.com EDA Systems, Inc.
guy@auspex.UUCP (Guy Harris) (10/28/88)
>It would be mightily useful if those finding this problem would start >posting hardware/software configurations in use. I have just checked >my systems and have no problems (no defunct .[ai]* files in >/usr/spool/news). So it would seem to be a problem peculiar to >certain types of systems. > >Pyramid 98x w/OSx 4.0 and 3B2/400 w/SysVRel3.0 are `clean.' If the problem is a core dump on the moral equivalent of char *p = NULL; p++; do_something_with(*p); then it's not surprisng the 3B2 is clean, unless you linked the software with "-z" or whatever the option to take location 0 out of the address space is called, and it's not surprising it blew up on a Sun. I can't speak for the Pyramid; I don't know if it slaps your wrist for dereferencing null pointers or not.
clarke@acheron.UUCP (Ed Clarke) (10/28/88)
From article <393@zinn.MV.COM>, by mem@zinn.MV.COM (Mark E. Mallett): > In article <5695@fluke.COM> battan@tc.fluke.COM (Jim Battan) writes: >>...I found tons of .ina* and .ara* files sitting in the news directory, >>all of them UUCP maps > Over the last 2-3 weeks I, too, have been seeing lots of .ina* and .ara* > files sitting in the news directory, all of which are uucp maps from Me too, but with a slight difference. The maps in question were successfully posted to comp.mail.maps BUT my automatic unshar script in the news/sys file failed to work: UUMAP:world,usa,na,comp.mail.maps::/usr/lib/news/uumap If I run the script by hand using the failed .ina* files, it works correctly. The failing system is a Sun 3/2?? running Sun OS/4.0. The same shell script and (source for) B news ( patchlevel 14 ) works on an IBM RT/PC with AIX 2.2. Are other people with the problem using Sun 4.0? I'm pretty sure it worked ok with a prior release ... -- Ed Clarke uunet!bywater!acheron!clarke
battan@tc.fluke.COM (Jim Battan) (10/28/88)
In article <25756@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >It would be mightily useful if those finding this problem would start >posting hardware/software configurations in use. >Pyramid 98x w/OSx 4.0 and 3B2/400 w/SysVRel3.0 are `clean.' It is obviously only going to happen on systems that give you a segmentation violation when you try to access memory at word 0, like on Suns. Our news machine is a Sun 2/120 running SunOS 3.4, News B.2.11.14. The code in control.c tries to indirect through memory location 1 when it's done with the list of filenames to remove. My patch prevents this. I'm still perplexed as to why Sun sites (including ours) haven't seen this in the past. -- Jim Battan (+1 206 356 6469) battan@tc.fluke.COM || {sun,uw-beaver,decvax!microsoft}!fluke!battan
jim@eda.com (Jim Budler) (10/29/88)
In article <330@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: |>It would be mightily useful if those finding this problem would start |>posting hardware/software configurations in use. I have just checked | |If the problem is a core dump on the moral equivalent of | | char *p = NULL; | | p++; | do_something_with(*p); | |then it's not surprisng the 3B2 is clean, unless you linked the software |with "-z" or whatever the option to take location 0 out of the address |space is called, and it's not surprising it blew up on a Sun. I can't Umh, a 'Sun' 680x0 is not surprising, but a Sun 386? Or did they implement 'no location 0' option as default. Whatever, the posted patch *does* fix the ~news/.??*, the ~news/core, and the 'why weren't my maps batched' problems. ( for a Sun 386i). jim -- uucp: {decwrl,uunet}!eda!jim Jim Budler internet: jim@eda.com EDA Systems, Inc.
lmb@vsi1.UUCP (Larry Blair) (10/29/88)
In article <5744@fluke.COM> battan@tc.fluke.COM (Jim Battan) writes: >I'm still perplexed as to why Sun sites (including ours) haven't seen this in >the past. I've always noticed a number of these . files building up in /usr/spool/news on our Sun. Periodically I would clean them out. Since I installed the patch, there hasn't been a single one. -- Larry Blair ames!vsi1!lmb lmb%vsi1.uucp@ames.arc.nasa.gov
skip@claris.com (Brian Schipper) (10/30/88)
In article <1160@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: >I've always noticed a number of these . files building up in /usr/spool/news >on our Sun. Periodically I would clean them out. Since I installed the >patch, there hasn't been a single one. The patch seems to have fixed things here on our Sun too. I haven't seen any of the .ina or .ara files building up and the map updates are working great! -- Internet: skip@claris.com Applelink: SCHIPPER1 UUCP: {ames,apple,sun}!claris!skip Phone: 415-960-2618
bill@twwells.uucp (T. William Wells) (10/30/88)
In article <25756@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes:
: It would be mightily useful if those finding this problem would start
: posting hardware/software configurations in use. I have just checked
: my systems and have no problems (no defunct .[ai]* files in
: /usr/spool/news). So it would seem to be a problem peculiar to
: certain types of systems.
Sun 3/280, SunOS 3.4 fails.
Sun 3/280, SunOS 4.0 seems to fail, but there may be other causes.
Zenith 386, latest Microport UNIX seems OK, but I'll check in a few days.
---
Bill
{uunet|novavax}!proxftl!twwells!billguy@auspex.UUCP (Guy Harris) (11/01/88)
>Umh, a 'Sun' 680x0 is not surprising, but a Sun 386? > >Or did they implement 'no location 0' option as default. They implemented "no location 0" as default. From COFF(5): When an a.out file is loaded into memory for execution, three logical segments are set up: the text segment, the data segment (initialized data followed by uninitialized, the latter actually being initialized to all 0's), and a stack. The text segment starts at location 0x1000 by default.
wes@obie.UUCP (Barnacle Wes) (11/04/88)
In article <25995@tut.cis.ohio-state.edu>, karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: > Tut == Pyramid 98x: > > [135] [1:59pm] tut:/dino0/karl/tmp> cat > z.c > main() > { > char *p = (char *)0; > p++; > *p = 'p'; > printf("done\n"); > } > [136] [1:59pm] tut:/dino0/karl/tmp> cc z.c -o z > [137] [2:00pm] tut:/dino0/karl/tmp> ./z > Bus error (core dumped) Here are the results for System V/AT ('286): obie!wes[44] cat z.c main() { char *p = (char *)0; p++; *p = 'p'; printf("done\n"); } obie!wes[45] time cc -o z z.c 2.4u 4.1s 0:10 64% obie!wes[45] ./z done obie!wes[46] time cc -o z -Ml z.c # use "large memory model" 2.8u 3.9s 0:11 60% obie!wes[47] ./z ./z: Segmentation violation -- Core dumped obie!wes[48] rm core z z.c Neat, huh? This is why: using the small memory model (the default), pointers are 16-bit offsets into the data segments. Addresses DS:0 and DS:1 are valid, writable addresses, so the program runs correctly in small model. In the large model, however, pointers are 32 bits, and include the segment selector. This makes (char *)0 equal address 0:0, which may or may not be a valid address in the process' space. If it is a valid address, it is probably in the code segment, which CANNOT be writable on the '286. This system can really be a nightmare to port to! -- "The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." - Bertrand Russell "How come he didn't put `I think' at the end of it?" - James P. Hogan
clewis@ecicrl.UUCP (Chris Lewis) (11/06/88)
In article <5686@fluke.COM> battan@tc.fluke.COM (Jim Battan) writes: >Recently, I've noticed core dumps being left by inews. Other symptom - .ina and .ar(?) files left around. I used to get this on a spectrix machine (68020 with location zero readable - usually - a bug caused really large programs like Oracle to not be able to get at zero - not sure whether inews qualifies). Now I'm on a 3b1 (3.5.1.4) and haven't seen this occur yet (haven't been subscribed to comp.mail.maps long enough for a map supercede to actually delete something). >Index: control.c > (void) unlink(nfilename); >! if (q == NULL) >! break; >! else >! p = q+1; > } > #endif /* !NFSCLIENT */ Interestingly enough, when I went to install this patch, I found: (void) unlink(nfilename); if (!q) break; else p = q + 1; Hmm. Looks the same to me. Mod date Feb 15, 1988. I'm now running on a 3b1 (3.5.1.4) and haven't seen the bug crop up yet (and I'm not even sure at the moment whether this news software is the same as what was running on the Spectrix). Evidently, someone posted this bug fix back in February (it might have been me, but I don't think so - I only remember posting a bug fix for headers having tab separators after the colon - as C-news will sometimes generate) Every once in a while someone uncovers another bug in B-news and sometimes we get a flurry of unofficial patches some of which work, and some don't. It appears that Rick Adams isn't going to be posting any more official patches because of the nearness of C news or News 3.0. I think it's fair to say that many people would like to keep running B-news 2.11 until official release of C news or News 3.0 (this may already have been done - I've been off the net for a while) occur and perhaps beyond then. And, that new functionality isn't appropriate. And, that many people miss (or vaguely mistrust) patches that don't come from Rick Adams. Rick, it would be a great service if you could - give us at least a description (if not patch input) for any bug fixes that you've seen going by that *would* have gone into a patch 15 if you were to send one? Eg: a "maintenance-only" patch. - sanction in some fashion any new bugfixes going by? Thanks, -- Chris Lewis Ferret Mailing list:{uunet!attcan,yunexus,utzoo}!lsuc!gate!eci386!ferret-request {uunet!attcan,uunet,utgpu,yunexus,utzoo}!lsuc!ecicrl!clewis (or lsuc!gate!eci386!clewis or lsuc!clewis)
jbrown@herron.uucp (Jordan Brown) (11/09/88)
> [test pgm works in small model, not in large model] > Neat, huh? This is why: using the small memory model (the default), > pointers are 16-bit offsets into the data segments. Addresses DS:0 and > DS:1 are valid, writable addresses, so the program runs correctly in > small model. In the large model, however, pointers are 32 bits, and > include the segment selector. This makes (char *)0 equal address 0:0, So far so good. > which may or may not be a valid address in the process' space. If it is > a valid address, it is probably in the code segment, which CANNOT be > writable on the '286. Segment 0 is NEVER valid. Guaranteed. (Amazing, Intel doing something right!) > This system can really be a nightmare to port to! Not if your code is portable. The only real problems come if you use sbrk to allocate memory instead of malloc, or if you want to work with single objects (arrays, structures, etc) bigger than 64K. In general, you can't assume anything about pointers to different objects. We found a lot of bugs by running things under 286 large model... (Don't get me wrong. All in all I'd rather have a conventional addressing model, as long as address 0 is mapped out, code is read-only, and nonexistant memory causes faults. Unfortunately, few versions of UNIX choose to do all of these "obviously right" things. It's hard not to on a 286 in large model.)
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (11/11/88)
In article <8@herron.uucp> jbrown@jato.jpl.nasa.gov writes: >We found a lot of bugs by running things under 286 large model... i compile all of my new software in 286 or 8086 mode. those cpus are so brain damaged that merely making it thru the compiler and a short test run is a very good indicator of correctness. ps - i'm not joking. -- John F. Haugh II +----Make believe quote of the week---- VoiceNet: (214) 250-3311 Data: -6272 | Nancy Reagan on Artifical Trish: InterNet: jfh@rpp386.Dallas.TX.US | "Just say `No, Honey'" UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
admin@cs.exeter.ac.uk (Khalid Sattar) (11/16/88)
In article <1160@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: > Since I installed the patch, there hasn't been a single one. We get similar problems here, but I seems to have missed the patch. Anyone willing to send me this patch? -- Khalid Sattar JANET: admin@uk.ac.exeter.cs Computer Science Dept. UUCP: ukc!expya!admin University of Exeter