线程问题——同样的程序,在ubuntu中运行和嵌入式中PID表现不同的原因

最新推荐文章于 2025-01-15 21:42:10 发布
原创 最新推荐文章于 2025-01-15 21:42:10 发布 · 2.8k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#ubuntu #嵌入式 #library #linux #system #多线程

本文探讨了Ubuntu与嵌入式Linux环境下线程库的不同，如NPTL与linuxthreads，并解释了它们如何影响进程显示，通过实例展示了在Ubuntu与目标板上运行同一程序时的PID差异。
 

1. 同一多线程程序，经过编译和交叉编译后，在ubuntu和在我们的ARM板的嵌入式LINUX中运行时候，通过ps 看到的信息不一致：
   比如：同样的attr_thread这个程序：
   ubuntu中运行后，通过ps -aux只能看到一个进程在运行
   目标板中运行后，通过ps 能看到4个进程在运行，但运行的程序名字是一致的

原因：
   ubuntu中使用NPTL线程库,目标板中使用linuxthreads线程库
  
   NPTL从一个进程中所有的线程中运行getpid()获取到得PID值相同
   而linuxthreads每个线程使用不同的PID,从一个进程中不同线程中运行getpid()获取到得PID值不相同

2. 确认系统中线程库是那一种的方法：

   查看方法可以通过运行/lib/libc.so.6 可看到：
 
ubuntu中如下：
  shyi@ubuntu:~/labs/1106/labs/threads$ /lib/libc.so.6
GNU C Library (Ubuntu EGLIBC 2.12.1-0ubuntu6) stable release version 2.12.1, by Roland McGrath et al.
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.5 20100909 (prerelease).
Compiled on a Linux 2.6.35 system on 2010-09-10.
Available extensions:
        crypt add-on version 2.1 by Michael Glad and others
        GNU Libidn by Simon Josefsson
        Native POSIX Threads Library by Ulrich Drepper et al  （这一行是重点，表示这是NPTL）
        BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.


目标板上：
# /lib/libc.so.6
GNU C Library stable release version 2.3.6, by Roland McGrath et al.
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.4.5.
Compiled on a Linux 2.6.12 system on 2008-09-10.
Available extensions:

        GNU libio by Per Bothner
        crypt add-on version 2.1 by Michael Glad and others
        linuxthreads-0.10 by Xavier Leroy  （这一行是重点，表示这是linuxthreads）                   
        BIND-8.2.3-T5B
        libthread_db work sponsored by Alpha Processor Inc
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.  

