root@ozdaltx.UUCP (Scotty) (04/19/88)
Is anyone else running news on SCO XENIX running into 'Memory Fault - Core dump' on certain article headers where the Newsgroup line is extreamly long? (Ie. > 128 chars?). Seem like lately we've had a rash of postings that seem to cover as many as 20 newsgroups in a single cross-post. Any ideas? Thanx -- ============================================================ | Scotty | Adapt - Enjoy - Survive | | ihnp4!killer!ozdaltx!sysop | "Ad Venerem Securiorem" | ============================================================
john@jclyde.UUCP (John B. Meaders Jr.) (04/20/88)
In article <4782@ozdaltx.UUCP> root@ozdaltx.UUCP (Scotty) writes: >Is anyone else running news on SCO XENIX running into >'Memory Fault - Core dump' on certain article headers where >the Newsgroup line is extreamly long? (Ie. > 128 chars?). I am. I applied the fix posted recently to change BUFLEN in rightgroup in rfuncs.c to LBUFLEN. This hasn't eliminated the problem. I still get the occasional dump. Anybody know why this is happening? -- John B. Meaders, Jr. 1114 Camino La Costa #3083, Austin, TX 78752 ATT: Voice: +1 (512) 451-5038 Data: +1 (512) 371-0550 UUCP: ...!uunet!utastro!bigtex!jclyde!john or john@jclyde.UUCP
mike@ists (Mike Clarkson) (04/22/88)
In article <4782@ozdaltx.UUCP>, root@ozdaltx.UUCP (Scotty) writes: > Is anyone else running news on SCO XENIX running into > 'Memory Fault - Core dump' on certain article headers where > the Newsgroup line is extreamly long? (Ie. > 128 chars?). Yes, this is happening to me too. I can't seem to find where this is happening. The field in hbuf for the newsgroups line is usually set to LBUFLEN which is 1024, <header.h> struct hbuf { char from[BUFLEN]; /* From: */ char path[PATHLEN]; /* Path: */ char nbuf[LBUFLEN]; /* Newsgroups: */ ... but somewhere this must be getting jammed into something of BUFLEN in size, which is 128 on small address space systems. Can anyone find where this is happening? -- Mike Clarkson mike@ists.UUCP Institute for Space and Terrestrial Science York University, North York, Ontario, CANADA M3J 1P3 (416) 736-5611
jfh@rpp386.UUCP (John F. Haugh II) (04/26/88)
In article <188@ists> mike@ists (Mike Clarkson) writes: >In article <4782@ozdaltx.UUCP>, root@ozdaltx.UUCP (Scotty) writes: >> Is anyone else running news on SCO XENIX running into >> 'Memory Fault - Core dump' on certain article headers where >> the Newsgroup line is extreamly long? (Ie. > 128 chars?). > >Yes, this is happening to me too. I can't seem to find where this is >happening. The field in hbuf for the newsgroups line is usually set to >LBUFLEN which is 1024, >-- >Mike Clarkson mike@ists.UUCP FLAME ON! have we all forgotten how to debug a program??? first, start by determining WHERE this is happening. to do that you need to compile with -g turned on. then, determine which exact article caused the core dump by looking at the header which was being processed when you caught the core dump. next, figure out what about the article caused the dump. THEN FIX IT. FLAME OFF! i suspect this is not the actual problem. has anyone seen if any pdp-11's are having this problem? make the damned fields larger, if the trouble goes away, consider it fixed. what about path length? just for my $0.02 worth - the '386 isn't having this problem. i may recompile -M2s if noone finds the bug soon ... - john. -- John F. Haugh II | "You see, I want a lot. Perhaps I want every River Parishes Programming | -thing. The darkness that comes with every UUCP: ihnp4!killer!rpp386!jfh | infinite fall and the shivering blaze of DOMAIN: jfh@rpp386 | every step up ..." -- Rainer Maria Rilke
mem@zinn.MV.COM (Mark E. Mallett) (05/03/88)
In article <1293@rpp386.UUCP>, jfh@rpp386.UUCP (John F. Haugh II) writes: > FLAME ON! > > have we all forgotten how to debug a program??? > > first, start by determining WHERE this is happening. to do that you > need to compile with -g turned on. > > <etc> This is an idiotic flame. Very few people are interested in debugging every program that goes wrong on their system, *especially* all of the system programs that you use every day. The reasonable thing when finding a problem is to ask for a solution, and not to try to hunt for the answer in parallel with the other 10,000 people who also use the program! No, we have not all forgotten how to debug, but we are more interested in debugging things that are more closely related to our *own* lives. -- Mark E. Mallett PO Box 4188/ Manchester NH/ 03103 Bus. Phone: 603 645 5069 Home: 603 424 8129 uucp: mem@zinn.MV.COM (...decvax!elrond!zinn!mem or ...sii!zinn!mem) BIX: mmallett
amull@Morgan.COM (Andrew P. Mullhaupt) (12/10/89)
I am porting a large program to SCO UNIX System/V 386 r3.2 and it has acquired the habit of core dumping here and there. There isn't a lot of use in looking at the dumps, which (due to data) are about 8 MBytes. I have tried to find a limit I can put on the size of core dumps, or a way to pipe them to /dev/null, etc. because it's pretty annoying to wait for the thing to dump 8 MBytes before much else useful can be done with the machine. I put a file in the directory with the name core, owned by root and read only, but the dump still happens. Any ideas? Thanks in advance, Andrew Mullhaupt
cpcahil@virtech.uucp (Conor P. Cahill) (12/11/89)
In article <591@s5.Morgan.COM>, amull@Morgan.COM (Andrew P. Mullhaupt) writes: > I put a file in the directory with the name core, owned by > root and read only, but the dump still happens. Any ideas? How about making a directory named "core". In SysV Rel 3.2 the kernel will not overwrite a directory named core. Be careful using this technique in older systems because you could end up with a munged. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
captain@vax1.acs.udel.EDU (Jeffrey Kirk) (12/11/89)
In article <591@s5.Morgan.COM> amull@Morgan.COM (Andrew P. Mullhaupt) writes:
:I am porting a large program to SCO UNIX System/V 386 r3.2 and
:it has acquired the habit of core dumping here and there. There
:isn't a lot of use in looking at the dumps, which (due to data)
:are about 8 MBytes. I have tried to find a limit I can put on
:the size of core dumps, or a way to pipe them to /dev/null, etc.
:
:I put a file in the directory with the name core, owned by
:root and read only, but the dump still happens. Any ideas?
:
Try: ln /dev/null core, from the directory where you get the dump.