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
Every Mac has a hidden expiration date. After exactly 49 days, 17 hours, 2 minutes, and 47 seconds of continuous uptime, a 32-bit unsigned integer overflow in Apple's XNU kernel freezes the internal TCP timestamp clock. Once frozen, TIME_WAIT connections never expire, ephemeral ports slowly...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
Every Mac has a hidden expiration date. After exactly 49 days, 17 hours, 2 minutes, and 47 seconds of continuous uptime, a 32-bit unsigned integer overflow in Apple's XNU kernel freezes the internal TCP timestamp clock. Once frozen, TIME_WAIT connections never expire, ephemeral ports slowly...
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
Every Mac has a hidden expiration date. After exactly 49 days, 17 hours, 2 minutes, and 47 seconds of continuous uptime, a 32-bit unsigned integer overflow in Apple's XNU kernel freezes the internal TCP timestamp clock. Once frozen, TIME_WAIT connections never expire, ephemeral ports slowly...
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:
Alright everybody, here we go:
...and my Mac is running without issue. Remind me how to confirm that this bug is real and that I am affected? Since the initial claim was that every single Mac is affected. (I am running Sequoia 15.7.5 and was about to install 15.7.7 when I remembered this bug.)
Obviously I can still post here and I have multiple browsers open that all still load pages just fine, I still receive e-mails and so on.
Using the calculation from the original post results in Time until overflow: -31h -6m -54s confirming that the bug should have triggered 31 hours ago.
Running the code from the website that supposedly triggers more of these connections shows that if anything, my Mac is not affected:
The number goes up to 21 and then back down to where it was before.
This is the highest I was able to get the number but it clearly doesn't keep accumulating. So I'd say this supposed bug is hereby debunked.
Code:
Last login: Sat May 23 08:37:59 on ttys005
user@mac ~ % w
09:54 up 51 days, 1 min, 14 users, load averages: 5.48 6.24 5.50...and my Mac is running without issue. Remind me how to confirm that this bug is real and that I am affected? Since the initial claim was that every single Mac is affected. (I am running Sequoia 15.7.5 and was about to install 15.7.7 when I remembered this bug.)
Obviously I can still post here and I have multiple browsers open that all still load pages just fine, I still receive e-mails and so on.
Using the calculation from the original post results in Time until overflow: -31h -6m -54s confirming that the bug should have triggered 31 hours ago.
Code:
user@mac ~ % while true; do
tw=$(netstat -an | grep -c TIME_WAIT)
echo "$(date) TIME_WAIT=$tw"
sleep 5
done
Sat May 23 10:01:14 EST 2026 TIME_WAIT=11
Sat May 23 10:01:19 EST 2026 TIME_WAIT=12
Sat May 23 10:01:24 EST 2026 TIME_WAIT=9Running the code from the website that supposedly triggers more of these connections shows that if anything, my Mac is not affected:
Code:
Sat May 23 10:01:55 EST 2026 TIME_WAIT=12
Sat May 23 10:02:00 EST 2026 TIME_WAIT=11
Sat May 23 10:02:05 EST 2026 TIME_WAIT=10
Sat May 23 10:02:10 EST 2026 TIME_WAIT=10
Sat May 23 10:02:15 EST 2026 TIME_WAIT=11
Sat May 23 10:02:20 EST 2026 TIME_WAIT=11
Sat May 23 10:02:25 EST 2026 TIME_WAIT=21
Sat May 23 10:02:30 EST 2026 TIME_WAIT=21
Sat May 23 10:02:35 EST 2026 TIME_WAIT=21
Sat May 23 10:02:40 EST 2026 TIME_WAIT=21
Sat May 23 10:02:45 EST 2026 TIME_WAIT=21
Sat May 23 10:02:50 EST 2026 TIME_WAIT=20
Sat May 23 10:02:55 EST 2026 TIME_WAIT=12
Sat May 23 10:03:00 EST 2026 TIME_WAIT=12
Sat May 23 10:03:05 EST 2026 TIME_WAIT=13
Sat May 23 10:03:10 EST 2026 TIME_WAIT=12
Sat May 23 10:03:15 EST 2026 TIME_WAIT=13The number goes up to 21 and then back down to where it was before.
This is the highest I was able to get the number but it clearly doesn't keep accumulating. So I'd say this supposed bug is hereby debunked.
Code:
Sat May 23 10:21:31 EST 2026 TIME_WAIT=99
Sat May 23 10:21:36 EST 2026 TIME_WAIT=118
Sat May 23 10:21:41 EST 2026 TIME_WAIT=184
Sat May 23 10:21:46 EST 2026 TIME_WAIT=349
Sat May 23 10:21:51 EST 2026 TIME_WAIT=387
Sat May 23 10:21:56 EST 2026 TIME_WAIT=381
Sat May 23 10:22:01 EST 2026 TIME_WAIT=384
Sat May 23 10:22:06 EST 2026 TIME_WAIT=384
Sat May 23 10:22:11 EST 2026 TIME_WAIT=345
Sat May 23 10:22:16 EST 2026 TIME_WAIT=203
Sat May 23 10:22:21 EST 2026 TIME_WAIT=147
Sat May 23 10:22:26 EST 2026 TIME_WAIT=145
Last edited:
Calaveras
macrumors regular
This is neither helpful nor funny.
Do you go to the start menu and shut down your Mac when you are done or do you just close the lid. Are you sure it is shut down?
Leave a thumb drive plugged in and unplug it when the lid has been closed for several hours. What do you see? I see a 'device unplugged without ejecting' message. So closing the lid seems to only put the mac in hibernation or sleep no?
That is how most folks I know treat their Mac. So perhaps most of use with non-desktops are more susceptible than your little quip would lead them to believe.
Calaveras
macrumors regular
I'm intruiged, but I hate articles that start on the command line but fail to disclose all the commands they use to get the results they are showing. I'm not disputing their findings on that basis or implying anything shady. Merely that it's editorially weak af.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
Every Mac has a hidden expiration date. After exactly 49 days, 17 hours, 2 minutes, and 47 seconds of continuous uptime, a 32-bit unsigned integer overflow in Apple's XNU kernel freezes the internal TCP timestamp clock. Once frozen, TIME_WAIT connections never expire, ephemeral ports slowly...
Guess I'm exploring sysctl man pages this weekend.
I reboot my Mac for macOS updates and it's been 45 days between 15.7.5 which is what I'm running now and the next update that released last week (15.7.7, apparently there was no 15.7.6). This is my main work device that I can't interrupt during the week so it's this weekend that I finally found time. It's that easy to run into 50 days between reboots.
So why am I not seeing the evidence that this bug is real? Every Mac is supposedly affected, right?
The people who found this supposed bug claimed and I quote from the blog post "Every Mac has a hidden expiration date." and calling it a bomb that "detonates". But this is obviously not true. They claim I should now be seeing a "TIME_WAIT" value that increases well into the thousands and does not come down anymore. Yet the highest value I saw today was 387 where it plateaued during the script and now it's back to 11. Which is exactly what the blog post claims to be "healthy" behavior.
On top of that the blog post is from April but my macOS version is from March which rules out that Apple could have quietly fixed this in the background.
I am calling bogus on this one.
So why am I not seeing the evidence that this bug is real? Every Mac is supposedly affected, right?
The people who found this supposed bug claimed and I quote from the blog post "Every Mac has a hidden expiration date." and calling it a bomb that "detonates". But this is obviously not true. They claim I should now be seeing a "TIME_WAIT" value that increases well into the thousands and does not come down anymore. Yet the highest value I saw today was 387 where it plateaued during the script and now it's back to 11. Which is exactly what the blog post claims to be "healthy" behavior.
On top of that the blog post is from April but my macOS version is from March which rules out that Apple could have quietly fixed this in the background.
I am calling bogus on this one.