Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Serious Bug in macOS will Crash after 49 days
- Thread starter boppin
- Start date
- Sort by reaction score
I think this is new (with Tahoe). Reasons:
We Found a Ticking Time Bomb in macOS TCP Networking - It Detonates After Exactly 49 Days - Photon Blog
Photon powers conversational AI agents on iMessage, WhatsApp, Telegram, and more. Open-source Spectrum framework + SDK for seamless agent interactions.photon.codes
1. The two Apple Community references in the Photon article are to TCP connection issues within a few hours - not 49 days. So nothing to substantiate this maybe going back to Catalina. These false references were where Michael Tsai based his observation of it maybe going back to Catalina.
2. John Gruber https://daringfireball.net/linked/2026/04/09/macos-crash-49-days has looked in the code and found:
"If you look at Apple’s open-source XNU kernel code — e.g. lines 3,732 to 3,745 in tcp_subr.c — you can see that the lines assigning the time in milliseconds to a uint32_tvariable were checked in just six months ago, whereas most of the file is five years old." And so likely to be Tahoe only.
3. John Gruber goes on to say that he has a Sequoia MBP which ran for 91 days between software updates. Others have found something similar.
It is annoying that Photon did not say what macOS version is running on their servers. Nevertheless I found the Photon article an interesting read with exactly the sort of evidence to make Apple sit up and take notice.
Last edited:
I used to shut down my Windows machine almost every day. Since I got a Mac as my main desktop, I rarely shut it down. Still, old habits die hard and I do find myself shutting down my Mac maybe every month or so just because it feels like the right thing to do. Clear the memory, close out everything and get a fresh restart. So, I do that.
macfacts
macrumors 603
copied the windows 95 bug I see. Google "windows 95 49 days".Hi,
No News at MacRumors?
Michael Tsai did also wrote something in his blog. Good man!
We Found a Ticking Time Bomb in macOS TCP Networking - It Detonates After Exactly 49 Days - Photon Blog
Photon powers conversational AI agents on iMessage, WhatsApp, Telegram, and more. Open-source Spectrum framework + SDK for seamless agent interactions.
Green Plan: shut down when done for the day. Save the world with your 2-3 watts.
Add it all up by the millions and is lots of wasted energy.
Apple will be proud of you shutting down saving the Planet.
Besides AI Data Centers could use a few more Watts of electricity! :😂
Add it all up by the millions and is lots of wasted energy.
Apple will be proud of you shutting down saving the Planet.
Besides AI Data Centers could use a few more Watts of electricity! :😂
Only sort of. The Windows 95 bug is not in TCP (or other networking). Rather it is a completely different bug but which is also caused by the overflow of a 32 bit unsigned integer counting millisecond ticks. The W95 bug causes immediate crash whilst the Tahoe(?) bug just disables new TCP connections at some time after 49.7 days.
But I agree this is a kindergarten type of error by some Apple coder.
Why is that? You just close the laptop. Besides, you shouldn't leave a laptop plugged in all the time. I don't, for example. And as an aside: an M4 MacBook Air consumes very little energy in sleep mode. Amazing, I think.
Larsvonhier
macrumors 68000
Just set the "max. charge level" in macOS to 80 or 85% and you should be ok with letting the MacBook on AC for prolonged time. No need to take care any more: It's the fully-charged over prolonged time scenario
(esp. at summer temperatures) that kills your lithium cells.
SnowCrocodile
macrumors 6502a
I haven't shut down my Windows in months, unless this was dictated by updates.
I haven't shut down my Mint desktop in over a year, until I had to unplug it to paint the wall.
The days of Windows ME are long past us. (But clearly, the scars still remain...)
Yup. And that would be why I never encounter this bug despite keeping my Mac Studio on 24/7/365, putting it to sleep but never rebooting it except for updates (or the rare crash).
That's a very good question! Although, some bugs do manage to survive into newer versions. I'm just remembering the bug where the cursor would jump from the Apple menu, after selecting "Shut Down," across the entire screen. I reproduced that with an AppleCare support representative back then, and it was later fixed.
New comment from a MacTechNews commentator
At the end of January/beginning of February, I had to restart my Mini outside of normal operating hours because the entire network connection was down. I was working on it at the same time; first this stopped working, then that, and then nothing at all. A restart fixed everything. I wondered what had happened, since it's not a Windows 64/7 machine, so restarts weren't really something I was familiar with (though it used to be different, of course).
www.mactechnews.de
At the end of January/beginning of February, I had to restart my Mini outside of normal operating hours because the entire network connection was down. I was working on it at the same time; first this stopped working, then that, and then nothing at all. A restart fixed everything. I wondered what had happened, since it's not a Windows 64/7 machine, so restarts weren't really something I was familiar with (though it used to be different, of course).
Kurioser Fehler in Tahoe: Netzwerkversagen nach 50 Tagen
Ein Programmierfehler in macOS 26 führt dazu, dass 49,71 Tage nach Neustart überflüssige Netzwerkverbindungen nicht mehr gelöst werden. Kurz darauf zeigt ein betroffener Mac unerklärliche Verbindungsprobleme. Die Ursache verbirgt sich tief in macOS.
This is all rather strange. Back then, the saying was: you don't need to turn off or restart an Apple notebook. Closing and reopening it is enough, because it's not Windows.
I have several questions:
Why does the number of ticks need to be counted for the networking, and why in the heck did they use a 32-bit u_int? For a start it would make more sense to use a 64-bit value (what is the point of having 64-bit systems?!).
A similar bug exists in many routers for the same reason - they count bytes received and sent, and eventually overflow and crash or corrupt the router. This is why home routers need to be rebooted periodically otherwise things start breaking (I usually experience it as TLS connections failing specifically, followed by DNS lookup problems).
Programmers are getting to be pretty dumb. Someone needs to roll this back or do some bounds checking to ensure it doesn't overflow. I can't even understand why it is required. Anyone know why they need ms resolution counter in the middle of TCP?
I haven't experienced this bug yet myself as my Mac hasn't run long enough without a reboot (I had other problems like built-in processes eating memory, so I would restart to clear that out).
Why does the number of ticks need to be counted for the networking, and why in the heck did they use a 32-bit u_int? For a start it would make more sense to use a 64-bit value (what is the point of having 64-bit systems?!).
A similar bug exists in many routers for the same reason - they count bytes received and sent, and eventually overflow and crash or corrupt the router. This is why home routers need to be rebooted periodically otherwise things start breaking (I usually experience it as TLS connections failing specifically, followed by DNS lookup problems).
Programmers are getting to be pretty dumb. Someone needs to roll this back or do some bounds checking to ensure it doesn't overflow. I can't even understand why it is required. Anyone know why they need ms resolution counter in the middle of TCP?
I haven't experienced this bug yet myself as my Mac hasn't run long enough without a reboot (I had other problems like built-in processes eating memory, so I would restart to clear that out).
Read the actual document in the first post, particularly the "TIME_WAIT" section, to see why.
We Found a Ticking Time Bomb in macOS TCP Networking - It Detonates After Exactly 49 Days - Photon Blog
Photon powers conversational AI agents on iMessage, WhatsApp, Telegram, and more. Open-source Spectrum framework + SDK for seamless agent interactions.
photon.codes
That's the real question - probably an oversight of something that should have changed when MacOS/OS X went 64 bit years ago. Someone/some group just missed it.
I'm curious, since some commenters on MacTechNews and Proton have noticed this, whether it wasn't reported to Apple before. There was that public defect database, wasn't there?
On another note, when I was managing the website and archive for MGV Harmonia, my old notebook was also occasionally slow after weeks of only using sleep mode. Before anyone asks: the RAM and CPU usage hasn't changed. Everything's just running at a snail's pace.
On another note, when I was managing the website and archive for MGV Harmonia, my old notebook was also occasionally slow after weeks of only using sleep mode. Before anyone asks: the RAM and CPU usage hasn't changed. Everything's just running at a snail's pace.
Why 32-bit? TCP (unlike UDP) is a protocol for reliable transmission - no lost packets however bad the network medium. Lost packets are retransmitted and reassembled in the correct order. One method of assisting reliable transmission (RFC 1323 https://www.rfc-editor.org/rfc/rfc1323 and RFC 7323 https://www.rfc-editor.org/rfc/rfc7323) uses a monotonically increasing counter - in most systems every millisecond. The size of this counter is baked into the packet format as TCP Timestamp. This was at a time when 32 bits was a generous size and it still is more than sufficient for maintaining reliable transmission. The size of the TCP Timestamp is not going to change. It is up to each TCP implementation to manage what happens when this overflows and starts again from zero - and that has failed in Tahoe due to a change in the code.
It doesn't have to be a millisecond, so long as it is a monotonically increasing counter. Needs to be shorter than minimum transmission time. Most operating systems (which do implement TCP Timestamps) use a millisecond. As an aside, my understanding is that Windows since Windows 2008 does not implement TCP Timestamps.
Many routers use 32-bit unsigned integers to count bytes for statistical purposes. Network management systems reading those counters need to allow for overflow. This overflow can happen multiple times in a day (every 4 GBytes). They do not cause crashes of the router.
Last edited: