堆栈内存溢出
  简体   繁体   English

Valgrind 抱怨使用 std::ios_base::sync_with_stdio( false ) 的程序可能存在 memory 问题，为什么？

[英]Valgrind complaining for possible memory problems from a program which uses std::ios_base::sync_with_stdio( false ) why?

 原文  2022-08-07 12:45:34  1   1    c++/ performance/ memory-leaks/ c++17/ valgrind

问题描述

I have the following problem: recently I was trying to improve the performance of my programs using this option:我有以下问题：最近我试图使用这个选项来提高我的程序的性能：

std::ios_base::sync_with_stdio( false );

which I read from here that it is useful to increase the output stream speed for std::cout .我从这里读到，提高std::cout的 output stream 速度很有用。

The problem is that, if I try to compile my program prove.cpp with g++ and -std=c++17 flag:问题是，如果我尝试使用g++和-std=c++17标志编译我的程序prove.cpp ：

#include <ios>

class foo
 {
  public:
   void test() { std::ios_base::sync_with_stdio( false );}
 };

int main
 {
  foo object;
  object.test();
 }

and run Valgrind memcheck tool on the executable, using:并在可执行文件上运行Valgrind memcheck工具，使用：

valgrind --leak-check=full --show-leak-kinds=all ./a.out

I got a sort of error from Valgrind output:我从 Valgrind output 得到了一种错误：

