c cpp 代码 数据竞争 分析, 以及 内存泄露 分析 工具 使用 demo

简介: c cpp 代码 数据竞争 分析, 以及 内存泄露 分析 工具 使用 demo

race_check_and_mem_leak_on_cpp

问题代码

v1_race 版本

test_race_and_leak.cpp

#include <pthread.h>
#include <iostream>
static int a;
void *_work_1(void *args)
{
    for (int i = 0; i < 1000; i++)
    {
        a += 1;
    }
    int *x = new int;
    return 0;
}
int main(int argc, char *argv[])
{
    a = 0;
    int count = 1000;
    pthread_t cThreads[count];
    for (int i = 0; i < count; i++)
    {
        pthread_create(&cThreads[i], NULL, _work_1, NULL);
    }
    for (int i = 0; i < count; i++)
    {
        pthread_join(cThreads[i], NULL);
    }
    std::cout << " a : " << a << std::endl;
    return 0;
}

build code

g++ -o test_race_and_leak test_race_and_leak.cpp -lpthread
# 正确结果 应该是 
1000000
# 多次 运行 结果 都小于 1000000
# 说明出现了 data race 数据 争抢 以及 脏读
./test_race_and_leak
a : 999700

race 数据 竞争 分析

https://stackoverflow.com/questions/5360491/how-i-can-detect-memory-leaks-of-c-application-in-linux-ubuntu-os

https://valgrind.org/


检查后 提示 出现了 数据争抢 发生在

0x10C158 同时被 线程 2 线程 3 写入 4 bytes, 也就是 一个 整形的大小

apt install valgrind -y
valgrind --tool=memcheck <your_app> <your_apps_params>
valgrind --tool=memcheck  test_race_and_leak
./test_race_and_leak
 a : 999779
# 数据 竞争 检查
valgrind --tool=helgrind  ./test_race_and_leak
# ==2592589== Possible data race during write of size 4 at 0x10C158 by thread #3
# ==2592589== Locks held: none
# ==2592589==    at 0x10924E: _work_1(void*) (in /root/learn_threads/test_race_and_leak)
# ==2592589==    by 0x4842B1A: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_helgrind-amd64-linux.so)
# ==2592589==    by 0x4865608: start_thread (pthread_create.c:477)
# ==2592589==    by 0x4B83292: clone (clone.S:95)
# ==2592589==
# ==2592589== This conflicts with a previous write of size 4 by thread #2
# ==2592589== Locks held: none
# ==2592589==    at 0x10924E: _work_1(void*) (in /root/learn_threads/test_race_and_leak)
# ==2592589==    by 0x4842B1A: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_helgrind-amd64-linux.so)
# ==2592589==    by 0x4865608: start_thread (pthread_create.c:477)
# ==2592589==    by 0x4B83292: clone (clone.S:95)
# ==2592589==  Address 0x10c158 is 0 bytes inside data symbol "_ZL1a"
# ==2592589==
#  a : 1000000
# ==2592589==
# ==2592589== Use --history-level=approx or =none to gain increased speed, at
# ==2592589== the cost of reduced accuracy of conflicting-access information
# ==2592589== For lists of detected and suppressed errors, rerun with: -s
# ==2592589== ERROR SUMMARY: 1998 errors from 2 contexts (suppressed: 0 from 0)

内存泄露检查

检查后 提示 出现了 内存 泄露 发生在

malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)

by 0x10942E: main (in /root/learn_threads/test_race_and_leak)

