3.4 进程管理_进程终结

最新推荐文章于 2024-09-12 19:58:49 发布
原创 最新推荐文章于 2024-09-12 19:58:49 发布 · 357 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#编译器 #struct #语言 #工作 #c

本文介绍了进程终结时如何释放资源并通知父进程的过程。详细解释了进程析构发生在调用exit()之后，以及如何通过wait()函数获取子进程退出信息。

    当一个进程终结时，内核必须释放它所占有的资源并把这一不幸告知其父进程。

    一般说来，进程的析构发生在它调用exit()之后，既可能显示地调用这个系统调用，也可能隐式地从某个程序的主函数返回(其实C语言编译器会在main()函数的返回点后面放置调用exit()的代码)。

 

3.4.1 删除进程描述符

    在调用了do_exit()之后，尽管线程已经僵死不能再运行了，但是系统还保留了它的进程描述符。这样做可以让系统有办法在子进程终结后仍能获得它的信息。因此，进程终结时所需的清理工作和进程描述符的删除被分开执行。在父进程获得已终结的子进程的信息后，或者通知内核它并不关注那些信息后，子进程的task_struct结构才被释放。

    wait()的标准动作时挂起调用它的进程，直到其中的一个子进程退出，此时函数会返回该子进程的PID.   

Linux内核--进程管理(一)进程的概念控制单元
文艺小少年的博客
12-12 1055
本章开始，我们进入linux五大子系统之一的进程管理，本篇文章主要介绍进程的生命周期于内核中的控制单元
【操作系统】3.进程管理
愿万事胜意
06-24 2393
文章目录1. 进程和线程1.1 进程的概念进程的特点进程的组成进程与程序的联系进程与程序的区别1.2进程控制块(PCB)PCB的创建和回收进程控制块的内容：1.3 进程生命周期进程创建进程执行进程等待进程抢占进程唤醒进程结束1.4 进程状态变化模型1.5 进程挂起1.6 线程的概念1.7 用户线程与内核线程用户线程：内核线程线程和进程的区别2. 进程控制2.1 进程切换2.2 进程创建2.3 进程加载2.4 进程等待与退出3. CPU调度3.1 CPU调度概念3.2 调度准则3.3 就绪队列调度算法先来先服
Linux进程管理概述
小呆的博客
08-24 1227
Linux进程管理概述
Python菜鸟起飞day11_ 线程、进程、协程（二、多进程）
ihan.的博客
03-09 802
三、多进程 由于GIL的存在，python中的多线程其实并不是真正的多线程，如果想要充分地使用多核CPU的资源，在python中大部分情况需要使用多进程。 multiprocessing支持子进程、通信和共享数据、执行不同形式的同步，提供了Process、Queue、Pipe、Lock等组件。 　　multiprocessing包是Python中的多进程管理包。与threading.Thre...
Linux基础篇——Linux进程、服务管理
LXWalaz1s1s的博客
03-11 4241
程序（program）、进程（process）、守护进程（daemon）与服务（service）的之间是什么关系？简直一个头两个大，服务器之间的各个进程、服务又是怎么管理的呢？本篇文章，带你走进Linux进程（process）和服务（service）的世界。
Linux内核设计与实现_第三章 进程管理_学习笔记
qq_25626505的博客
05-20 215
3.1 进程 1） 程序与进程的区别 程序：就是程序正文与初始化的全局数据或静态数据，存放在磁盘上； 进程：exec将程序读入到内存空间，分配堆、栈、环境变量、bss数据段，内核再提供各种资源，使得程序得以运行，变成进程；（进程的其他资源：打开的文件， 挂起的信号， 内核内部数据， 处理器状态，寄存器值，线程等）； 程序不是进程，进程是执行器的程序以及相关资源的总称； 2） 线程 线程拥有独立的程序计数器、栈、一组寄存器； 3） linux的线程实现很特别， 不对线程和进程区分。内核调度的对象是线程，而不是
course2610_lab5 Linux 进程的概念
chumingqian的博客
05-05 107
1. 实验介绍 1.1 实验内容 Linux 中也难免遇到某个程序无响应的情况，可以通过一些命令来帮助我们让系统能够更流畅的运行。 而在此之前，我们需要对进程的基础知识有一定的了解，才能更好、更有效率的使用Linux 提供的工具。 1.2实验知识点 进程与程序 进程的衍生 工作管理 2. 概念理解 2.1 程序 程序（procedure）：不太精确地说，程序就是执行一系列有逻辑、有顺序结构的指令，帮我们达成某个结果。就如我们去餐馆，给服务员说我要牛肉盖浇饭，她执行了做牛肉盖浇饭这么一个程序，最后我们得
3.进程管理
PMSM_Driver的博客
07-09 399
在Linux中，除了init进程是手动创建外，其它进程都是通过fork()系统调用创建的，fork()通过复制现有进程来创建一个新进程。调用fork()的进程称为父进程，由fork()创建的进程称为子进程。进程除了程序（代码段，text_section）外，还包含了打开的文件、挂起的信号、内核内部数据、处理器状态、虚拟内存映射的内存空间地址、线程以及存放全局变量的数据段等。由fork()创建的进程不会马上执行，而是在调用exec()这组函数后，才会将新的程序装载到内存中。等待更新......
Linux系统下的进程管理利器：pkill命令详解
weixin_70208651的博客
09-12 3180
通过Linux中pkill命令的基本用法和常见选项，包括按用户名、命令行参数、完全匹配、进程组ID等条件终止进程。通过范例展示了pkill在终止特定进程（如top）、确认进程运行数量以及终止最新同名进程中的应用。最后通过和kill命令的对比展现了不同命令之间差异和用途上的殊途同归。虽然pkill一般情况下使用较为简单，但是结合支持的选项依旧可以实现不少功能。无论是使用pkill还是kill，都需要小心谨慎，在避免误杀重要的进程。终结进程前，最好能用pgrep等其他命令先测试匹配进程的准确性。
linux内核对孤儿进程寻父,Linux内核分析——第三章 进程管理(示例代码)
weixin_39842617的博客
04-30 152
第三章 进程管理3.1进程1、进程就是处于执行期的程序；进程就是正在执行的程序代码的实时结果；进程是处于执行期的程序以及相关的资源的总称；进程包括代码段和其他资源。线程：是在进程中活动的对象。2、执行线程，简称线程，是在进程中活动的对象。每个线程都拥有一个独立的程序计数器、进程栈和一组进程寄存器。3、内核调度的对象是线程，而不是进程。Linux对线程并不特别区分，视其为特殊的进程4、在现代操作系统...
Linux内核进程管理专题报告
phmatthaus的专栏
05-04 1064
一、引言 在Linux内核的五大组成部分（进程管理、内存管理、设备驱动、文件系统、网络协议）中，进程管理是非常重要的一部分，它虽然不像内存管理、虚拟文件系统那样复杂，也不像进程间通信那样条理化，但作为五大内核组成部分之一，进程管理对我们理解内核的运作、对于我们今后的编程非常重要。同时，作为五大组成部分的核心，它与其他四个模块都有联系。 因此，对于进程管理是必须要充分理解和掌握的。本文对进程管理进行详细的介绍，首先介绍进程及其相关的概念，而后介绍进程的创建、退出等基本操作以及线程的相关知识。 二、背景
Android进程系列1　杀进程实现原理
liuwg1226的专栏
03-06 1050
概述 文章理解Android进程创建流程，介绍了Android进程创建过程是如何从framework一步步走到虚拟机。本文正好相反则是说说进程是如何被kill的过程。简单说，kill进程其实是通过发送signal信号的方式来完成的。创建进程从Process.start开始说起，那么杀进程则相应从Process.killProcess开始讲起。 涉及代码如下： /framework/base/core/java/android/os/Process.java /framework/base/core/jni/
Python 多进程 multiprocessing 使用示例
墨鱼菜鸡
07-11 911
multiprocessing 文档：https://docs.python.org/zh-cn/3.10/library/multiprocessing.html Process、Lock、Semaphore、Queue、Pipe、Pool：https://cuiqingcai.com/3335.html 把一个多线程改成多进程，主要有下面几种方法：...
4.2 进程调度_Linux调度算法
cxf100900的专栏
07-29 1356
<br />    设计新的调度程序是为了实现下列目标:充分实现O(1)调度。不管有多少进程，新调度程序采用的每个算法都能在恒定时间内完成。强化SMP的亲和力。尽量将相关一组人物分配给一个CPU进行连续的执行。只有在需要平衡任务队列的大小时才在CPU之间移动进程。加强交互性能。即使在系统处于相当负载的情况下，也能保证系统的响应，并立即调度交互式进程。保证公平。在合理设定的时间范围内，没有进程会处于饥饿状态。同样的，也没有进程能够显失公平地得到大量时间片。虽然最常见的优化情况是系统中只有1~2个可运行进程，但
7.4 下半部和推后执行的工作_工作队列
cxf100900的专栏
08-27 1201
<br />    工作队列可以把工作推后，交由一个内核线程去执行--这个下半部分总是会在进程上下文执行。这样，通过工作队列执行的代码能占尽进程上下文的所有优势。最重要的就是工作队列允许重新调度甚至是睡眠。<br />    通常，在工作队列和软中断/tasklet中作出选择非常容易。如果推后执行的任务需要睡眠，那么就选择工作队列。如果推后执行的任务不需要睡眠，那么就选择软中断或tasklet。<br />    如果你需要用一个可以重新调度的实体执行你的下半部处理，你应该使用工作队列。它是唯一能在进程上下
6.3 中断和中断处理程序_注册中断处理程序
cxf100900的专栏
08-03 994
<br />    驱动程序可以通过下面的函数注册并激活一个中断处理程序，以便处理中断:int request_irq(unsigned int irq, irqreturn_t (*handler)(int, void *, struct pt_regs *), unsigned long irgflags, const char *devname, void *dev_id)<br />    第一个参数irq表示要分配的中断号。<br />    第二个参数handler是一个指针，指向处理这个中断的
4.3 进程调度_抢占和上下文切换
cxf100900的专栏
07-30 983
<br />    上下文切换，也就是从一个可执行进程切换到另一个可执行进程。<br />    内核提供了一个need_resched标志来表明是否需要重新执行一次调度。再返回用户空间以及从中断返回的时候，内核也会检查need_resched标志。每个进程都包含一个need_resched标志，这是因为访问进程描述符内的数值要比访问一个全局变量快。<br /> 4.3.1 用户抢占<br />    内核即将返回用户空间的时候，如果need_resched标志被设置，会导致schedule()被调用，此时
5.5 系统调用_系统调用上下文
cxf100900的专栏
07-31 851
<br />    内核在执行系统调用的时候处于进程上下文。在进程上下文中，内核可以休眠(比如在系统调用阻塞或显式调用schedule()的时候)并且可以被抢占。这两点都很重要。<br /> 5.5.1 绑定一个系统调用的最后步骤5.5.2 从用户空间访问系统调用<br /> 5.5.3 为什么不通过系统调用的方式实现
7.2 下半部和推后执行的工作_软中断
cxf100900的专栏
08-25 816
7.2.1 软中断的实现    软中断是在编译期间静态分配的。它不像tasklet那样能被动态地注册或去除。软中断由softirq_action结构表示，它定义在:struct softirq_action{    void (*action) (struct softirq_action *);    void *data;} 1. 软中断处理程序    一个软中断不会抢占另外一个软中断。实际上，唯一可以抢占软中断的是中断处理程序。不过，其他的软中断--甚至是相同类型的软中断--可以在其他处理器上同时执行
命令 sudo find / -name &#39;libstdc++.so.6*&#39; 2>/dev/null | xargs -I{} strings {} | grep GLIBCXX_3.4.29输出 GLIBCXX_3.4.29 GLIBCXX_3.4.29 GLIBCXX_3.4.29 GLIBCXX_3.4.29 GLIBCXX_3.4.29 GLIBCXX_3.4.29 GLIBCXX_3.4.29 GLIBCXX_3.4.29 GLIBCXX_3.4.29 GLIBCXX_3.4.29 GLIBCXX_3.4.29 GLIBCXX_3.4.29 GLIBCXX_3.4.29 GLIBCXX_3.4.29 GLIBCXX_3.4.29 GLIBCXX_3.4.29 GLIBCXX_3.4.29 GLIBCXX_3.4.29 GLIBCXX_3.4.29 GLIBCXX_3.4.29 GLIBCXX_3.4.29 GLIBCXX_3.4.29 GLIBCXX_3.4.29 GLIBCXX_3.4.29什么原因 怎么解决
最新发布
07-01
<think>我们遇到了一个RKNN构建错误，提示缺少GLIBCXX_3.4.29，但用户已经通过`strings`命令确认系统中存在该符号版本。这表明问题可能不在于缺失库文件，而在于运行时加载了错误版本的库。 ###问题原因分析1. **多版本库冲突**：系统可能存在多个`libstdc++.so.6`版本，而RKNN运行时加载了旧版本（不包含GLIBCXX_3.4.29）[^1]。 2. **环境变量覆盖**：`LD_LIBRARY_PATH`可能优先指向旧版库路径，导致新版库未被加载。 3. **RPATH设置**：RKNN的共享库（如`libcpputils.so`）可能硬编码了库搜索路径，覆盖系统默认路径。 4. **动态链接缓存未更新**：`ldconfig`缓存未刷新，导致旧版库仍被使用。###解决方案####步骤1：确认运行时加载的库版本```bash#检查RKNN进程实际加载的libstdc++.so.6路径ldd/usr/local/python3.10/lib/python3.10/site-packages/rknn/api/lib/linux-x86_64/cp310/libcpputils.so |grep libstdc++#输出示例： #libstdc++.so.6=> /old/path/libstdc++.so.6(0x00007f...)```若输出路径不是新版库（如指向`/usr/lib/x86_64-linux-gnu/`下的旧版），则需干预加载顺序。 ####步骤2：强制指定库路径（三种方法）#####方法1：设置`LD_LIBRARY_PATH`（临时） ```bash#定位包含GLIBCXX_3.4.29的libstdc++.so.6目录（如GCC11的路径）export LD_LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/11:$LD_LIBRARY_PATH#然后运行RKNN构建命令pythonyour_script.py```#####方法2：修改RPATH（永久）```bash#使用patchelf修改RKNN库的RPATH（需先安装patchelf）sudo aptinstall patchelf#Ubuntu/Debian#修改libcpputils.so的库搜索路径patchelf --set-rpath &#39;$ORIGIN:/usr/lib/gcc/x86_64-linux-gnu/11&#39; \/usr/local/python3.10/lib/python3.10/site-packages/rknn/api/lib/linux-x86_64/cp310/libcpputils.so```#####方法3：更新系统默认库链接```bash#确保新版库在ldconfig缓存中echo"/usr/lib/gcc/x86_64-linux-gnu/11"| sudotee /etc/ld.so.conf.d/gcc11.confsudoldconfig#检查是否已更新ldconfig -p |grep libstdc++.so.6```####步骤3：验证修复```bash#检查RKNN库的依赖解析ldd /usr/local/python3.10/lib/python3.10/site-packages/rknn/api/lib/linux-x86_64/cp310/libcpputils.so |grep libstdc++#应输出新版路径：=>/usr/lib/gcc/x86_64-linux-gnu/11/libstdc++.so.6```###根本原因与预防-**动态链接优先级规则**：Linux加载共享库时按以下顺序[^2]：1.可执行文件的RPATH2. `LD_LIBRARY_PATH`3.`/etc/ld.so.cache`4.默认路径（`/usr/lib`等）- **预防措施**：-使用容器（如Docker）隔离RKNN环境-在较新发行版（如Ubuntu22.04+）中部署###示例：在Ubuntu18.04上的完整修复流程```bash#安装GCC11sudoadd-apt-repository ppa:ubuntu-toolchain-r/testsudoapt updatesudoapt installgcc-11g++-11#确认新版库包含GLIBCXX_3.4.29strings/usr/lib/gcc/x86_64-linux-gnu/11/libstdc++.so.6| grepGLIBCXX_3.4.29#更新动态链接sudo ln-sf/usr/lib/gcc/x86_64-linux-gnu/11/libstdc++.so.6/usr/lib/x86_64-linux-gnu/sudo ldconfig#设置环境变量（可选） exportLD_LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/11:$LD_LIBRARY_PATH```> **注意**：如果系统中有其他应用依赖旧版库，建议使用`LD_LIBRARY_PATH`局部覆盖而非替换系统库。 通过上述调整，RKNN应能正确加载新版C++标准库，解决构建错误。###相关问题1.如何在不影响系统其他应用的情况下为特定程序升级`libstdc++`？2.RKNN模型部署时出现`undefinedsymbol:_ZSt24__throw_out_of_range_fmt...`该如何解决？3.使用Docker容器运行RKNN的最佳实践是什么？ 4.如何检查Linux动态链接库的加载顺序？</think>### RKNN构建错误：`GLIBCXX_3.4.29`存在但仍报错的原因与解决方案 #### 问题本质分析 当`strings`命令显示系统中存在`GLIBCXX_3.4.29`符号，但RKNN仍报告缺失时，核心问题在于**动态链接器未正确加载新版库**。根本原因如下： 1. **多版本库冲突** 系统存在多个`libstdc++.so.6`副本（如GCC 11和GCC 9共存），但RKNN通过`LD_LIBRARY_PATH`或`ldconfig`缓存加载了旧版本。 2. **路径优先级问题** `/usr/lib/x86_64-linux-gnu/`路径优先级高于`/usr/lib/gcc/`目录，导致旧版库被优先加载。 3. **硬编码RPATH干扰** RKNN的共享库（如`libcpputils.so`）可能包含硬编码的库搜索路径，覆盖系统默认路径[^1]。 --- ### 诊断与解决方案 #### 步骤1：确认运行时加载的库版本 ```bash # 检查RKNN实际加载的库路径 ldd /usr/local/python3.10/lib/python3.10/site-packages/rknn/api/lib/linux-x86_64/cp310/libcpputils.so | grep libstdc++ # 示例输出（问题场景）： # libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (旧版) ``` #### 步骤2：强制指定新版库路径（三种方法） ##### 方法1：设置`LD_LIBRARY_PATH`（推荐） ```bash # 定位包含GLIBCXX_3.4.29的库目录（如GCC 11的路径） export LD_LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/11:$LD_LIBRARY_PATH # 验证环境变量 echo $LD_LIBRARY_PATH ``` ##### 方法2：更新`ldconfig`缓存 ```bash # 添加新版库路径到配置文件 echo "/usr/lib/gcc/x86_64-linux-gnu/11" | sudo tee /etc/ld.so.conf.d/gcc11.conf # 更新动态链接器缓存 sudo ldconfig # 检查是否生效 ldconfig -p | grep libstdc++.so.6 ``` ##### 方法3：修改RPATH（高级） ```bash # 安装patchelf工具 sudo apt install patchelf # 修改RKNN库的RPATH指向新版 patchelf --set-rpath &#39;/usr/lib/gcc/x86_64-linux-gnu/11:$ORIGIN&#39; \ /usr/local/python3.10/lib/python3.10/site-packages/rknn/api/lib/linux-x86_64/cp310/libcpputils.so ``` #### 步骤3：验证修复效果 ```bash # 检查实际加载的库 ldd /path/to/libcpputils.so | grep libstdc++ # 应输出新版路径：=> /usr/lib/gcc/x86_64-linux-gnu/11/libstdc++.so.6 # 测试RKNN构建 python -c "from rknn.api import RKNN; print(RKNN().build())" ``` --- ### 根本原因详解 - **动态链接器工作原理** Linux加载共享库时按以下优先级[^2]： 1. 可执行文件的RPATH 2. `LD_LIBRARY_PATH`环境变量 3. `/etc/ld.so.cache`缓存 4. 默认系统路径`/usr/lib/` 当RKNN的库包含硬编码RPATH时，会跳过系统路径。 - **版本冲突示例** 假设系统中有： - GCC 9：`/usr/lib/gcc/x86_64-linux-gnu/9/libstdc++.so.6`（无GLIBCXX_3.4.29） - GCC 11：`/usr/lib/gcc/x86_64-linux-gnu/11/libstdc++.so.6`（含目标符号） 若`ldconfig`缓存指向GCC9路径，则报错发生。 --- ### 永久性解决方案 ```mermaid graph TD A[问题现象] --> B{检查库版本} B -->|strings 确认存在| C[诊断加载路径] C --> D[设置LD_LIBRARY_PATH] C --> E[更新ldconfig] C --> F[修改RPATH] D --> G[验证修复] E --> G F --> G G -->|成功| H[正常构建RKNN] G -->|失败| I[使用Docker容器] ``` #### 推荐：容器化方案（彻底隔离） ```dockerfile # Dockerfile示例 FROM ubuntu:22.04 RUN apt update && apt install -y python3-pip RUN pip install rknn-toolkit2 # 验证glibcxx版本 RUN strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBCXX_3.4.29 ``` 构建命令： ```bash docker build -t rknn_env . docker run -it --rm rknn_env python your_script.py ``` > **关键提示**：Ubuntu 22.04默认包含GCC 12（提供GLIBCXX_3.4.30），完全兼容此需求[^3]。 --- ### 相关问题 1. 如何在不影响其他应用的情况下为RKNN单独升级`libstdc++`？ 2. Docker容器中部署RKNN模型的最佳实践是什么？ 3. 如何检测Linux动态库的加载优先级？ 4. RKNN模型转换时出现`undefined symbol`错误如何解决？ 5. 多版本GCC共存时如何管理库依赖？
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值