Hello Clem, Well, I have some interesting results. First, your comments about fprintf made me think about turning off the output. So: cd / find . -print | cpio -ocB > /dev/null Works perfectly, the return code is a nice clean 0—No more core dump! However, when I enable the verbose option to cpio, it dumps core. Next, it dumps core using your example below. However, if I remove the verbose option, cpio completes without error!!! Next, I got a super weird result when I try to print the error code: find . -print | cpio -ocvB > /dev/null files are displayed…. Memory Fault: core dumped echo $? 1003 Now, I thought all return values were 8 bit? What is that all about? I just wanted to pass along the update. I will see if I can follow the string pointers in fprintf. Truly, Bill Corcoran On Dec 21, 2017, at 5:30 PM, Clem Cole &lt;clemc(a)ccc.com&gt; wrote: Bill, in the debugger, for both cpio and tar, follow the string ptrs in fprintf and see if you can figure out where its dying. Also see what value errno is, hopefully it has not been lost. Neither program should be using printf except for messages to the console, so I'm guessing this is an error message trying to be output from an error the kernel returned. See if you can find the message from cpio/tar and the error code and that might give you a hint to look in the kernel. Could you be running out of open files, maybe. Another thing to try, is: cd / find . -print​ > /tmp/file.lst cpio -ocvB > /dev/null​ < /tmp/file.lst See if that changes anything. It should remove some of pressure on the kernel tables. ​Clem​ ​ ᐧ On Thu, Dec 21, 2017 at 5:12 PM, William Corcoran &lt;wlc(a)jctaylor.com&gt; wrote: Hello Team TUHS: I am having a problem with my PDP-11 SVR1 running under a recent SIMH build. My problem occurs on both MAC OS X and FreeBSD. First, I created a six disk (RP06) and eight port TTY (DZ) kernel, with swap placed on drive 1. The system behaves beautifully as FSCK reports clean. Eight users can login with no problem. Second, I reverted to a pristine PDP-11 SVR1 with one drive (RP06) and no DZ and booted the default kernel (gdtm) and I see the same problem described below. Third, when using the tape driver instead of /dev/null i get the same results. Next, here is the issue: cd / find . -print | cpio -ocvB > /dev/null It runs for a short while and then shitz a core: I am using /dev/null to take the tape driver out of the equation. Here is the backtrace for cpio: $c __strout(053522,043,0,053012) __doprnt(046652,0177606,053012) _fprintf(053012,046652,053522) ~main(02,0177636) Now, interestingly, I run into a similar issue when using tar: cd /usr tar -cvf /dev/null . Again, this will run for a while, then drops a core. Here is the backtrace for tar: $c __strout(043123,02,0,045506) __doprnt(043123,0167472,045506) _fprintf(045506,043123,0170600) ~putfile(0170600,0170641) ~putfile(0171654,0171704) ~putfile(0172730,0172745) ~putfile(0174004,0174016) ~putfile(0175060,0175066) ~putfile(0176134,0176136) ~putfile(0177672,0177672) ~dorep(0177632) ~main(04,0177630) This really bugging me since my SVR1 is otherwise working flawlessly. I was able to remake the entire system and custom kernels that boot with no problem. Also, I configured my main port to run inside the AWS Lightsail and now I have access to SVR1 from anywhere in the world! I was also wondering if doing a CPIO or TAR on the entire system was overflowing some link tables and maybe this is expected behavior for the minimal resource of the PDP-11? Thank you for any help. Would you expect tar or cpio to dump core if you attempted to copy large filesystems (or the entire system) on a PDP-11? Note: All of my testing has been in single user mode. Truly, Bill Corcoran

