emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: make-frame-on-display crash with HEAD


From: Eric Gillespie
Subject: Re: make-frame-on-display crash with HEAD
Date: Wed, 15 Jan 2003 16:38:37 -0500
User-agent: nmh/1.0.4+dev (i386-unknown-netbsdelf1.6)

Richard Stallman <address@hidden> writes:

>     #1  0x810a9c6 in fatal_error_signal (sig=11) at emacs.c:379
>     #2  0xbfbfdfdc in ?? ()
>     #3  0x80c8618 in lface_hash (v=0xbfbfc608) at xfaces.c:4946
> 
> Can you investigate precisely what is happening inside frame
> #3?  You could see the name of the function it called in frame #2,
> and then with a breakpoint and stepping, you could figure out precisely
> why it gets a signal.

I think frame #2 is just some OS-specific signal-handling gunk,
or maybe the hash_string_case_insensitive function where the
segmentation fault actually occurs.  hash_string_case_insensitive
is in fact the only function lface_hash calls.

To learn this, i set a breakpoint at lface_hash and proceeded to
do the make-frame-on-display.  lface_hash is called a *lot*,
sometimes where emacs appears simply to be sitting there, and
many times during text input.

At any rate, i finally reached the point where it segfaults:

Program received signal SIGSEGV, Segmentation fault.
0x80c8e0f in hash_string_case_insensitive (string=406057516) at xfaces.c:4934
(gdb) print s
$1 = (
    unsigned char *) 0x1832ec1c <Error reading address 0x1832ec1c: Invalid 
argument>
(gdb) print string
$2 = 406057516

Here is the function in question:

static INLINE unsigned
hash_string_case_insensitive (string)
     Lisp_Object string;
{
  const unsigned char *s;
  unsigned hash = 0;
  xassert (STRINGP (string));
  for (s = SDATA (string); *s; ++s)
    hash = (hash << 1) ^ tolower (*s);
  return hash;
}

The crash actually occurs in the for statement, at '*s'.  string
seems to be fine, but SDATA (string) is not.

These Lisp_Object are awfully hard to inspect in the debugger due
to all the macro hair.  Are their function versions of the macros
that i can call from gdb?  If not, there ought to be.

--  
Eric Gillespie <*> address@hidden

Build a fire for a man, and he'll be warm for a day.  Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett




reply via email to

[Prev in Thread] Current Thread [Next in Thread]