[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Texmacs-dev] Using Valgrind and first results
From: |
Joris van der Hoeven |
Subject: |
Re: [Texmacs-dev] Using Valgrind and first results |
Date: |
Tue, 25 May 2004 11:03:07 +0200 (CEST) |
On Tue, 25 May 2004, David MENTRE wrote:
> I've tried to configure Valgrind to look for TeXmacs memory leaks.
>
> First, I have modified with following line the texmacs sh script:
> exec valgrind --leak-check=yes --gen-suppressions=yes
> --suppressions=texmacs.supp -v texmacs.bin "$@"
Thanks for showing the right command.
> With this setting, valgrind runs without to much errors/warnings. Be
> aware that valgrind slows TeXmacs a lot. Right now, my test procedure is
> to start TeXmacs and then quit it (C-x C-c).
OK. We should try with updating a small buffer several times.
Don't forget to
(set-maximal-undo-depth 1)
in your my-init-texmacs.scm.
> With this setting, I have following result:
>
> ==4199== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 115742 from 11)
> --4199--
> --4199-- supp: 45 Ugly strchr error in /lib/ld-2.3.2.so
> --4199-- supp: 11 Unitialized value in edit_env_rep::decode_length(string)
> (env_exec.cpp:1656)
>
> I have added the above one at potential TeXmacs error. See end of
> texmacs.supp.
Interesting...
> --4199-- supp: 4 TLS Syscall param writev(vector[...]) contains
> uninitialised or unaddressable byte(s)
> --4199-- supp: 2 Guile GC uninitialised value of size 4 in scm_markstream
> --4199-- supp: 16 Guile GC scm_c_hook_run
> --4199-- supp: 963 Guile GC scm_c_hook_run
> --4199-- supp: 11459 Guile GC scm_igc
> --4199-- supp: 15758 Guile GC marking
> --4199-- supp: 17544 Guile GC marking
> --4199-- supp: 69421 Guile GC marking
> --4199-- supp: 519 __libc_sigaction (in /lib/tls/libc-2.3.2.so
> ==4199== malloc/free: in use at exit: 5604984 bytes in 13895 blocks.
> ==4199== malloc/free: 36887 allocs, 22992 frees, 8319394 bytes allocated.
> ==4199==
> ==4199== searching for pointers to 13895 not-freed blocks.
> ==4199== checked 13398108 bytes.
> ==4199==
> ==4199== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- n
> ==4199==
> ==4199== 5520 bytes in 3 blocks are definitely lost in loss record 94 of 105
> ==4199== at 0x3C01F40D: malloc (vg_replace_malloc.c:105)
> ==4199== by 0x817EED0: safe_malloc(unsigned) (fast_alloc.cpp:35)
> ==4199== by 0x80570E7: operator new[](unsigned) (basic.cpp:62)
> ==4199== by 0x8273F2D: as_charp(string) (string.cpp:235)
>
> Is there a leak here?
Could be, but what are the objects...?
> ==4199==
> ==4199== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- n
> ==4199==
> ==4199==
> ==4199== 1007792 bytes in 287 blocks are possibly lost in loss record 103 of
> 105
> ==4199== at 0x3C01F40D: malloc (vg_replace_malloc.c:105)
> ==4199== by 0x817EED0: safe_malloc(unsigned) (fast_alloc.cpp:35)
> ==4199== by 0x80570E7: operator new[](unsigned) (basic.cpp:62)
> ==4199== by 0x80CE2B0: hashmap_rep<tree_label, tag_info>::resize(int)
> (hashmap.cpp:54)
>
> And here?
Could be too (and that is a huge one), but what are the objects?
> ==4199==
> ==4199== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- n
> ==4199==
> ==4199== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- y
> {
> <insert a suppression name here>
> Memcheck:Leak
> fun:malloc
> fun:_Z11safe_mallocj
> fun:_Z14enlarge_mallocj
> fun:_Znwj
> }
>
> I don't know for this one.
>
> ==4199==
> ==4199== LEAK SUMMARY:
> ==4199== definitely lost: 5520 bytes in 3 blocks.
> ==4199== possibly lost: 1007792 bytes in 287 blocks.
>
> Apparently, some memory is lost.
Yes, I also suspect that.