TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

A very subtle bug (2010)

118 pointsby r4umover 1 year ago

8 comments

mprovostover 1 year ago
I&#x27;ve run into a similar issue in Rust with SIGPIPE. The compiler adds the call to signal() to ignore SIGPIPEs when a Rust program starts. Apparently this was to stop a listening server from exiting when a client closed their connection. But in my book I&#x27;m teaching Rust by rewriting a classic BSD utility (cat, head, wc, ...) in Rust and none of those utilities have to care about broken pipes because they don&#x27;t ignore the signal and the OS silently kills the process. Instead, if a Rust program doesn&#x27;t handle a write failing with a EPIPE error then the process panics and exits with a backtrace. The worst part is that Rust standard library doesn&#x27;t include a module for handling signals so it&#x27;s not possible to undo the signal() call ignoring SIGPIPEs without using another crate.<p>In the end it&#x27;s fine and you just have to handle broken pipes but it adds a lot of boilerplate to small CLI programs that in C just work as expected. Another twist (and possible further subtle bug) is that most shells set the exit status of a program that exits from a broken pipe to 141 (128 + the signal number, in this case 13). So when you catch the pipe you can exit the process with a status of 141, but that&#x27;s the shell&#x27;s behaviour and there&#x27;s no safe way to fake an exit status.
评论 #38364835 未加载
评论 #38364923 未加载
评论 #38369693 未加载
评论 #38374875 未加载
评论 #38364533 未加载
评论 #38377472 未加载
o11cover 1 year ago
The &quot;fix&quot; also has a bug - `preexec_fn` causes nasal demons if the current process has threads.<p>Fortunately, Python 3.2 added the `restore_signals` argument for exactly this purpose, and it is enabled by default. The (2010) in the title is quite relevant.
评论 #38366196 未加载
formerly_provenover 1 year ago
In my experience virtually every use of the subprocess module at the time of first writing contains at least one more or less subtle bug.
cabirumover 1 year ago
&gt; This code has a bug<p>From what I see, the code should be expected to work without requiring workarounds; instead, it is one of following:<p>- a python design problem<p>- gzip signal handling bug<p>- a flaw in linux pipe spec
评论 #38362892 未加载
评论 #38364864 未加载
评论 #38366474 未加载
tbm57over 1 year ago
this is clearly fixed by popen starting a docker container for the subprocess to run in
评论 #38367297 未加载
trompover 1 year ago
Related: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=22647539">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=22647539</a>
thirdplace_over 1 year ago
i think more bugs reside here.<p>if tarball or path is user input then they could be used to inject tar command options.
评论 #38362340 未加载
评论 #38363482 未加载
评论 #38363536 未加载
dveeden2over 1 year ago
Maybe better to use something like <a href="https:&#x2F;&#x2F;docs.python.org&#x2F;3&#x2F;library&#x2F;tarfile.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;docs.python.org&#x2F;3&#x2F;library&#x2F;tarfile.html</a> instead of calling some &quot;outside&quot; utilities?<p>This might be safer (command injection) and maybe more reliable.<p>However I don&#x27;t know what I would have chosen and hindsight is always 20&#x2F;20 and there might be other external commands and requirements...
评论 #38373353 未加载