==353686== Memcheck, a memory error detector
==353686== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==353686== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==353686== Command: ./a.out
==353686== 
==353686== 
==353686== HEAP SUMMARY:
==353686==     in use at exit: 122,880 bytes in 6 blocks
==353686==   total heap usage: 7 allocs, 1 frees, 195,584 bytes allocated
==353686== 
==353686== 8,192 bytes in 1 blocks are still reachable in loss record 1 of 6
==353686==    at 0x483C583: operator new[](unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==353686==    by 0x4977D03: std::basic_filebuf<char, std::char_traits<char> >::_M_allocate_internal_buffer() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686==    by 0x4975AD9: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686==    by 0x4927AA7: std::ios_base::sync_with_stdio(bool) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686==    by 0x10926B: foo::test() (in /home/gianluca/a.out)
==353686==    by 0x1091CF: main (in /home/gianluca/a.out)
==353686== 
==353686== 8,192 bytes in 1 blocks are still reachable in loss record 2 of 6
==353686==    at 0x483C583: operator new[](unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==353686==    by 0x4977D03: std::basic_filebuf<char, std::char_traits<char> >::_M_allocate_internal_buffer() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686==    by 0x4975AD9: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686==    by 0x4927AC8: std::ios_base::sync_with_stdio(bool) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686==    by 0x10926B: foo::test() (in /home/gianluca/a.out)
==353686==    by 0x1091CF: main (in /home/gianluca/a.out)
==353686== 
==353686== 8,192 bytes in 1 blocks are still reachable in loss record 3 of 6
==353686==    at 0x483C583: operator new[](unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==353686==    by 0x4977D03: std::basic_filebuf<char, std::char_traits<char> >::_M_allocate_internal_buffer() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686==    by 0x4975AD9: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686==    by 0x4927AE8: std::ios_base::sync_with_stdio(bool) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686==    by 0x10926B: foo::test() (in /home/gianluca/a.out)
==353686==    by 0x1091CF: main (in /home/gianluca/a.out)
==353686== 
==353686== 32,768 bytes in 1 blocks are still reachable in loss record 4 of 6
==353686==    at 0x483C583: operator new[](unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==353686==    by 0x4979B16: std::basic_filebuf<wchar_t, std::char_traits<wchar_t> >::_M_allocate_internal_buffer() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686==    by 0x4975CC9: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686==    by 0x4927B5D: std::ios_base::sync_with_stdio(bool) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686==    by 0x10926B: foo::test() (in /home/gianluca/a.out)
==353686==    by 0x1091CF: main (in /home/gianluca/a.out)
==353686== 
==353686== 32,768 bytes in 1 blocks are still reachable in loss record 5 of 6
==353686==    at 0x483C583: operator new[](unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==353686==    by 0x4979B16: std::basic_filebuf<wchar_t, std::char_traits<wchar_t> >::_M_allocate_internal_buffer() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686==    by 0x4975CC9: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686==    by 0x4927B77: std::ios_base::sync_with_stdio(bool) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686==    by 0x10926B: foo::test() (in /home/gianluca/a.out)
==353686==    by 0x1091CF: main (in /home/gianluca/a.out)
==353686== 
==353686== 32,768 bytes in 1 blocks are still reachable in loss record 6 of 6
==353686==    at 0x483C583: operator new[](unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==353686==    by 0x4979B16: std::basic_filebuf<wchar_t, std::char_traits<wchar_t> >::_M_allocate_internal_buffer() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686==    by 0x4975CC9: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686==    by 0x4927B90: std::ios_base::sync_with_stdio(bool) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686==    by 0x10926B: foo::test() (in /home/gianluca/a.out)
==353686==    by 0x1091CF: main (in /home/gianluca/a.out)
==353686== 
==353686== LEAK SUMMARY:
==353686==    definitely lost: 0 bytes in 0 blocks
==353686==    indirectly lost: 0 bytes in 0 blocks
==353686==      possibly lost: 0 bytes in 0 blocks
==353686==    still reachable: 122,880 bytes in 6 blocks
==353686==         suppressed: 0 bytes in 0 blocks
==353686== 
==353686== For lists of detected and suppressed errors, rerun with: -s
==353686== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Do you know how to solve it?你知道怎么解决吗？ Should I suppress it?我应该压制它吗？ Thanks.谢谢。

1 个解决方案

解决方案1
 0  2022-08-08 12:10:05

Based on other's answers, it seems that there is no easy solution to the problem.根据其他人的答案，似乎没有简单的解决方案。 However, since this is a not so relevant issue and memory is reclaimed when my program exits, I concluded that the most suitable "solution" is to add these specific errors to a Valgrind suppression file.但是，由于这是一个不太相关的问题，并且 memory 在我的程序退出时被回收，我得出结论，最合适的“解决方案”是将这些特定错误添加到 Valgrind 抑制文件中。

暂无
暂无

声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 std::ios_base::sync_with_stdio(false)，优点，缺点？ - std::ios_base::sync_with_stdio(false), advantages, disadvantages? 使用 ios_base::sync_with_stdio(false) 编译错误； - Compile Error with ios_base::sync_with_stdio(false); 为什么移动 ios_base::sync_with_stdio(false), cin.tie(NULL) 会导致内存错误？ - Why does moving around ios_base::sync_with_stdio(false), cin.tie(NULL) result in a memory error? ios_base::sync_with_stdio 优化 - ios_base::sync_with_stdio optimization 为什么在libc ++（clang）中没有实现std :: ios_base :: sync_with_stdio？ - Why std::ios_base::sync_with_stdio isn't implemented in libc++ (clang)? ios_base :: sync_with_stdio（false）在来自stdin的两个输入之间不起作用 - ios_base::sync_with_stdio(false) does not work between two inputs from stdin ios_base::sync_with_stdio(0); 有什么区别？ 和 ios::sync_with_stdio(0); 在 C++ 中？ - What is the difference between ios_base::sync_with_stdio(0); and ios::sync_with_stdio(0); in C++? ios_base::sync_with_stdio(false) 的意义； cin.tie(NULL); - Significance of ios_base::sync_with_stdio(false); cin.tie(NULL); std :: ios_base :: sync_with_stdio如何影响流缓冲？ - How does std::ios_base::sync_with_stdio impact stream buffering? iostream的确切含义是与ios_base :: sync_with_stdio同步 - What is exact meaning of iostream is sync with ios_base::sync_with_stdio
相关标签
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM