问题标签 [sigpipe]

我在我的 iPhone 应用程序中使用AsyncUDPSocket第三方库，并且在大多数情况下它工作得很好。我有一个AsyncUDPSocket用于所有网络流量的单例实例。我的应用程序在后台注册了位置跟踪，并且在后台运行时将唤醒并通过网络发送位置更新数据包。这一切都在后台，前台，手机锁定或解锁中运行，除非我执行以下操作：

1. 启动我的应用
2. 在我的应用设置中禁用位置跟踪（因此没有后台唤醒）
3. 按下主页按钮（应用程序进入后台，套接字与应用程序的其余部分“冻干”）
4. 锁定手机
5. 解锁手机
6. 简历应用
7. 尝试重新启动跟踪并从套接字发送一些东西。我一尝试，就会收到SIGPIPE/EPIPE错误并且应用程序崩溃。

我认为处理此问题的最佳方法是在应用程序退出且未启用后台跟踪时关闭并释放套接字，但是当我尝试[socket close]或[socket release]打开时AsyncUDPSocket，我会收到各种EXC_BAD_ACCESS错误。我已经向开发团队提交了一个错误，但想知道这里是否有人可以就如何SIGPIPE完全避免错误或其他方式在不释放套接字的情况下保持套接字存活提出一些想法。谢谢。

我刚刚了解了 SIGPIPE，然后阅读了如何在 Python 中处理这些。

在其他来源中，我读过：如何在 python 中处理损坏的管道（SIGPIPE）？

假设管道读取脚本退出，那么所有答案都表明写入脚本将其写入调用包装在 try 子句中。

但是，我无法完成这项工作。这是我的代码：

和

在外壳中：

显然，什么都没有抓到。此外，当它打印“原始异常是：”时，它看起来真的错了，然后就没有了。

出了什么问题/我误解了什么？

托马斯

如果我有一个管道来运行某些命令，则管道命令需要进行一些清理，但是，如果启动管道的进程有错误，则管道命令不会清理。在这种情况下，管道命令是否获得 SIGPIPE？如何确保 cleanupPipe 析构函数始终运行？当 errorOccurred 异常被抛出时，我看到 cleanupPipe 析构函数没有运行。我设置了 SIGPIPE 处理程序以引发异常，因此如果 SIGPIPE 是结果，我希望我的析构函数在 SIGPIPE 导致抛出异常展开堆栈时运行。

我尝试制作一个可以连接到 FTP 服务器的应用程序。我使用 Chilkat 库来做这个连接。问题是，我想测试我的应用程序并建立错误的连接。所以我连接到我的 FTP 服务器，但使用 SSL 连接（基于 Chilkat示例代码中的 chilkat 示例，用于隐式 SSL 连接）

仅供参考，我没有在我的 FTP 服务器中设置 SSL。在设备上运行我的代码后，应用程序崩溃了，调试器显示了 SIGPIPE。我知道 SIGPIPE 是因为我建立了错误的套接字连接，但我不知道如何处理它。我在这个链接上读过一篇关于未捕获异常的文章，但我不知道如何实现这些。

有人可以告诉我，如何处理这些 SIGPIPE 异常吗？

我正在处理一项任务，该任务涉及编写一个程序来使用 fork（进程）、信号和选择来处理数据（计算 pi）。

我现在正在处理信号，我想我想做的是使用 SIGPIPE 所以如果程序捕获它，它会尝试再次写入管道（如果进程尝试写入没有阅读器的管道, 它将被发送 SIGPIPE)。

我在 main() 中使用 fork() 通过将它们发送到工作函数来为每个进程分配相同的工作。

如何在此函数中实现信号以捕获 SIGPIPE 并使其再次写入管道？

谢谢！

我有两个守护进程，A 正在与 B 通话。B 正在监听一个端口，A 打开一个到该端口的 tcp 连接。A 能够为 B 打开一个套接字，但是当它尝试实际写入所述套接字时，我得到一个 SIGPIPE，所以我试图找出 B 可能在哪里关闭打开的套接字。

但是，如果我附加到 gdb 中的两个守护进程，则 SIGPIPE 会在调用任何处理数据的代码之前发生。这种方式是有道理的，因为初始写入永远不会成功，并且侦听器是从接收数据触发的。我的问题是 - 什么会导致守护进程 B 在发送任何数据之前关闭套接字？套接字在打开后不到一微秒就关闭了，所以我认为它不可能是超时或类似的东西。我想要一份可以追踪的可能性清单，因为我已经研究了几天，而且我几乎没有想法。

根据要求，这是接受和处理通信的代码：

注意：我没有编写此代码。

我有一个 Linux 进程（我们称之为主进程），它的标准输出通过 shell 的管道运算符 (|) 传送到另一个进程（称为下游进程）。主进程设置为在下游进程崩溃时接收 SIGPIPE 信号。不幸的是，在主进程写入标准输出之前，不会引发 SIGPIPE。有没有办法更快地告诉下游进程已经终止？

一种方法是连续写入下游进程，但这似乎很浪费。另一种方法是有一个单独的看门狗进程来监控所有相关进程，但这很复杂。或者也许有一些方法可以使用 select() 来触发信号。我希望主进程可以自己完成这一切。

我想知道 tcp socket 是否有可能立即报告任何损坏的管道错误。目前，当服务器出现故障时，我正在客户端捕获 sigpipe 信号......但我发现只有在从客户端向服务器发送第二个 msg 后才会生成 sigpipe 信号。这可能是什么原因？如果另一个套接字端出现故障，那么第一次发送必须返回 sigpipe .. y 不是立即生成的信号..?? 这种特殊行为有什么可能的解释吗？以及任何可能的方法来解决这个问题？

我是网络编程的新手，并且通过编写使用 Socket API 的小程序来学习这一点。目前，我正在编写一个简单的回显服务器，它使用 fork 创建它的副本，一旦它收到连接请求，这加起来就像对以前的迭代 服务器(here)的改进一样。但是，在我启动服务器并启动客户端并在其控制台上键入一条消息后，它意外退出。在 Gdb 下运行程序显示SIGPIPE已交付。但据我所知，套接字仍然有效，不应该发生 SIGPIPE。任何涉及的帮助表示赞赏。这是客户端代码

这是服务器代码

我写了一个 Rmpi​​ 代码，希望主人与奴隶平等地分担工作负担。因此，函数work_by_master会在进行发送-接收以交换结果之前mpi.bcast.cmd对其进行work_by_slaves调用。work_to_be_done_per_process

我不断收到一个错误：

我很难理解错误是什么，最后在投入大量时间后，间接意识到错误可能来自奴隶无法以嵌套方式调用用户定义函数的事实。当我合并并只让主调用时work_to_be_done_per_process，错误就解决了。work_by_slaveswork_to_be_done_per_process

我还将函数复制work_to_be_done_per_process到work_to_be_done_per_process_by_slavesandwork_to_be_done_per_process_by_master中，让从属和主控分别调用它们。即使这样也没有解决问题。因此，似乎只有我的上述结论是原因。

这是真的吗？有没有其他人也遇到过从机无法从内部调用用户定义函数的问题？有没有办法正确地做到这一点。