嵌入式linux系统中压力测试的方法
嵌入式技术开发
07-24 1169
通过这种方法，不仅能够确保负载的管理，在系统极限状态下，也能确保数据的安全和完整。fio 可以模拟多种不同类型的I/O工作负载，包括顺序读写和随机读写，并且可以详细设定每次I/O操作的大小、I/O深度、队列长度等，这样可以更真实地模拟应用程序对磁盘的使用模式。sysbench 是一款强大的多线程系统评测和基准测试工具，它对于评估各种系统参数的性能非常有用，包括：CPU性能、磁盘I/O性能、调度程序性能、内存分配和传输速度、POSIX线程的性能、数据库的性能（特别有名的是MySQL数据库的测试）。
Linux C/C++ or 嵌入式面试之《多进程多线程编程系列》(4) 进程同步和通信的方式有哪些？
二进制君
08-16 1万+
🥇 作者简介： 热衷于知识探索和分享的技术博主。💂 csdn主页:：【✍️ 微信公众号：【🎉精彩专栏：🎓 【​ 🧡 【​ 📚【​ 🌎【✍️ 【​ …💂关于作者: 曾就职于国内知名安防上市公司，现就职于国内知名AMR机器人公司，担任高级系统软件工程师。2020年至今保持优快云博客专家，优快云 C/C++领域优质创作者头衔。全网5万+粉丝。十载寒冰，难凉热血；多年过去，历经变迁，物是人非。然而，对于技术的探索和追求从未停歇。💪坚持创作，热衷分享，初心未改，继往开来！
服务启动与应用程序的启动的差别
lijigang1982的专栏
03-21 1791
服务启动与应用程序的启动的差别，一直以来很模糊，今天看书的时候注意到了，特摘录下来，以备日后查看！1、服务是与用户无关的，只要设置妥当，服务会在操作系统启动后就由服务控制器来启动它，只要未关机，服务就一直在执行；而应用程序一定得在用户登陆后才能执行，而且用户退出时，应用程序也会关闭。2、服务具有自己的logon session，或者与其它的服务分享同一个session，因此可以将服务设置为
程序自启动和手动启动区别
专注技术分享
08-23 3252
区别 自动运行要考虑如何加载环境变量； 手动运行在用户登陆的时候，环境变量已经加载了 解决 自动运行缺少环境变量时要加上环境变量 source /etc/profile source ~/.bashrc 例如： #!/bin/bash sec=100000 source /etc/profile source ~/.bashrc while true do ocrThread=`ps -...
libc
happykillerxxx的专栏
12-06 337
$ ldd a.out     linux-vdso.so.1 =&gt;  (0x00007fd7ea05b000)     libc.so.6 =&gt; /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd7e9c66000)     /lib64/ld-linux-x86-64.so.2 (0x00005604828b7000) $ $ /lib/{x86...
linux进程pid一直在改变,在linux环境下关于java获取进程PID的有关问题
weixin_39884144的博客
04-29 1889
Java codeimport java.io.*;import java.util.regex.*;public class GetPID {public static void main(String[] args) {Process process = null;BufferedReader br = null;try {process = Runtime.getRuntime().exec...
嵌入式软件错误的五个主要原因
BeginnerMind
11-21 1648
嵌入式软件错误的五个主要原因 在嵌入式开发软件中查找和消除潜在的错误是一项艰巨的任务。 通常需要英勇的努力和昂贵的工具才能从观察到的崩溃，死机或其他计划外的运行时行为追溯到根本原因。 在最坏的情况下，根本原因会破坏代码或数据，使系统看起来仍然可以正常工作或至少在一段时间内仍能正常工作。 工程师常常放弃尝试发现不常见异常的原因，这些异常在实验室中不易再现，将其视为用户错误或“小故障”。 然而，机器中的这些鬼魂仍然存在。这是难以重现错误的最常见根本原因指南。每当您阅读固件源代码时，请查找以下五个主要错误。并遵
【进程与线程】进程的PID
猫猫的小茶馆
01-15 1727
PID（Process Identifier，进程标识符）是操作系统为每个进程分配的一个唯一标识，用于标识系统中的每个进程。PID 是一个非负整数，通常从 1 开始分配；每个运行中的进程都有一个唯一的 PID，通过 PID，操作系统可以区分不同的进程并对它们进行管理。简单点理解为操作系统为进程分配的身份证号。
嵌入式中的多核开发和核间通信总结
qq_28576837的博客
09-24 3561
而如果采用高速并口，则占用管脚多，硬件成本将会增加。在M核，将Virtio移植，并使用简化版的RPMsg，因为涉及到互斥锁和信号量，最终使用FreeRTOS完成过程的封装，流程框图如下方所示。处理器支持消息传递单元（MessagingUnit，简称MU）功能模块，通过MU传递消息进行通信和协调，芯片内的M控制核和A处理核通过通过寄存器中断的方式传递命令，最多支持4组MU双向传递消息，既可通过中断告知对方数据传递的状态，也可发送最多4字节数据，还可在低功耗模式下唤醒对方，是保证双核通信实时性的重要手段。
嵌入式 线程与进程
smile3333的博客
05-04 731
1. 查看源代码 1. 线程与进程 在一些操作中，等待的时间是比较长的，为避免卡顿，或者反应不及时引入线程和进程。 进程是资源分配的最小单位，线程是CPU调度的最小单位。 单进程单线程：一个人在一个桌子上吃菜。 单进程多线程：多个人在同一个桌子上一起吃菜。 多进程单线程：多个人每个人在自己的桌子上吃菜。 ubuntu默认没有pthread库，需要安装。 sudo apt-get install -y glibc-doc manpages-posix-dev 查看pthrea手册，提示： $ ma
浅谈PID
You Only Live Once
08-01 883
p:误差比例项 ，如果偏差为0，则比例环节不起作用，只有存在偏差时，比例环节才起作用。 【在没有i的情况下存在静差：输入调整温度10度--》|外界环境降低1度 | --输出9度》--反馈给输入：调整10度】 比例 i:误差的累计 ，积分环节主要用来消除静差，所谓静差，就是系统稳定后输出值和设定值之间的差值，积分环节实际上就是 偏差累计的过程，把累计的误差加到原有系统上以抵消系统造成的静差。 【就是系数 i * 所有误差的和】 积分 d：误差的差值 微分信号这是反应了偏差信...
gcc链接介绍
实践求真知
03-10 2406
一点睛 在成功汇编之后，就进入了链接阶段。链接主要是为了解决多个文件之间符号引用的问题。编译时编译器只对单个文件进行处理，如果该文件里面需要引用到其他文件中符号（例如全局变量或者某个函数库中的函数），那么这时在这个文件中该符号的地址是没法确定的，只能等链接器把所有的目标文件连接到一起才能确定最终的地址，最终生成可执行文件。 当所有目标文件都生成之后，gcc就在内部调用链接器ld完成链接工作。...
第33章 线程:更多细节
u010783439的博客
07-01 157
不要将线程与信号混合使用，只要可能多线程应用程序的设计应该避免使用信号。如果多线程应用必须处理异步信号的话，通常zuijianjie-的方法是所有的线程都阻塞信号，创建一个专门的线程调用sigwait()函数（或者类似的函数）来接收收到的信号。这个线程就可以安全地执行像修改共享内存（处于互斥量的保护之下）和调用非异步信号安全的函数。
进程与线程
m0_62360856的博客
11-29 480
进程与线程详细介绍
linxu 线程kill不掉，线程PID一直在变
热门推荐
qq_44086060的博客
03-16 33万+
问题描述 centos7.9系统，运行了一个jar包，想把它停掉，但是怎么kill都杀不死 查看服务名：ps -ef | grep oys-core-4.0-SNAPSHOT.jar 查看得知进程PID = 12906 kill -9 12906 杀死进程，发现线程不存在 再次查看服务名：ps -ef | grep oys-core-4.0-SNAPSHOT.jar ，发现线程PID变了 解释： 那是因为oys-core-4.0-SNAPSHOT.jar 根本就没有启动进程，看到的进程是grep指令的
嵌入式开发--PID控制
深圳五月花--老李的森林
12-26 2238
讲解PID的文章书籍很多，本文就不详细讲了，只讲一下我在学习过程中不容易理解的一些问题点，以供大家参考。比如很多书籍对于PID，只讲了计算，但是最后计算出来的值如何应用，则完全不讲，当时我是一头雾水，后来搞明白以后又觉得还是很简单的，但如果书籍里面能提一下，那不是让人学习起来容易很多么。 PID就是比例，积分，微分三个单词的首字母缩写，是工程上控制系统中的一个常用控制算法。以下结合我之前做过的一个温度控制的项目来介绍PID。用的是当时保留下来的一些调试图片，供参考。 PID有两种控制方式，增量式和位置式，二
linux中pid gid tgid tid的区别和联系
hunter
10-12 2284
    https://blog.youkuaiyun.com/techtitan/article/details/39134927 getpid ： 取得process id，对于thread，就是取得线程对应进程的id； 对应的system call：  asmlinkage long sys_getpid(void) 1614 { 1615         return current-&gt;t...
linux获取当前进程进程号,Linux内核获取当前进程结构的current宏
weixin_31440053的博客
04-28 2597
上篇文章Linux内核的源码结构简介(1)简单介绍了Linux内核源码的目录结构，以及和进程的task_struct的几个关键变量，最后提到了在内核里获取当前进程的pid的代码：current->pid。current，属于内核的一个宏，指向get_current()函数。#define current get_current()所以代码current，实际是获取get_current()函...
使用嵌入式模块ESM8400开发的Qt6.7的程序，cpu是 i.mx8 plus芯片，窗口管理器是weston。频繁切换画面时，程序画面会卡死，但是进程还在执行，程序网络通讯也正常。然后强制杀死进程后，卡死的画面依然不变。执行 systemctl restart weston 也长时间无响应；若要嵌入式恢复之前的正常运行，必须要重新上电执行程序才可以，。同样的程序在虚拟计算机ubuntu20.04系统中，可以长时间执行无故障运行。这最最可能是什么原因？按照可能性高低回答。
最新发布
12-02
<think> 我们面对的是一个在特定嵌入式环境下（ESM8400模块、i.mx8 plus芯片、Weston窗口管理器、Qt6.7）的图形界面卡死问题。问题现象描述如下： 1. 频繁切换画面时卡死 2. 进程和网络通讯正常（说明应用主逻辑和网络部分还在运行） 3. 强制杀死进程后画面不变（说明图形界面已经冻结） 4. 重启weston无响应（说明问题可能涉及窗口管理器的底层） 5. 必须重新上电才能恢复 根据以上现象，我们可以推断问题可能发生在图形渲染和显示相关的环节，尤其是与硬件加速、GPU驱动、显示缓冲区管理、窗口管理器和Qt图形渲染集成相关的部分。 按照可能性从高到低分析原因： ### 1. GPU驱动或硬件加速相关的问题（高可能性） - i.MX8 Plus芯片内置GPU（GC7000UL/Vulkan），Qt6.7在嵌入式Linux平台上通常会使用EGLFS或Wayland后端进行硬件加速渲染。 - 频繁切换画面可能导致GPU资源（如显存）耗尽或泄露，或者驱动内部状态异常（例如：命令队列阻塞、GPU挂起）。 - 由于GPU驱动是内核模块的一部分，一旦GPU驱动进入错误状态，可能导致整个显示系统无响应，即使重启Weston（它在启动时会尝试初始化GPU）也无法恢复，因为GPU硬件状态没有复位，需要重新上电才能复位硬件。 - 证据支持：杀死Qt进程后画面不变，重启Weston无响应，必须重新上电。这非常符合GPU驱动/硬件故障的特征。 ### 2. Weston窗口管理器的Wayland协议栈问题（中高可能性） - Weston是Wayland的参考窗口管理器。Qt6.7在Wayland环境下运行，频繁切换画面（窗口）可能导致Wayland协议处理错误（如：资源泄露、协议错误处理不当）。 - 如果Weston的服务端（compositor）在处理某些客户端（Qt应用）的请求时发生死锁或资源耗尽，可能导致整个Weston无响应。 - 杀死Qt进程后，Weston可能仍然处于错误状态，无法处理新的启动请求（或者已经崩溃但进程还在）。重启Weston需要重新初始化整个显示系统，但如果GPU驱动已经处于错误状态，则重启Weston也会失败。 - 注意：问题中提到重启Weston无响应，说明Weston可能无法重新启动，这指向底层资源（如DRM/KMS）被占用或处于无效状态。 ### 3. Qt图形渲染引擎的缺陷（中等可能性） - Qt6.7版本可能存在与i.MX8平台相关的渲染缺陷。例如，在频繁创建和销毁窗口/场景时，Qt的图形场景管理（Scene Graph）可能出现内存泄露或资源未释放，导致GPU资源耗尽。 - 另外，Qt的Wayland集成可能存在特定问题，比如在快速切换窗口时，没有正确销毁和释放Wayland资源（wl_surface, wl_buffer等），导致Weston端的资源耗尽（如达到最大允许的surface数量）。 - 但这一原因通常会导致Qt进程崩溃或变慢，而不会导致整个Weston无法重启。因此，结合重启Weston失败的现象，这个原因的可能性低于前两个。 ### 4. 显示框架（DRM/KMS）问题（中等可能性） - Linux内核的DRM（Direct Rendering Manager）子系统和KMS（Kernel Mode Setting）负责管理显示输出。如果DRM驱动（如imx-drm）存在缺陷，比如在多次模式设置或页面翻转（page flipping）后进入错误状态，那么显示输出将被冻结。 - 杀死Qt进程并不会影响内核中的DRM状态，重启Weston会尝试重新初始化DRM，但如果DRM驱动已经处于错误状态，初始化就会失败，导致Weston无法启动。 - 重新上电会复位整个硬件和驱动状态，因此可以恢复。 ### 5. 内存泄露或资源耗尽（中等可能性，但指向特定组件） - 虽然进程和网络正常，但图形相关资源（如GPU显存、DRM资源、Wayland资源）可能被耗尽。例如： - Weston的Wayland资源（wl_display管理的资源）泄露。 - Qt应用未释放的GPU缓冲区（如未销毁的纹理、帧缓冲区）。 - 内核DRM资源泄露（如未关闭的DRM句柄、未释放的framebuffer）。 - 资源耗尽会导致后续的图形操作失败，从而卡死。但同样，需要解释为何重启Weston也无法恢复。可能的解释是资源泄露发生在内核模块（如GPU驱动）中，而这些资源不会因用户空间进程退出而释放。 ### 6. 多线程死锁（低可能性） - 在Qt应用程序内部，或者Qt与Weston之间的交互中，可能存在多线程死锁。例如，Qt的渲染线程与事件线程之间，或者与Wayland通信线程之间的死锁。但通常死锁只会影响当前进程，不会导致重启Weston失败。因此，这一原因的可能性较低。 ### 根本原因排查建议 1. **收集日志**： - 在内核启动参数中添加`debug`（如`loglevel=8`）并启用GPU驱动和DRM的调试日志（例如，在模块加载时传递调试参数：`modprobe imxgpu debug=0x1`或`modprobe imxdrm debug=0x1`）。 - 启用Weston的详细日志（启动Weston时加上`--log=wayland-debug.log`）。 - 在Qt应用启动时设置环境变量`QT_LOGGING_RULES=qt.scenegraph.general=true`以启用Scene Graph的日志。 2. **监控资源使用**： - 通过`cat /proc/interrupts`监控GPU中断是否在卡死后停止（表明GPU停止工作）。 - 监控内存和显存使用：使用`gmeminfo`（如果可用）或`cat /sys/kernel/debug/gc/meminfo`（路径可能不同）查看GPU内存使用情况。 3. **工具调试**： - 使用`gdb`附加到Qt进程（如果可能）或生成coredump，分析卡死时的线程堆栈。 - 使用`wayland-info`工具检查Wayland资源使用情况。 4. **版本验证**： - 检查使用的GPU驱动（内核模块）版本、Weston版本和Qt版本是否都有已知问题。特别是查看NXP官方提供的BSP（Board Support Package）中是否有类似问题的修复。 5. **压力测试**： - 编写一个简单的测试程序（不使用Qt，仅使用Wayland客户端或DRM直接渲染）进行频繁的画面切换，以排除Qt的影响。 ### 总结 最可能的原因是**GPU驱动或硬件加速模块的缺陷**导致在频繁切换画面时GPU进入不可恢复的错误状态，其次是**Weston窗口管理器在处理Qt快速创建和销毁窗口时发生资源耗尽或死锁**。这两个原因都可能导致整个图形系统冻结，且无法通过重启用户空间组件（Weston）恢复，必须复位硬件。 §§相关问题§§ 1. 如何为i.MX8 Plus平台启用GPU驱动调试日志？ 2. 在Weston中，如何监控Wayland客户端（如Qt应用）的资源使用情况？ 3. 如何确认Qt6.7在i.MX8平台使用的是Wayland后端？ 4. 在嵌入式Linux中，如何调试DRM/KMS问题？ 5. 如何检测GPU显存泄露？ </think>基于ESM8400模块(i.MX8 Plus芯片)、Weston窗口管理器和Qt6.7应用的卡死问题分析，按可能性高低排序的原因如下： ### 高可能性原因 1. **GPU显存泄漏/耗尽**（最可能） Qt6.7的硬件加速渲染可能导致GPU显存管理异常。频繁切换画面时，OpenGL/Vulkan资源未正确释放，最终耗尽显存。 *现象关联*：杀进程后画面冻结、重启Weston无效，因GPU驱动需硬复位恢复状态[^1]。 2. **Weston合成器资源枯竭** Weston的Wayland协议栈在处理Qt频繁创建/销毁的`wl_surface`时，可能出现： - 未释放的缓冲区（`wl_buffer`泄露） - 合成器线程死锁（如帧回调阻塞） *证据*：重启Weston无响应，需重置整个显示管线[^2]。 3. **Qt场景图(Scene Graph)缺陷** Qt Quick的渲染树在动态场景切换中可能出现： ```cpp // 疑似问题点：纹理异步加载未同步 QQuickImage { source: "dynamic_texture.png" } // 频繁切换时资源竞争 ``` 导致GPU命令队列阻塞（通过`glGetError()`可检测）。 ### 中可能性原因 4. **DRM/KMS驱动异常** i.MX8 Plus的**imx-drm驱动**在快速切换显示模式时可能出现： - 页面翻转（page-flip）超时 - CRTC状态机死锁 *检测方法*：`dmesg | grep drm`查看内核报错。 5. **Qt与Weston的线程冲突** Qt的渲染线程与Weston的主循环线程竞争DRM设备句柄，引发死锁： ```bash strace -p <weston_pid> -f -e poll,ioctl # 观察卡在DRM_IOCTL调用 ``` ### 低可能性原因 6. **内存碎片化** 长期运行的ARMv8系统可能因CMA内存碎片导致DMA-BUF分配失败，但通常伴随其他进程异常（本案例中网络正常）。 7. **硬件故障** ESM8400模块的DDR4或PMIC电源波动，但需排除软件原因后验证。 --- ### 排查建议 1. **GPU诊断**： ```bash echo 0x1f > /sys/class/graphics/fb0/debug # 启用i.MX8 GPU调试 cat /sys/kernel/debug/gc/meminfo # 检查显存泄漏 ``` 2. **Weston日志**： ```bash weston --log=debug-wayland.txt # 捕获Wayland协议错误 ``` 3. **Qt渲染分析**： 设置环境变量： ```bash export QT_LOGGING_RULES="qt.scenegraph.*=true" export QSG_RENDERER_DEBUG=render ``` ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值