Re: valgrinding emacs?

[Paul Eggert <eggert@cs.ucla.edu>]

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

joakim@verona.se wrote:
> I seem to recall that others have had success valgrinding emacs in the past.

It works for me, sort of, but it's kind of flaky.  I haven't used it recently, 
but I just now tried it on Fedora 21 x86-64 and got some warnings that I hope 
are false alarms.  I use the attached valgrind.supp file which is somewhat 
obsolescent now (it probably needs to be upgraded to match Fedora 21's quirks, 
and I haven't looked into that).


[-- Attachment #2: valgrind.supp --]
[-- Type: text/plain, Size: 1337 bytes --]

# valgrind suppression file
# Usage:
#    valgrind --suppressions=valgrind.supp ./temacs

# Conservative garbage collection inherently looks at uninitialized values,
# and Fgarbage_collect and its callees all depend on this.
# It's hard to separate out exactly which callees need to be listed here,
# since the C compiler can inline them.  Also, valgrind doesn't care
# about the use of uninitialized variables directly, only when their values
# are eventually used.  So just list Fgarbage_collect and its callees.
{
   Fgarbage_collect Cond - conservative garbage collection
   Memcheck:Cond
   ...
   fun:Fgarbage_collect
}
{
   Fgarbage_collect Value8 - conservative garbage collection
   Memcheck:Value8
   ...
   fun:Fgarbage_collect
}
# valgrind only looks at the last few callees on the stack, but
# mark_object can call itself recursively and deeply.  So list
# it too, in case Fgarbage_collect is a long way from the stack top.
{
   Fgarbage_collect Cond - conservative garbage collection
   Memcheck:Cond
   ...
   fun:mark_object
}
{
   Fgarbage_collect Value8 - conservative garbage collection
   Memcheck:Value8
   ...
   fun:mark_object
}

# On one circa-2011 x86-64 GNU/Linux platform, strlen is inlined to
# something that loads 4 bytes at a time.
{
   init_buffer optimized strlen
   Memcheck:Addr4
   fun:init_buffer
}