новият libstdc++ на gcc5.1 може да разпредели голяма купчина памет

valgrind открива "все още достъпен теч" в празна програма, компилирана с gcc5.1, g++ ./a.cpp,

int main () {}

valgrind казва, valgrind ./a.out,

==32037== HEAP SUMMARY:
==32037==     in use at exit: 72,704 bytes in 1 blocks
==32037==   total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated
==32037== 
==32037== LEAK SUMMARY:
==32037==    definitely lost: 0 bytes in 0 blocks
==32037==    indirectly lost: 0 bytes in 0 blocks
==32037==      possibly lost: 0 bytes in 0 blocks
==32037==    still reachable: 72,704 bytes in 1 blocks
==32037==         suppressed: 0 bytes in 0 blocks
==32037== Rerun with --leak-check=full to see details of leaked memory
==32037== 
==32037== For counts of detected and suppressed errors, rerun with: -v
==32037== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 5)

За c програми valgrinds отчита липса на изтичане на памет и разпределяне на памет. В допълнение, за gcc5.0 и gcc4.9.2, valgrinds отчита липса на изтичане на памет и разпределение на памет. Тогава предполагам, че новият libstdc++ на gcc5.1 е причината.

Въпросът ми е как да намаля това огромно разпределение на паметта, което може да е в libstdc++. Наистина, времето за изпълнение на тази празна c++ програма, компилирана с -O3, е по-голямо от това на празната c програма с няколко милисекунди (без системно време).


gcc c c++ valgrind
person akakatak    schedule 22.05.2015    source източник
comment
вашият файл само int main () {} ли е? или има ли включва и други подобни?   -  person Eregrith    schedule 22.05.2015
comment
не са включени или свързани файлове, определени от потребителя. int main () {} е точно съдържанието, а g++ ./a.cpp е командата за компилиране, която използвах.   -  person akakatak    schedule 22.05.2015
comment
Така че наистина е само int main () {}... уау gcc... уау....   -  person Eregrith    schedule 22.05.2015
comment
Какво ви дава gcc -E a.cpp? Как изглежда .o?   -  person Eregrith    schedule 22.05.2015
comment
g++ -E a.cpp казва, 　　　　# 1 test.cpp 　　　　# 1 ‹built-in› 　　　　# 1 ‹command-line› 　　　　# 1 test.cpp 　　　　int main () {} 　 Мисля, че файлът obj. Няма по-непознати символи. Както и да е, връзката, предложена от user657267, може да каже нещо по същество.   -  person akakatak    schedule 22.05.2015

Отговори (1)


arrow_upward
9
arrow_downward

Пространството се разпределя като буфер за спешни изключения в libsup++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

разработчиците говорят за може би потискане на следата във Valgrind, но вероятно нищо не е направено в крайна сметка. Единственият начин да го елиминирате от проследяването в момента вероятно би бил да деактивирате изключенията, но и в двата случая не изглежда, че е голяма работа, не е като че паметта може да бъде възстановена за нещо друго, преди програмата да излезе.

person user657267    schedule 22.05.2015
comment
Това определено се нуждае от потискане във Valgrind, изгубих половин час в търсене на изтичане на информация, преди да попадна на тази тема SO... - person XapaJIaMnu; 28.05.2015
comment
Изглежда, че са решили проблема, сега просто трябва да изчакаме, докато нашата дистрибуция навакса! - person nic; 26.01.2016
comment
@nic Имате ли някакъв ресурс за вашия коментар? - person akakatak; 16.02.2016
comment
Намерих тази статия wiki.wxwidgets.org/Valgrind_Suppression_File_Howto за полезна, като ми каза как да създам потискане на valgrind. Моето потискане (за gcc 5.4.0) е { ‹Suppress Exception buffer leak in libstdc++› Memcheck:Leak match-leak-kinds: reachable fun:malloc obj:/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0 .21 fun:call_init.part.0 fun:call_init fun:_dl_init obj:/lib/x86_64-linux-gnu/ld-2.23.so } - person RichardHowells; 18.08.2016