TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

The case of the UI thread that hung in a kernel call

143 点作者 luu25 天前

14 条评论

simscitizen25 天前
Oh I&#x27;ve debugged this before. Native memory allocator had a scavenge function which suspended all other threads. Managed language runtime had a stop the world phase which suspended all mutator threads. They ran at about the same time and ended up suspending each other. To fix this you need to enforce some sort of hierarchy or mutual exclusion for suspension requests.<p>&gt; Why you should never suspend a thread in your own process.<p>This sounds like a good general princple but suspending threads in your own process is kind of necessary for e.g. many GC algorithms. Now imagine multiple of those runtimes running in the same process.
评论 #43698347 未加载
评论 #43700051 未加载
ot25 天前
On Linux you&#x27;d do this by sending a signal to the thread you want to analyze, and then the signal handler would take the stack trace and send it back to the watchdog.<p>The tricky part is ensuring that the signal handler code is async-signal-safe (which pretty much boils down to &quot;ensure you&#x27;re not acquiring any locks and be careful about reentrant code&quot;), but at least that only has to be verified for a self-contained small function.<p>Is there anything similar to signals on Windows?
评论 #43696831 未加载
ryao24 天前
Who are these customers that get developer support from Microsoft engineering teams?
评论 #43702687 未加载
评论 #43702266 未加载
评论 #43703237 未加载
评论 #43702315 未加载
zavec25 天前
I knew from seeing a title like that on microsoft.com that it was going to be a Raymond Chen post! He writes fascinating stuff.
评论 #43698628 未加载
评论 #43701232 未加载
评论 #43700080 未加载
pitterpatter25 天前
Reminds me of a hang in the Settings UI that was because it would get stuck on an RPC call to some service.<p>Why was the service holding things up? Because it was waiting on acquiring a lock held by one of its other threads.<p>What was that other thread doing? It was deadlocked because it tried to recursively acquire an exclusive srwlock (exactly what the docs say will happen if you try).<p>Why was it even trying to reacquire said lock? Ultimately because of a buffer overrun that ended up overwriting some important structures.
boxed25 天前
I had a support issue once at a well known and big US defense firm. We got kernel hangs consistently in kernel space from normal user-level code. Crazy shit. I opened a support issue which eventually got closed because we used an old compiler. Fun times.
评论 #43702943 未加载
markus_zhang25 天前
Although I understand nothing from these posts, read Raymond&#x27;s posts somehow always &quot;tranquil&quot; my inner struggles.<p>Just curious, is this customer a game studio? I have never done any serious system programming but the gist feels like one.
评论 #43697987 未加载
saagarjha24 天前
&gt; If you want to suspend a thread and capture stacks from it, you’ll have to do it from another process, so that you don’t deadlock with the thread you suspended.<p>Unfortunately sometimes you don&#x27;t have the luxury of being able to do this (e.g. on iOS, especially pre-MetricKit). We shipped one such implementation in the Twitter app (which was still there last I checked) and as far as I can tell it&#x27;s safe but mostly by accident–I didn&#x27;t want to to pause things for very long, so the code just suspends the thread, grabs register state, then writes the backtrace to a stack buffer before resuming. I originally wanted to grab traces without suspending the process, which is something you can actually &quot;do&quot; because getting register state doesn&#x27;t require suspension and you need to put guards on your frame decoding anyway (&quot;is this address I am about to dereference actually in the stack?&quot;). But unfortunately after thinking about it I added the suspension back because trying to collect a trace from a running thread could give you a fragmented backtrace as it modifies it out from under you.
rat8725 天前
Reminds me of a bug that would bluescreen windows if I stopped Visual Studio debugging if it was in the middle of calling the native Ping from C#
评论 #43698343 未加载
Permik24 天前
I have the weirdest hunch that the customer in question was Valve :D
frabona25 天前
Such a clean breakdown. &quot;Don’t suspend your own threads&quot; should be tattooed on every Windows dev’s arm at this point
makz25 天前
Looking at the title, at first I thought “uh?”, but then I saw microsoft and it made sense.
baruchthescribe24 天前
&gt;Naturally, a suspended UI thread is going to manifest itself as a hang.<p>The correct terminology is &#x27;stopped responding&#x27; Raymond. You need to consult the style guide.
brcmthrowaway25 天前
Can this happen with Grand Central Dispatch ?
评论 #43702932 未加载
评论 #43699077 未加载