Strike that... this is UNIX. Please forgive my offensive post. I should have said when count overflows it attempts to clobber the structure and the kernel gets mad and kills the process. Please forgive my transgression. On Dec 21, 2017, at 8:51 PM, William Corcoran <wlc@jctaylor.com<mailto:wlc@jctaylor.com>> 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. I looked at fprintf and there is a register int called “count.” It looks like when it overflows its clobbering a structure and then the kernel gets mad and kills the process. Is it possible this is a latent defect in SVR1 or is there something going on with SIMH? I can’t believe this is a latent defect. Thank you so much for all of your help TEAM TUHS! Much thanks to Clem’s help! Bill Corcoran On Dec 21, 2017, at 7:34 PM, William Corcoran <wlc@jctaylor.com<mailto:wlc@jctaylor.com>> wrote: Hello Clem, Well, I have some interesting results. First, your comments about fprintf made me think about turning off the output. So: cd / find . -print | cpio -ocB > /dev/null Works perfectly, the return code is a nice clean 0—No more core dump! However, when I enable the verbose option to cpio, it dumps core. Next, it dumps core using your example below. However, if I remove the verbose option, cpio completes without error!!! Next, I got a super weird result when I try to print the error code: find . -print | cpio -ocvB > /dev/null files are displayed…. Memory Fault: core dumped echo $? 1003 Now, I thought all return values were 8 bit? What is that all about? I just wanted to pass along the update. I will see if I can follow the string pointers in fprintf. Truly, Bill Corcoran On Dec 21, 2017, at 5:30 PM, Clem Cole <clemc@ccc.com<mailto:clemc@ccc.com>> wrote: Bill, in the debugger, for both cpio and tar, follow the string ptrs in fprintf and see if you can figure out where its dying. Also see what value errno is, hopefully it has not been lost. Neither program should be using printf except for messages to the console, so I'm guessing this is an error message trying to be output from an error the kernel returned. See if you can find the message from cpio/tar and the error code and that might give you a hint to look in the kernel. Could you be running out of open files, maybe. Another thing to try, is: cd / find . -print​ > /tmp/file.lst cpio -ocvB > /dev/null​ < /tmp/file.lst See if that changes anything. It should remove some of pressure on the kernel tables. ​Clem​ ​ ᐧ On Thu, Dec 21, 2017 at 5:12 PM, William Corcoran <wlc@jctaylor.com<mailto:wlc@jctaylor.com>> wrote: Hello Team TUHS: I am having a problem with my PDP-11 SVR1 running under a recent SIMH build. My problem occurs on both MAC OS X and FreeBSD. First, I created a six disk (RP06) and eight port TTY (DZ) kernel, with swap placed on drive 1. The system behaves beautifully as FSCK reports clean. Eight users can login with no problem. Second, I reverted to a pristine PDP-11 SVR1 with one drive (RP06) and no DZ and booted the default kernel (gdtm) and I see the same problem described below. Third, when using the tape driver instead of /dev/null i get the same results. Next, here is the issue: cd / find . -print | cpio -ocvB > /dev/null It runs for a short while and then shitz a core: I am using /dev/null to take the tape driver out of the equation. Here is the backtrace for cpio: $c __strout(053522,043,0,053012) __doprnt(046652,0177606,053012) _fprintf(053012,046652,053522) ~main(02,0177636) Now, interestingly, I run into a similar issue when using tar: cd /usr tar -cvf /dev/null . Again, this will run for a while, then drops a core. Here is the backtrace for tar: $c __strout(043123,02,0,045506) __doprnt(043123,0167472,045506) _fprintf(045506,043123,0170600) ~putfile(0170600,0170641) ~putfile(0171654,0171704) ~putfile(0172730,0172745) ~putfile(0174004,0174016) ~putfile(0175060,0175066) ~putfile(0176134,0176136) ~putfile(0177672,0177672) ~dorep(0177632) ~main(04,0177630) This really bugging me since my SVR1 is otherwise working flawlessly. I was able to remake the entire system and custom kernels that boot with no problem. Also, I configured my main port to run inside the AWS Lightsail and now I have access to SVR1 from anywhere in the world! I was also wondering if doing a CPIO or TAR on the entire system was overflowing some link tables and maybe this is expected behavior for the minimal resource of the PDP-11? Thank you for any help. Would you expect tar or cpio to dump core if you attempted to copy large filesystems (or the entire system) on a PDP-11? Note: All of my testing has been in single user mode. Truly, Bill Corcoran

