From mboxrd@z Thu Jan 1 00:00:00 1970 From: random832@fastmail.com (Random832) Date: Thu, 21 Dec 2017 21:55:14 -0500 Subject: [TUHS] SYSTEM V R1 HELP In-Reply-To: <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com> References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com> <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com> <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com> Message-ID: <1513911314.999748.1213050656.486E2E9E@webmail.messagingengine.com> On Thu, Dec 21, 2017, at 20:51, William Corcoran wrote: > Okay, I think I am on to something… > > Whenever tar or cpio dumps core, it is always when 32769 bytes have been > written to stdout. Is that 32769 bytes to the tape (which is not stdout in your tar invocation), or 32769 bytes of printed output? Is it exactly 32769, or just some value above 32768 by some small amount? > I looked at fprintf and there is a register int called “count.” Your crash is in _strout, two calls deep before that variable is written since the adjust parameter is 0, the only thing of note in _strout is a putc loop. putc is a macro so it won't appear in the stack trace - that _flsbuf does not appear in the stack trace means this is happening in the 'ordinary' buffered I/O case. Strange, though, I can't see anything inside putc/flsbuf that seems like anything should be any different on the 32770th character than the 514th or 1026th. What are the strings being printed? (second argument to printf, and first argument to strout)?