Название: Почему в Qt-эшных примерах лики?
Отправлено: juvf от Сентябрь 25, 2009, 05:49
демо аффинные преобразования, запуск с параметрами valgrind --track-origins=yes -v ./affine вывод: ==14907== IN SUMMARY: 6 errors from 1 contexts (suppressed: 156 from 2)
==14907==
==14907== malloc/free: in use at exit: 215,256 bytes in 4,742 blocks.
==14907== malloc/free: 270,182 allocs, 265,440 frees, 278,348,380 bytes allocated.
==14907==
==14907== searching for pointers to 4,742 not-freed blocks.
==14907== checked 963,136 bytes.
==14907==
==14907== LEAK SUMMARY:
==14907== definitely lost: 650 bytes in 6 blocks.
==14907== possibly lost: 744 bytes in 3 blocks.
==14907== suppressed: 0 bytes in 0 blocks.
==14907== Rerun with --leak-check=full to see details of leaked memory.
--14907-- memcheck: sanity checks: 2871 cheap, 57 expensive
--14907-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
--14907-- memcheck: auxmaps_L1: 0 searches, 0 cmps, ratio 0:10
--14907-- memcheck: auxmaps_L2: 0 searches, 0 nodes
--14907-- memcheck: SMs: n_issued = 2598 (41568k, 40M)
--14907-- memcheck: SMs: n_deissued = 2320 (37120k, 36M)
--14907-- memcheck: SMs: max_noaccess = 65535 (1048560k, 1023M)
--14907-- memcheck: SMs: max_undefined = 11 (176k, 0M)
--14907-- memcheck: SMs: max_defined = 518 (8288k, 8M)
--14907-- memcheck: SMs: max_non_DSM = 307 (4912k, 4M)
--14907-- memcheck: max sec V bit nodes: 34864 (1770k, 1M)
--14907-- memcheck: set_sec_vbits8 calls: 512594 (new: 40927, updates: 471667)
--14907-- memcheck: max shadow mem size: 6986k, 6M
--14907-- ocacheL1: 2,097,890,298 refs 1,968,002 misses (0 lossage)
--14907-- ocacheL1: 2,054,702,696 at 0 41,219,600 at 1
--14907-- ocacheL1:
--14907-- errormgr: 162 errlist searches, 376 comparisons during search
--14907-- ocacheL1: 92,274,688 sizeB 67,108,864 useful
--14907-- ocacheL2: 1,978,575 refs 1,968,002 misses
--14907-- ocacheL2: 0 max nodes 0 curr nodes
--14907-- niacache: 0 refs 0 misses
--14907-- translate: fast SP updates identified: 89,311 ( 87.9 %)
--14907-- translate: generic_known SP updates identified: 8,888 ( 8.7 %)
--14907-- translate: generic_unknown SP updates identified: 3,342 ( 3.2 %)
--14907-- tt/tc: 1,873,031 tt lookups requiring 8,833,573 probes
--14907-- tt/tc: 1,873,031 fast-cache updates, 7 flushes
--14907-- transtab: new 74,226 (1,735,523 -> 38,680,847; ratio 222:10) [0 scs]
--14907-- transtab: dumped 0 (0 -> ??)
--14907-- transtab: discarded 162 (3,255 -> ??)
--14907-- scheduler: 287,133,479 jumps (bb entries).
--14907-- scheduler: 2,871/2,763,686 major/minor sched events.
--14907-- sanity: 2872 cheap, 57 expensive checks.
--14907-- exectx: 98,317 lists, 75,840 contexts (avg 0 per list)
--14907-- exectx: 606,983 searches, 592,996 full compares (976 per 1000)
--14907-- exectx: 0 cmp2, 332 cmp4, 0 cmpAll
--14907-- errormgr: почему лики? ps сначало своё приложение, написанное на Qt4.5.2, не прошло проверку. Потом попробовали из qtDemo - лики (((
Название: Re: Почему в Qt-эшных примерах лики?
Отправлено: Rcus от Сентябрь 25, 2009, 06:47
Не тот ключ используете. этот нужен для поиска использования неинициализированных переменных. --track-origins=<yes|no> [default: no]
Controls whether Memcheck tracks the origin of uninitialised values. By default, it does not, which means that although it can tell you
that an uninitialised value is being used in a dangerous way, it cannot tell you where the uninitialised value came from. This often makes
it difficult to track down the root problem.
Для поиска утечек памяти используется --leak-check
Название: Re: Почему в Qt-эшных примерах лики?
Отправлено: juvf от Сентябрь 25, 2009, 07:52
Не тот ключ используете. этот нужен для поиска использования неинициализированных переменных. Ой, сори. я делаю команду valgrind --leak-check=full -v ./affine ps проверка на не инициализированные переменные показала, что не инициализированные переменные есть. Но это же демо, как так? и лики, и переменные! Почему они там есть?
Название: Re: Почему в Qt-эшных примерах лики?
Отправлено: ildar от Сентябрь 26, 2009, 10:04
меня тоже это интересовало...
http://www.prog.org.ru/index.php?topic=10592 (http://www.prog.org.ru/index.php?topic=10592)
Название: Re: Почему в Qt-эшных примерах лики?
Отправлено: shadone от Сентябрь 28, 2009, 11:38
покажите конкретные утечки :) <qt-4.6|*> $ valgrind --leak-check=full ./demos/affine/affine
==20663== Memcheck, a memory error detector.
==20663== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==20663== Using LibVEX rev 1854, a library for dynamic binary translation.
==20663== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==20663== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation framework.
==20663== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==20663== For more details, rerun with: -v
==20663==
==20663== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 172 from 3)
==20663== malloc/free: in use at exit: 2,572,390 bytes in 15,509 blocks.
==20663== malloc/free: 213,903 allocs, 198,394 frees, 74,827,715 bytes allocated.
==20663== For counts of detected errors, rerun with: -v
==20663== searching for pointers to 15,509 not-freed blocks.
==20663== checked 4,843,040 bytes.
==20663==
==20663== 98 bytes in 6 blocks are definitely lost in loss record 69 of 202
==20663== at 0x4025D2E: malloc (vg_replace_malloc.c:207)
==20663== by 0x54EE3BD: FcStrCopy (fcstr.c:42)
==20663== by 0x54F1B9C: FcEndElement (fcxml.c:1936)
==20663== by 0x64E3EC3: (within /usr/lib/libexpat.so.1.5.2)
==20663== by 0x64E4C10: (within /usr/lib/libexpat.so.1.5.2)
==20663== by 0x64E65EE: (within /usr/lib/libexpat.so.1.5.2)
==20663== by 0x64E6CE6: (within /usr/lib/libexpat.so.1.5.2)
==20663== by 0x64DD68B: XML_ParseBuffer (in /usr/lib/libexpat.so.1.5.2)
==20663== by 0x54EFF1D: FcConfigParseAndLoad (fcxml.c:2552)
==20663== by 0x54F0265: FcConfigParseAndLoad (fcxml.c:2438)
==20663== by 0x54F154E: FcEndElement (fcxml.c:1648)
==20663== by 0x64E3EC3: (within /usr/lib/libexpat.so.1.5.2)
==20663==
==20663==
==20663== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 74 of 202
==20663== at 0x4025D2E: malloc (vg_replace_malloc.c:207)
==20663== by 0x53E99F3: nss_parse_service_list (nsswitch.c:547)
==20663== by 0x53EA18D: __nss_database_lookup (nsswitch.c:134)
==20663== by 0x6B1CF4B: ???
==20663== by 0x6B1E07E: ???
==20663== by 0x53A1D11: getpwnam_r@@GLIBC_2.1.2 (getXXbyYY_r.c:253)
==20663== by 0x567D765: g_get_any_init_do (gutils.c:1596)
==20663== by 0x567F25C: g_get_home_dir (gutils.c:1747)
==20663== by 0x6BAD4E4: ORBit_option_parse (in /usr/lib/libORBit-2.so.0.1.0)
==20663== by 0x6BB3FCF: CORBA_ORB_init (in /usr/lib/libORBit-2.so.0.1.0)
==20663== by 0x6B685BE: gconf_orb_get (in /usr/lib/libgconf-2.so.4.1.5)
==20663== by 0x6B6874D: (within /usr/lib/libgconf-2.so.4.1.5)
==20663==
==20663==
==20663== 216 bytes in 1 blocks are definitely lost in loss record 105 of 202
==20663== at 0x4025D2E: malloc (vg_replace_malloc.c:207)
==20663== by 0x5574812: _XimOpenIM (imInt.c:211)
==20663== by 0x557464F: _XimRegisterIMInstantiateCallback (imInsClbk.c:196)
==20663== by 0x55588C7: XRegisterIMInstantiateCallback (IMWrap.c:194)
==20663== by 0x4A35A0E: QXIMInputContext::QXIMInputContext() (qximinputcontext_x11.cpp:371)
==20663== by 0x4A3419D: QInputContextFactory::create(QString const&, QObject*) (qinputcontextfactory.cpp:137)
==20663== by 0x42A281F: QApplication::inputContext() const (qapplication.cpp:5118)
==20663== by 0x4313FBC: QWidgetPrivate::inputContext() const (qwidget.cpp:292)
==20663== by 0x432233F: QWidget::inputContext() (qwidget.cpp:311)
==20663== by 0x436BB2F: QWidget::destroy(bool, bool) (qwidget_x11.cpp:1061)
==20663== by 0x4316483: QWidget::~QWidget() (qwidget.cpp:1478)
==20663== by 0x47F9FD0: QLineEdit::~QLineEdit() (qlineedit.cpp:356)
==20663==
==20663==
==20663== 396 (256 direct, 140 indirect) bytes in 2 blocks are definitely lost in loss record 110 of 202
==20663== at 0x4025D2E: malloc (vg_replace_malloc.c:207)
==20663== by 0x54EB9F6: FcPatternObjectInsertElt (fcpat.c:367)
==20663== by 0x54EC3E7: FcPatternObjectAddWithBinding (fcpat.c:515)
==20663== by 0x54EC4FE: FcPatternAppend (fcpat.c:991)
==20663== by 0x54F1FDE: FcEndElement (fcxml.c:2023)
==20663== by 0x64E3EC3: (within /usr/lib/libexpat.so.1.5.2)
==20663== by 0x64E4C10: (within /usr/lib/libexpat.so.1.5.2)
==20663== by 0x64E65EE: (within /usr/lib/libexpat.so.1.5.2)
==20663== by 0x64E6CE6: (within /usr/lib/libexpat.so.1.5.2)
==20663== by 0x64DD68B: XML_ParseBuffer (in /usr/lib/libexpat.so.1.5.2)
==20663== by 0x54EFF1D: FcConfigParseAndLoad (fcxml.c:2552)
==20663== by 0x54F0265: FcConfigParseAndLoad (fcxml.c:2438)
==20663==
==20663== 268 (12 direct, 256 indirect) bytes in 1 blocks are definitely lost in loss record 111 of 202
==20663== at 0x402573E: operator new(unsigned) (vg_replace_malloc.c:224)
==20663== by 0x80509CA: main (main.cpp:53)
==20663==
==20663==
==20663== 56,200 (19,840 direct, 36,360 indirect) bytes in 55 blocks are definitely lost in loss record 195 of 202
==20663== at 0x4025E4C: realloc (vg_replace_malloc.c:429)
==20663== by 0x54EB971: FcPatternObjectInsertElt (fcpat.c:358)
==20663== by 0x54EC3E7: FcPatternObjectAddWithBinding (fcpat.c:515)
==20663== by 0x54ECA2B: FcPatternObjectAdd (fcpat.c:545)
==20663== by 0x54E898D: FcFontRenderPrepare (fcmatch.c:444)
==20663== by 0x71C8EBA: (within /usr/lib/libpangoft2-1.0.so.0.2202.0)
==20663== by 0x7200559: pango_font_map_load_fontset (in /usr/lib/libpango-1.0.so.0.2202.0)
==20663== by 0x71C94F4: (within /usr/lib/libpangoft2-1.0.so.0.2202.0)
==20663== by 0x72005E2: pango_font_map_load_font (in /usr/lib/libpango-1.0.so.0.2202.0)
==20663== by 0x71FE9A2: pango_context_load_font (in /usr/lib/libpango-1.0.so.0.2202.0)
==20663== by 0x7204424: (within /usr/lib/libpango-1.0.so.0.2202.0)
==20663== by 0x72048F1: pango_layout_line_get_extents (in /usr/lib/libpango-1.0.so.0.2202.0)
==20663==
==20663==
==20663== 128,680 bytes in 107 blocks are possibly lost in loss record 200 of 202
==20663== at 0x4023C4A: memalign (vg_replace_malloc.c:460)
==20663== by 0x4023CFE: posix_memalign (vg_replace_malloc.c:569)
==20663== by 0x5666352: slab_allocator_alloc_chunk (gslice.c:1136)
==20663== by 0x5667B32: g_slice_alloc (gslice.c:666)
==20663== by 0x56218AE: g_array_sized_new (garray.c:86)
==20663== by 0x56219C6: g_array_new (garray.c:78)
==20663== by 0x5673323: g_static_private_set (gthread.c:451)
==20663== by 0x563137F: g_get_filename_charsets (gconvert.c:1185)
==20663== by 0x56313F0: _g_convert_thread_init (gconvert.c:1290)
==20663== by 0x56735DC: g_thread_init_glib (gthread.c:165)
==20663== by 0x560168C: g_thread_init (gthread-impl.c:355)
==20663== by 0x4F8831A: QEventDispatcherGlibPrivate::QEventDispatcherGlibPrivate(_GMainContext*) (qeventdispatcher_glib.cpp:297)
==20663==
==20663== LEAK SUMMARY:
==20663== definitely lost: 20,458 bytes in 66 blocks.
==20663== indirectly lost: 36,876 bytes in 1,814 blocks.
==20663== possibly lost: 128,680 bytes in 107 blocks.
==20663== still reachable: 2,299,978 bytes in 12,155 blocks.
==20663== suppressed: 86,398 bytes in 1,367 blocks.
==20663== Reachable blocks (those to which a pointer was found) are not shown.
==20663== To see them, rerun with: --leak-check=full --show-reachable=yes
я здесь вижу только две проблемы - в main.cpp:53 - создается экземпляр ArthurStyle без родителя и не удаляется (не принципиальная проблема я бы сказал) и input method открытый с помощью XOpenIM не закрывается (это более сложная проблема над которой я воевал некоторое время но корректный способ исправить пока не нашел).
Название: Re: Почему в Qt-эшных примерах лики?
Отправлено: juvf от Сентябрь 29, 2009, 08:46
а это почему не относится к проблемам? ==20663== 396 (256 direct, 140 indirect) bytes in 2 blocks are definitely lost in loss record 110 of 202
==20663== at 0x4025D2E: malloc (vg_replace_malloc.c:207)
==20663== by 0x54EB9F6: FcPatternObjectInsertElt (fcpat.c:367)
==20663== by 0x54EC3E7: FcPatternObjectAddWithBinding (fcpat.c:515)
==20663== by 0x54EC4FE: FcPatternAppend (fcpat.c:991)
==20663== by 0x54F1FDE: FcEndElement (fcxml.c:2023)
==20663== by 0x64E3EC3: (within /usr/lib/libexpat.so.1.5.2)
==20663== by 0x64E4C10: (within /usr/lib/libexpat.so.1.5.2)
==20663== by 0x64E65EE: (within /usr/lib/libexpat.so.1.5.2)
==20663== by 0x64E6CE6: (within /usr/lib/libexpat.so.1.5.2)
==20663== by 0x64DD68B: XML_ParseBuffer (in /usr/lib/libexpat.so.1.5.2)
==20663== by 0x54EFF1D: FcConfigParseAndLoad (fcxml.c:2552)
==20663== by 0x54F0265: FcConfigParseAndLoad (fcxml.c:2438)
Название: Re: Почему в Qt-эшных примерах лики?
Отправлено: shadone от Сентябрь 29, 2009, 12:06
Это fontconfig. Возможно конечно причина в Qt - возможно мы не закрывает какой-то handle (FcConfig?), но сходу я не нашел в чем там проблема. Учитывая что утечка одноразовая (объем утекшей памяти не увеличивается по мере работы приложения), я бы сказал не критичная. (однако если есть идеи в чем там проблема и как исправить - welcome)
|