Re: [Texmacs-dev] Using Valgrind and first results

[Joris van der Hoeven]

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.