Deleted file from SMB-mounted HDD...
Yes, I've had WiFi (no Internet, no ping, no rsync, no ssh) and bluetooth (no external keyboard) connection issues as well as KPs on an entirely pristine machine, i.e., one whose SSD has been erased with HS and SU2 freshly installed with no other software or files transferred to the machine, not even other Apple software such as Xcode or the Commandline Tools.
In attempting to test for the random and intermittent WiFi connection problems (now on the second of two 2018 MBPs) without loading any other software but the basic system, I mounted (SMB) an HDD over WiFi and played using iTunes an older iTunes Library of music streamed over WiFi to a HomePod. The MBP's iTunes app informed me that it was updating the older iTunes Library, so it copied the old one to the Previous iTunes Libraries subdirectory but then failed to generate the updated iTunes Library file in the iTunes folder. I discovered this when I attempted to restart iTunes, it complained that the iTunes folder did not contain an iTunes Library file. (I tested exactly this same scenario but using a 2016 MBP instead the 2018 MBP, and the 2016 model successfully updated the old iTunes Library on exactly the same WiFi mounted SMB HDD, thus showing that this error in no way was due to the old iTunes Library nor the WiFi mounted SMB HDD.)
I documented this error and uploaded the documentation to Apple Support.
In summary, iTunes had deleted a file on a disk mounted over WiFi on a pristine reinstall of the latest software -- granted HS/SU2 because that is what the machine came with. To me, this is a scary error since it means that the 2018 MBP is capable of deleting files improperly.
[doublepost=1539991558][/doublepost]
Dang nabbit -- I wish the blog software hadn't merged these two posts since they were on different topics.
Corrupted encrypted file...
Another error that I consider quite serious, is one entailing gpg encryption/decryption. I've been using gpg since before its inception and before that I had been using my own coded RSA algorithm to perform encryption/decryption tasks of files. In all that time (over 25 years), I've never seen the following error, that is, until last month on the 2018 MBP.
Because of the Heartbleed and CUPID security holes, I wrote a 3500+ line bash script to implement a more secure encryption/decryption scheme using gpg2 for the encrypt/decrypt tasks. By more secure I mean that before the encryption/decryption, the network is stopped (i.e., the machine is taken offline), the abilities to write sleep images and swap files are stopped, no logins are allowed, etc. The encrypted files are then decrypted and edited, and then re-encrypted. Before resuming normal computer operations, the re-encrypted files are temporarily decrypted and checked against the original decrypted and edited files (thus verifying that the decryption/editing/encryption worked correctly). All of these steps and their outputs are written to a log file, thus documenting that each step worked correctly. Any failures of these actions is caught by the bash script and the user is not allowed to complete the actions until corrective actions are taken. Once the decrypt/edit/encrypt is validated, then the script deletes the decryptions, overwrites RAM memory with random bits (to confound the Heartbleed and CUPID security holes), it then reattaches the computer's network connections, turns the sleep and swap images back on, etc., and completes the session with a successful terminal message.
On the 2018 MBP I used this bash script to edit an encrypted file. It did so successfully, meaning that the original encrypted file had been properly decrypted, the decrypted file was edited, and the edited file was re-encrypted. The re-encrypted edited file was then decrypted and the decryption validated against the original edited version, i.e., the decryption/edit/encryption worked properly. But when I went to re-edit the same encrypted file six days later the bash script alerted me to the fact that gpg2 had failed in its decryption. In particular, gpg2 complained that it did have the necessary key ID to perform the decryption. The offending key ID reported by gpg2 does not even exist: nowhere is this key in my public nor secret keychains. In other words, according to gpg2 I could not have created this encrypted file, and yet I did create it and I have the log files to prove it. So, the encrypted file on the SSD had a corrupted key ID. Since the decryption/encryption had worked correctly 6 days earlier, this means that while these files were in RAM memory, the decryption/encryption by gpg2 had worked correctly, but either when the file was subsequently written to the SSD, or at a subsequent time during the 6 day hiatus, the file stored on the SSD was corrupted. (Now this encrypted, but corrupted, file can never be decrypted, it is lost forever. Fortunately I had a backup of the encrypted file that was not corrupted, so I only lost the edits that I had done 6 days earlier. Remembering those edits allowed me to recover the file with all of its edits.) I carefully documented this SSD error and uploaded the results to Apple Support.
This is the first and only time that I have ever seen this type of encryption/decryption error in over 25 years of use of the RSA algorithm and gpg on dozens of computers under multiple different operating systems (Cray, Sun, Iris, DEC, Connection Machine, BBN Butterfly, PCs, Linuxes, Macs, even Raspberry Pis, ...).
In summary, to me, this is a very serious error because it means that the 2018 MBP is capable of corrupting the files on its own SSD, as demonstrated and documented by me.
This type of error might also partially explain the seemingly delayed KPs initially, but then ever increasing frequency of KPs. Say that initially the kernel code is pristine and correct, so no KPs initially. But over time the macOS slowly introduces corruption randomly into the kernel code, then voila, a kernel panic occurs because of a corrupted kernel module. With more random code corruptions, then more random KPs. In other words, there is no one reason for KPs, they happen upon wake from sleep, they happen while playing audio, they happen while playing video, they happen while using emacs to write code (a la my own KPs), they happen while the computer is apparently idle, they happen while the CPUs are completely saturated, they happen while using WiFi, etc. What do you think?