# 内存 泄露检查
valgrind --tool=memcheck  --leak-check=full -s ./test_race_and_leak
# ==2599297== HEAP SUMMARY:
# ==2599297==     in use at exit: 100 bytes in 1 blocks
# ==2599297==   total heap usage: 1,003 allocs, 1,002 frees, 361,828 bytes allocated
# ==2599297== 
# ==2599297== 100 bytes in 1 blocks are definitely lost in loss record 1 of 1
# ==2599297==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
# ==2599297==    by 0x10942E: main (in /root/learn_threads/test_race_and_leak)
# ==2599297== 
# ==2599297== LEAK SUMMARY:
# ==2599297==    definitely lost: 100 bytes in 1 blocks
# ==2599297==    indirectly lost: 0 bytes in 0 blocks
# ==2599297==      possibly lost: 0 bytes in 0 blocks
# ==2599297==    still reachable: 0 bytes in 0 blocks
# ==2599297==         suppressed: 0 bytes in 0 blocks
# ==2599297== 
# ==2599297== For lists of detected and suppressed errors, rerun with: -s
# ==2599297== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
相关文章
|
2月前
|
安全 Java 应用服务中间件
Spring Boot + Java 21:内存减少 60%,启动速度提高 30% — 零代码
通过调整三个JVM和Spring Boot配置开关,无需重写代码即可显著优化Java应用性能:内存减少60%,启动速度提升30%。适用于所有在JVM上运行API的生产团队,低成本实现高效能。
266 3
|
5月前
|
存储 弹性计算 缓存
阿里云服务器ECS经济型、通用算力、计算型、通用和内存型选购指南及使用场景分析
本文详细解析阿里云ECS服务器的经济型、通用算力型、计算型、通用型和内存型实例的区别及适用场景,涵盖性能特点、配置比例与实际应用,助你根据业务需求精准选型,提升资源利用率并降低成本。
441 3
|
1月前
|
设计模式 缓存 Java
【JUC】(4)从JMM内存模型的角度来分析CAS并发性问题
本篇文章将从JMM内存模型的角度来分析CAS并发性问题; 内容包含:介绍JMM、CAS、balking犹豫模式、二次检查锁、指令重排问题
102 1
|
2月前
|
存储 大数据 Unix
Python生成器 vs 迭代器:从内存到代码的深度解析
在Python中,处理大数据或无限序列时,迭代器与生成器可避免内存溢出。迭代器通过`__iter__`和`__next__`手动实现,控制灵活;生成器用`yield`自动实现,代码简洁、内存高效。生成器适合大文件读取、惰性计算等场景,是性能优化的关键工具。
227 2
|
4月前
|
存储 人工智能 自然语言处理
AI代理内存消耗过大?9种优化策略对比分析
在AI代理系统中,多代理协作虽能提升整体准确性,但真正决定性能的关键因素之一是**内存管理**。随着对话深度和长度的增加,内存消耗呈指数级增长,主要源于历史上下文、工具调用记录、数据库查询结果等组件的持续积累。本文深入探讨了从基础到高级的九种内存优化技术,涵盖顺序存储、滑动窗口、摘要型内存、基于检索的系统、内存增强变换器、分层优化、图形化记忆网络、压缩整合策略以及类操作系统内存管理。通过统一框架下的代码实现与性能评估,分析了每种技术的适用场景与局限性,为构建高效、可扩展的AI代理系统提供了系统性的优化路径和技术参考。
247 4
AI代理内存消耗过大?9种优化策略对比分析
|
5月前
|
存储 Ubuntu Linux
内存卡格式化必看!4个格式化工具与注意事项
今天就给大家推荐几款经过实测的内存卡格式化工具,它们不仅使用简单、支持多种格式,而且在修复损坏卡方面也表现稳定,是实用性与安全性兼具的好帮手。
|
8月前
|
存储 Java
课时4:对象内存分析
接下来对对象实例化操作展开初步分析。在整个课程学习中,对象使用环节往往是最棘手的问题所在。
|
8月前
|
Java 编译器 Go
go的内存逃逸分析
内存逃逸分析是Go编译器在编译期间根据变量的类型和作用域,确定变量分配在堆上还是栈上的过程。如果变量需要分配在堆上,则称作内存逃逸。Go语言有自动内存管理(GC),开发者无需手动释放内存,但编译器需准确分配内存以优化性能。常见的内存逃逸场景包括返回局部变量的指针、使用`interface{}`动态类型、栈空间不足和闭包等。内存逃逸会影响性能,因为操作堆比栈慢,且增加GC压力。合理使用内存逃逸分析工具(如`-gcflags=-m`)有助于编写高效代码。
173 2
|
12月前
|
JavaScript
如何使用内存快照分析工具来分析Node.js应用的内存问题?
需要注意的是,不同的内存快照分析工具可能具有不同的功能和操作方式,在使用时需要根据具体工具的说明和特点进行灵活运用。
385 62
|
10月前
|
消息中间件 存储 缓存
kafka 的数据是放在磁盘上还是内存上,为什么速度会快?
Kafka的数据存储机制通过将数据同时写入磁盘和内存,确保高吞吐量与持久性。其日志文件按主题和分区组织,使用预写日志(WAL)保证数据持久性,并借助操作系统的页缓存加速读取。Kafka采用顺序I/O、零拷贝技术和批量处理优化性能,支持分区分段以实现并行处理。示例代码展示了如何使用KafkaProducer发送消息。

热门文章

最新文章