bug#14982: 24.3; core dump on NetBSD in graphical mode on files in cvs

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

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

Thomas Klausner wrote:
> I've included a detailed core dump in my original bug report.
> Does anyone have an idea what could be the cause?

Looks like a bad pointer.

If it's easily reproducible, can you reproduce it under valgrind?
I'm attaching the valgrind.supp I use on Fedora 17, maybe you can
use something similar on NetBSD.  It works only with temacs, but
perhaps you can reproduce the problem with temacs.  Instructions
for use are near the start of the attached file.


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

# valgrind suppression file
# Example use:
#    valgrind --db-attach=yes --suppressions=valgrind.supp ./temacs -l loadup

# This works with 'temacs', but not with 'bootstrap-emacs' or with 'emacs'
# due to incompabilities between valgrind and the way Emacs dumps itself.

# This is intended to work on both 32- and 64-bit hosts, so many rules
# are duplicated, e.g., there are rules for both Value4 and Value8.

# 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 Value4 - conservative garbage collection
   Memcheck:Value4
   ...
   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 Value4 - conservative garbage collection
   Memcheck:Value4
   ...
   fun:mark_object
}
{
   Fgarbage_collect Value8 - conservative garbage collection
   Memcheck:Value8
   ...
   fun:mark_object
}
# On Ubuntu 12.04 x86, valgrind gets confused about the call stack.
# GDB reports this:
#	mark_vectorlike
#	mark_maybe_pointer
#	mark_memory
#	mark_stack
#	Fgarbage_collect
#	Ffuncall
# but valgrind sees only the first and last functions in the chain.
{
   mark_vectorlike Value4 - conservative garbage collection
   Memcheck:Value4
   fun:mark_vectorlike
}
# There's a similar problem on Fedora 17 x86-64 with mark_maybe_object.
{
   mark_maybe_object Value8 - conservative garbage collection
   Memcheck:Value8
   fun:mark_maybe_object
}

# Fedora 17 x86-64 warns about this, for no good reason.
{
   timer_create evp arg is only partly initialized
   Memcheck:Param
   timer_create(evp)
   ...
   fun:init_atimer
}

# On Ubuntu 12.04 x86, strlen is inlined to something that loads 4 bytes
# at a time.
{
   libfontconfig optimized strlen
   Memcheck:Addr4
   obj:/usr/lib*/libfontconfig.so*
}

# On Ubuntu 12.04 x86, several libraries have issues due to unknown reasons.
{
   libgdk and libglib unknown issue
   Memcheck:Param
   writev(vector[...])
   fun:writev
}
{
   libgtk unknown issue
   Memcheck:Cond
   ...
   obj:/usr/lib*/libgtk-x11-*.so*
}
{
   libpixman unknown issue
   Memcheck:Cond
   ...
   obj:/usr/lib*/libpixman-*.so*
}
{
   librsvg unknown issue
   Memcheck:Cond
   ...
   obj:/usr/lib*/librsvg-*.so*
}