make-frame-on-display crash with HEAD

make-frame-on-display crash with HEAD

[Eric Gillespie]

wundagore is a NetBSD/i386 1.6 system with XFree86 4.2, argo is a
Mac OS X (not Jaguar) system also with XFree86 4.2.  I have emacs
running on :0 on wundagore.  I run XDawin on argo and ssh -X to
wundagore to forward argo's :0 display to wundagore.

Now, in emacs on wundagore, i do make-frame-on-display
localhost:10 (the display forwarded from argo).  The new emacs
frame appears on argo's display, but immediately after emacs
crashes.  This is 100% reproducible.  I have included a gdb
backtrace at the end of this message.

This only happens in this situation.  I can make-frame-on-display
on other displays on wundagore with no problems.  Also, i can run
emacs on wundagore displaying on argo if i run a new emacs.  The
problem only occurs with make-frame-on-display.

#0  0x484efd97 in kill ()
    at /usr/src/lib/csu/i386_elf/../common_elf/crtbegin.c:167
#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
#4  0x80c6693 in realize_face (cache=0x8b1bd00, attrs=0xbfbfc608, c=0, 
    base_face=0x0, former_face_id=0) at xfaces.c:6702
#5  0x80c64a7 in realize_default_face (f=0x8c7a200) at xfaces.c:6622
#6  0x80c5f09 in realize_basic_faces (f=0x8c7a200) at xfaces.c:6492
#7  0x80bce98 in recompute_basic_faces (f=0x8c7a200) at xfaces.c:956
#8  0x8063f39 in init_iterator (it=0xbfbfc798, w=0x8c7ac00, charpos=-1, 
    bytepos=-1, row=0x0, base_face_id=DEFAULT_FACE_ID) at xdisp.c:1587
#9  0x806f11e in x_consider_frame_title (frame=1221042688) at xdisp.c:7357
#10 0x806f2a8 in prepare_menu_bars () at xdisp.c:7416
#11 0x80714cc in redisplay_internal (preserve_echo_area=0) at xdisp.c:8628
#12 0x8070da8 in redisplay () at xdisp.c:8418
#13 0x81106b5 in read_char (commandflag=1, nmaps=2, maps=0xbfbfcf9c, 
    prev_event=405990404, used_mouse_menu=0xbfbfd058) at keyboard.c:2415
#14 0x811a506 in read_key_sequence (keybuf=0xbfbfd180, bufsize=30, 
    prompt=405990404, dont_downcase_last=0, can_return_switch_frame=1, 
    fix_current_buffer=1) at keyboard.c:8515
#15 0x810e126 in command_loop_1 () at keyboard.c:1474
#16 0x8188d4d in internal_condition_case (bfun=0x810dd7c <command_loop_1>, 
    handlers=406112740, hfun=0x810d898 <cmd_error>) at eval.c:1351
#17 0x810dbe4 in command_loop_2 () at keyboard.c:1274
#18 0x8188820 in internal_catch (tag=406065044, 
    func=0x810dbc4 <command_loop_2>, arg=405990404) at eval.c:1112
#19 0x810db95 in command_loop () at keyboard.c:1253
#20 0x810d5f7 in recursive_edit_1 () at keyboard.c:969
#21 0x810d74b in Frecursive_edit () at keyboard.c:1025
#22 0x810c024 in main (argc=1, argv=0xbfbfd494) at emacs.c:1659
#23 0x804f320 in ___start (argc=1, argv=0xbfbfd494, envp=0xbfbfd49c, 
    cleanup=0x4820cbe8 <_rtld_exit>, obj=0x48218200, ps_strings=0xbfbfdff0)
    at /usr/src/lib/csu/i386_elf/crt0.c:94

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

[Richard Stallman]

    #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.

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

[Eric Gillespie]

Richard Stallman <rms@gnu.org> 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 <*> epg@pretzelnet.org

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

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

[Eric Gillespie]

[taking this public so 100 people don't slam me for my ignorance,
hope you don't mind]

storm@cua.dk (Kim F. Storm) writes:

> etc/DEBUG gives a lot of advice here.
> 
> Notably
> 
>         p string
>         xtype
>         xstring
> 
> may be of interest here.

Thanks for the pointer.

--  
Eric Gillespie <*> epg@pretzelnet.org

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