Hello Random832, Yes, I make a mistake, the issue is with STDERR. The pipeline: find . -print | cpio -ocvB >/dev/null 2>/tmp/ERRFILE will drop core: ERRFILE will have exactly 32769 bytes (no more and no less). STDOUT is redirected to /dev/null and there is no problem with STDOUT. For example: find . -print | cpio -ocB > /dev/null Succeeds because nothing (or close to nothing) is written to STDERR before cpio successfully terminates. STDOUT is fine and CPIO and tar can write thousands of blocks cleanly on STDOUT. Normally, as you know, STDOUT would be redirected to the tape device and not /dev/null. Here is my take: This may be a latent defect in that early releases may not have realized the very large amounts of data that can be written to STDERR. In this case, each file that is backed up with cpio is represented as a single line in STDERR. When STDERR exceeds 32768 bytes, it blows up. fprintf returns an int that is the number of bytes in the stream. For some reason, when this overflows, it is not wrapping around, instead it causes a segmentation violation. Could the issue be with fprintf or doprnt.c? I thought STDERR was unbuffered? Please forgive me. Thank you for all of your help. On Dec 21, 2017, at 9:55 PM, Random832 &lt;random832(a)fastmail.com&gt; wrote: On Thu, Dec 21, 2017, at 20:51, William Corcoran wrote: 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? 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)?

Brilliant Random832! Very impressive! Thank you for the early Christmas present! Your initial analysis was equally spot on when you interpreted the backtrace. This is very much appreciated! Truly, Bill Corcoran On Dec 22, 2017, at 4:09 AM, Random832 <random832@fastmail.com<mailto:random832@fastmail.com>> wrote: On Thu, Dec 21, 2017, at 22:47, William Corcoran wrote: Could the issue be with fprintf or doprnt.c? I thought STDERR was unbuffered? Please forgive me. I've got it. The problem is with putc (actually _flsbuf), and it is precisely *because* stderr is unbuffered. #define putc(x, p) (--(p)->_cnt >= 0 ? \ ((int) (*(p)->_ptr++ = (unsigned char) (x))) : \ _flsbuf((unsigned char) (x), (p))) Under normal circumstances for an unbuffered (or line-buffered) stream, _cnt starts as 0, and therefore every character is passed through _flsbuf. However, _cnt is still decremented (becoming -1, -2, etc) - _flsbuf should be resetting this to zero (and does in other versions, both earlier and later), but we can see in flsbuf.c it does not. So, after 32769 characters have been output it ticks from -32768 to +32767, and putc now thinks the stream is buffered. You'll want to add iop->cnt = 0 to the second if clause in _flsbuf.

On Fri, 22 Dec 2017, Random832 wrote: [...] That, sir, is one brilliant piece of analysis; well done! Of course, in hindsight it's bleedin' obvious :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

V1. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.

On Thu, Dec 21, 2017, at 19:34, William Corcoran wrote: In the Bourne shell, when a process exits a signal, $? is set to sig|SIGFLG, which is, for some unknown reason, defined to 1000 (Yes, as in 0x3E8. As in 1000|11 == 1000|3 == 1003) - a value that no other version before or since SVR1 (at least not SysIII or SVR4) seems to have - every other one I checked has 0200. I can only guess that the reason is to make it easier to read the signal number, and whoever it is only tested with SIGINT and SIGQUIT or they would have presumably changed it to sig+SIGFLG. Then at some point before a later SysV release, it was reverted to 0200. POSIX for its part only guarantees a value above 128, not any particular value or distinct values per signal.