battan@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!billbill@twwells.uucp (T. William Wells) (10/30/88)
In article <120@twwells.uucp> bill@twwells.UUCP I wrote:
:
: 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.
All running B 2.11 12/1/87.
Sorry.
---
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
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 +--------------------------------------