关于一个内存泄露的问题
2017-06-17 00:39
309 查看
是这样子的
这样子的代码居然能够正常运行
不清楚为什么
使用内存检测工具检查了一下
后来拿了另外一个代码进行测试
这个是肯定没问题的
同样的内存检测工具进行
同样能够正常运行
不过内存检测工具还是检查出问题来了
问题:
不知道为什么之前那个代码能够正常运作
这样子的代码居然能够正常运行
#include <iostream> #include <vector> using namespace std; vector<int>::iterator fun(vector<int> t){ return t.begin()+2;//返回一个局部对象的迭代器 } int main(){ vector<int> test = {1,2,3,4}; auto p1 = fun(test); cout << *p1 << endl;//对之前局部的迭代器进行解引用,应该是不行的 } // 但是能够正常的输出3
不清楚为什么
使用内存检测工具检查了一下
valgrind --tool=memcheck --leak-check=full --show-reachable=yes ./test.out ==4677== Memcheck, a memory error detector ==4677== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==4677== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info ==4677== Command: ./test.out ==4677== ==4677== Invalid read of size 4 ==4677== at 0x400BA8: main (t.cpp:13) ==4677== Address 0x5ab4cd8 is 8 bytes inside a block of size 16 free'd ==4677== at 0x4C2F160: operator delete(void*) (vg_replace_malloc.c:576) ==4677== by 0x4016AB: __gnu_cxx::new_allocator<int>::deallocate(int*, unsigned long) (new_allocator.h:110) ==4677== by 0x4015B8: std::allocator_traits<std::allocator<int> >::deallocate(std::allocator<int>&, int*, unsigned long) (alloc_traits.h:517) ==4677== by 0x4013A5: std::_Vector_base<int, std::allocator<int> >::_M_deallocate(int*, unsigned long) (stl_vector.h:178) ==4677== by 0x401094: std::_Vector_base<int, std::allocator<int> >::~_Vector_base() (stl_vector.h:160) ==4677== by 0x400EB2: std::vector<int, std::allocator<int> >::~vector() (stl_vector.h:425) ==4677== by 0x400B9B: main (t.cpp:12) ==4677== Block was alloc'd at ==4677== at 0x4C2E1D6: operator new(unsigned long) (vg_replace_malloc.c:334) ==4677== by 0x4016EF: __gnu_cxx::new_allocator<int>::allocate(unsigned long, void const*) (new_allocator.h:104) ==4677== by 0x40160D: std::allocator_traits<std::allocator<int> >::allocate(std::allocator<int>&, unsigned long) (alloc_traits.h:491) ==4677== by 0x401435: std::_Vector_base<int, std::allocator<int> >::_M_allocate(unsigned long) (stl_vector.h:170) ==4677== by 0x401508: std::_Vector_base<int, std::allocator<int> >::_M_create_storage(unsigned long) (stl_vector.h:185) ==4677== by 0x40122C: std::_Vector_base<int, std::allocator<int> >::_Vector_base(unsigned long, std::allocator<int> const&) (stl_vector.h:136) ==4677== by 0x400F19: std::vector<int, std::allocator<int> >::vector(std::vector<int, std::allocator<int> > const&) (stl_vector.h:320) ==4677== by 0x400B7F: main (t.cpp:12) ==4677== 3 ==4677== ==4677== HEAP SUMMARY: ==4677== in use at exit: 72,704 bytes in 1 blocks ==4677== total heap usage: 4 allocs, 3 frees, 73,760 bytes allocated ==4677== ==4677== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1 ==4677== at 0x4C2DBB6: malloc (vg_replace_malloc.c:299) ==4677== by 0x4EC2EFF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21) ==4677== by 0x40104E9: call_init.part.0 (dl-init.c:72) ==4677== by 0x40105FA: call_init (dl-init.c:30) ==4677== by 0x40105FA: _dl_init (dl-init.c:120) ==4677== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so) ==4677== ==4677== LEAK SUMMARY: ==4677== definitely lost: 0 bytes in 0 blocks ==4677== indirectly lost: 0 bytes in 0 bl b7ca ocks ==4677== possibly lost: 0 bytes in 0 blocks ==4677== still reachable: 72,704 bytes in 1 blocks ==4677== suppressed: 0 bytes in 0 blocks ==4677== ==4677== For counts of detected and suppressed errors, rerun with: -v ==4677== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
后来拿了另外一个代码进行测试
#include <iostream> #include <vector> using namespace std; vector<int>::iterator fun(vector<int>& t){//修改了,变成传引用 return t.begin()+2; } int main(){ vector<int> test = {1,2,3,4}; auto p1 = fun(test); cout << *p1 << endl; }
这个是肯定没问题的
同样的内存检测工具进行
valgrind --tool=memcheck --leak-check=full --show-reachable=yes ./test.out ==4743== Memcheck, a memory error detector ==4743== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==4743== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info ==4743== Command: ./test.out ==4743== 3 ==4743== ==4743== HEAP SUMMARY: ==4743== in use at exit: 72,704 bytes in 1 blocks ==4743== total heap usage: 3 allocs, 2 frees, 73,744 bytes allocated ==4743== ==4743== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1 ==4743== at 0x4C2DBB6: malloc (vg_replace_malloc.c:299) ==4743== by 0x4EC2EFF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21) ==4743== by 0x40104E9: call_init.part.0 (dl-init.c:72) ==4743== by 0x40105FA: call_init (dl-init.c:30) ==4743== by 0x40105FA: _dl_init (dl-init.c:120) ==4743== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so) ==4743== ==4743== LEAK SUMMARY: ==4743== definitely lost: 0 bytes in 0 blocks ==4743== indirectly lost: 0 bytes in 0 blocks ==4743== possibly lost: 0 bytes in 0 blocks ==4743== still reachable: 72,704 bytes in 1 blocks ==4743== suppressed: 0 bytes in 0 blocks ==4743== ==4743== For counts of detected and suppressed errors, rerun with: -v ==4743== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
同样能够正常运行
不过内存检测工具还是检查出问题来了
问题:
不知道为什么之前那个代码能够正常运作
相关文章推荐
- Unity3D关于内存优化,内存泄露、多线程、引用C++的dll的问题研究
- 关于内存泄露和溢出问题浅谈
- 关于 MFC 中 CString 内存泄露的问题
- 关于一个CS项目,jvm内存溢出问题的解决方案
- 关于多态里父类的析构函数造成子类内存泄露的问题
- 一个JS图片放大镜,实现动态记录的图片放大,避免内存泄露,解决IE6下无法遮盖select控件问题
- 今天遇到一个关于对象和对象方法内存分配的有趣的问题
- 关于ACE_Asynch_Acceptor::accept 内存泄露的问题(Windows)
- 关于JavaFX中内存泄露问题
- 关于block的回调使用-防止内存泄露问题
- 关于android中使用new Message的内存泄露问题
- 关于Java内存泄露的问题
- 关于内存泄露的几点问题
- 关于js内存泄露的一个好例子
- 关于安装查看内存泄露工具BoundsChecker 时出错的问题 ERROR432
- 一个常见的android内存泄露 问题
- 修正了一个内存泄露的问题
- 一个关于string 内存的问题
- 一个关于js的内存问题
- 一个内存泄露问题的定位