unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* emacs crash
@ 2003-08-16 13:56 Werner LEMBERG
  2003-08-18  4:52 ` Richard Stallman
  0 siblings, 1 reply; 22+ messages in thread
From: Werner LEMBERG @ 2003-08-16 13:56 UTC (permalink / raw)



[This is CVS 2003-07-30]

I just got the following crash.  Please tell me what I shall do.


    Werner


======================================================================

Program received signal SIGSEGV, Segmentation fault.
0x081259f8 in mark_object (arg=543454268) at alloc.c:4991
4991          if (XMARKER (obj)->gcmarkbit)
#0  0x081259f8 in mark_object (arg=543454268) at alloc.c:4991
        obj = 6583356
        cdr_count = 0
#1  0x081255e8 in mark_object (arg=1487814016) at alloc.c:4831
        size = 48
        i = 0
        obj = 0
        cdr_count = 0
#2  0x081224b9 in mark_interval (i=0x8d8ece4, dummy=405548708) at alloc.c:1187
        i = 0x2
#3  0x081710ed in traverse_intervals_noorder (tree=0x8d8ece4, 
    function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:207
        tree = 0x8d8ece4
        function = (void (*)()) 0x81224a0 <mark_interval>
        arg = 405548708
#4  0x0817110e in traverse_intervals_noorder (tree=0x8d8ed00, 
    function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:212
        tree = 0x8d8ed00
        function = (void (*)()) 0x81224a0 <mark_interval>
        arg = 405548708
#5  0x0817110e in traverse_intervals_noorder (tree=0x8d8ecc8, 
    function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:212
        tree = 0x8d8ed38
        function = (void (*)()) 0x81224a0 <mark_interval>
        arg = 405548708
#6  0x0817110e in traverse_intervals_noorder (tree=0x8d8ee18, 
    function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:212
        tree = 0x8d8ee18
        function = (void (*)()) 0x81224a0 <mark_interval>
        arg = 405548708
#7  0x0817110e in traverse_intervals_noorder (tree=0x8d8ee88, 
    function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:212
        tree = 0x8d8ee88
        function = (void (*)()) 0x81224a0 <mark_interval>
        arg = 405548708
#8  0x0817110e in traverse_intervals_noorder (tree=0x8dc9684, 
    function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:212
        tree = 0x8d8ef68
        function = (void (*)()) 0x81224a0 <mark_interval>
        arg = 405548708
#9  0x0817110e in traverse_intervals_noorder (tree=0x8a543e0, 
    function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:212
        tree = 0x8d798bc
        function = (void (*)()) 0x81224a0 <mark_interval>
        arg = 405548708
#10 0x0817110e in traverse_intervals_noorder (tree=0x8aa91f4, 
    function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:212
        tree = 0x8aa91f4
        function = (void (*)()) 0x81224a0 <mark_interval>
        arg = 405548708
#11 0x081224dd in mark_interval_tree (tree=0x8aa91f4) at alloc.c:1202
        tree = 0x2
#12 0x08125bb4 in mark_buffer (buf=1219647024) at alloc.c:5098
        buffer = (struct buffer *) 0x8b25630
        ptr = (int *) 0x48b25630
        tmp = 2
        base_buffer = 2
#13 0x0812558c in mark_object (arg=1219647024) at alloc.c:4808
        obj = 1219647024
        cdr_count = 0
#14 0x08125a4a in mark_object (arg=677176588) at alloc.c:5008
        obj = 140305676
        cdr_count = 0
#15 0x0812596e in mark_object (arg=405681452) at alloc.c:4968
        ptr = (struct Lisp_Symbol *) 0x82e352c
        obj = 137245996
        cdr_count = 0
#16 0x08125b1b in mark_object (arg=1490682944) at alloc.c:5061
        ptr = (struct Lisp_Cons *) 0x8da0440
        obj = 148506600
        cdr_count = 0
#17 0x08125b1b in mark_object (arg=1490682952) at alloc.c:5061
        ptr = (struct Lisp_Cons *) 0x8da0448
        obj = 148506600
        cdr_count = 0
#18 0x08125dbe in mark_buffer (buf=1218972696) at alloc.c:5150
        buffer = (struct buffer *) 0x8a80c18
        ptr = (int *) 0x8a80d00
        tmp = 2
        base_buffer = 2
#19 0x0812558c in mark_object (arg=1218972696) at alloc.c:4808
        obj = 1218972696
        cdr_count = 0
#20 0x08125a4a in mark_object (arg=681782748) at alloc.c:5008
        obj = 144911836
        cdr_count = 0
#21 0x0812596e in mark_object (arg=405706996) at alloc.c:4968
        ptr = (struct Lisp_Symbol *) 0x82f5b0c
        obj = 137321228
        cdr_count = 0
...

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs crash
  2003-08-16 13:56 Werner LEMBERG
@ 2003-08-18  4:52 ` Richard Stallman
  0 siblings, 0 replies; 22+ messages in thread
From: Richard Stallman @ 2003-08-18  4:52 UTC (permalink / raw)
  Cc: emacs-devel

    0x081259f8 in mark_object (arg=543454268) at alloc.c:4991
    4991          if (XMARKER (obj)->gcmarkbit)
    #0  0x081259f8 in mark_object (arg=543454268) at alloc.c:4991
	    obj = 6583356
	    cdr_count = 0
    #1  0x081255e8 in mark_object (arg=1487814016) at alloc.c:4831
	    size = 48
	    i = 0
	    obj = 0
	    cdr_count = 0

You need to look at the objects being marked in these calls, and the
data structure they belong to, and figure out what's invalid
about the data structure.

That is the first step.  After that step, there will probably be more
debugging to do, but we can't guess now what it will be.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* emacs crash
@ 2003-10-08 12:42 Werner LEMBERG
  0 siblings, 0 replies; 22+ messages in thread
From: Werner LEMBERG @ 2003-10-08 12:42 UTC (permalink / raw)



[CVS 2003-09-29]

Below is a backtrace of an Emacs crash which hasn't happened during
garbage collection.  I still have this Emacs process so I can execute
your commands if necessary.  IIRC, the segfault happened while
scrolling new Email (with various character sets) in Mew.

Of the variables shown under #0, `faces' and `char2b' are invalid
pointers (besides `s' and `first_s', of course).


    Werner


======================================================================

Program received signal SIGSEGV, Segmentation fault.
0x08078bd3 in draw_glyphs (w=0x8f5e638, x=157, row=0x8e44590, area=TEXT_AREA, 
    start=0, end=62, hl=DRAW_NORMAL_TEXT, overlaps_p=0) at xdisp.c:17461
17461     BUILD_GLYPH_STRINGS (i, end, head, tail, hl, x, last_x);
(gdb) bt full
#0  0x08078bd3 in draw_glyphs (w=0x8f5e638, x=157, row=0x8e44590, 
    area=TEXT_AREA, start=0, end=62, hl=DRAW_NORMAL_TEXT, overlaps_p=0)
    at xdisp.c:17461
        c = 2747
        this_face_id = 150339144
        cmp_id = 2747
        face_id = 150339144
        base_face = (struct face *) 0x8ad25e0
        char2b = (XChar2b *) 0x3fffe154
        cmp = (struct composition *) 0x8f5fe80
        glyph_len = 1073741826
        faces = (struct face **) 0x3fffe144
        first_s = (struct glyph_string *) 0x0
        n = 0
        head = (struct glyph_string *) 0xbfffe664
        tail = (struct glyph_string *) 0xbfffe1d4
        s = (struct glyph_string *) 0xabb
        last_x = 973
        x_reached = 149177744
        i = 12
        j = -1073748396
        f = (struct frame *) 0x8640de8
#1  0x0807d00e in x_write_glyphs (start=0x8ff58f0, len=62) at xdisp.c:18503
        start = (struct glyph *) 0x8f5fe48
        x = 149177744
#2  0x08053fa5 in update_text_area (w=0x8f5e638, vpos=0) at dispnew.c:4270
        current_row = (struct glyph_row *) 0x8f589f8
        desired_row = (struct glyph_row *) 0x8e44590
        changed_p = 0
#3  0x080543e6 in update_window_line (w=0x8f5e638, vpos=0, 
    mouse_face_overwritten_p=0xbfffe938) at dispnew.c:4494
        w = (struct window *) 0x8f5e638
        mouse_face_overwritten_p = (int *) 0x0
        current_row = (struct glyph_row *) 0x8f589f8
        desired_row = (struct glyph_row *) 0x8e44590
        changed_p = 0
#4  0x08053d2b in update_window (w=0x8f5e638, force_p=0) at dispnew.c:4150
        vpos = 0
        i = 150339144
        end = (struct glyph_row *) 0x8e45980
        mode_line_row = (struct glyph_row *) 0x8f5fe80
        header_line_row = (struct glyph_row *) 0x0
        changed_p = 1
        mouse_face_overwritten_p = 0
        row = (struct glyph_row *) 0x8e44590
        yb = 504
        n_updated = 1
        desired_matrix = (struct glyph_matrix *) 0x8c2abe0
        paused_p = 0
        preempt_count = 9
#5  0x08053793 in update_window_tree (w=0x8f94f40, force_p=0) at dispnew.c:3885
        w = (struct window *) 0x8f5e638
        force_p = 0
        paused_p = 0
#6  0x08053778 in update_window_tree (w=0x8f97a88, force_p=0) at dispnew.c:3883
        w = (struct window *) 0x8f97a88
        force_p = 0
        paused_p = 0
#7  0x08053691 in update_frame (f=0x8640de8, force_p=0, inhibit_hairy_id_p=0)
    at dispnew.c:3822
        f = (struct frame *) 0x8640de8
        inhibit_hairy_id_p = 0
        paused_p = 140818216
        root_window = (struct window *) 0x8f97a88
#8  0x0806cdba in redisplay_internal (preserve_echo_area=0) at xdisp.c:10050
        f = (struct frame *) 0x8640de8
        tail = 150339144
        frame = 150339144
        i = 1
        updated = (struct frame **) 0xbfffe9f4
        n = 0
        size = 50
        w = (struct window *) 0x8f94f40
        f = (struct frame *) 0x8f5fe80
        pause = 0
        must_finish = 1
        tlbufpos = {charpos = 64537, bytepos = 64644}
        tlendpos = {charpos = 6428, bytepos = 6508}
        number_of_visible_frames = 1
        count = 2
        polling_stopped_here = 1
        consider_all_windows_p = 1
#9  0x0806bcd0 in redisplay () at xdisp.c:9448
No locals.
#10 0x080e1375 in read_char (commandflag=1, nmaps=2, maps=0xbffff0f4, 
    prev_event=675054316, used_mouse_menu=0xbffff148) at keyboard.c:2495
        c = 675054316
        count = 0
        local_getcjmp = {{__jmpbuf = {0, 0, 138441496, -1471787984, 675428364, 
      135432523}, __mask_was_saved = 138441496, __saved_mask = {__val = {
        3221221484, 3221221484, 135432701, 675428364, 675054316, 675054316, 0, 
        1212183320, 675428364, 675428364, 135457263, 140715040, 2288198688, 
        3221221532, 135432844, 675428364, 1212183320, 64537, 135748393, 2, 0, 
        516296, 675054316, 3221221332, 64537, 3221221612, 135195085, 
        675404660, 0, 0, 135743368, 2}}}}
        save_jump = {{__jmpbuf = {135740232, -1460667568, 675147572, 1, 
      -1073745988, 135747853}, __mask_was_saved = 64536, __saved_mask = {
      __val = {3221221308, 135747862, 2834299728, 675147572, 0, 140715040, 0, 
        1, 3221221532, 135457649, 64536, 675147572, 2288198688, 135457649, 
        1215067860, 675260524, 2288198688, 135437987, 1215067860, 141495344, 
        142050320, 0, 1, 19, 3221221148, 135504025, 2826020352, 0, 8192, 0, 
        138441496, 2823179312}}}}
        key_already_recorded = 0
        tem = 0
        save = 0
        previous_echo_area_message = 675054316
        also_record = 675054316
        reread = 0
        gcpro1 = {next = 0x486c76d4, var = 0xffffffff, nvars = 140715040}
        gcpro2 = {next = 0x283c82ec, var = 0xbfffef7c, nvars = -1073746032}
        last_idle_start = {tv_sec = 675054316, tv_usec = 64536}
        polling_stopped_here = 0
#11 0x080e881f in read_key_sequence (keybuf=0xbffff254, bufsize=30, 
    prompt=675054316, dont_downcase_last=0, can_return_switch_frame=1, 
    fix_current_buffer=1) at keyboard.c:8825
        key = 209
        used_mouse_menu = 0
        echo_local_start = 0
        last_real_key_start = 0
        keys_local_start = 0
        local_first_binding = 0
        from_string = 675054316
        count = 2
        t = 0
        echo_start = 0
        keys_start = 0
        nmaps = 2
        nmaps_allocated = 2
        defs = (int *) 0xbffff0e4
        submaps = (int *) 0xbffff0f4
        orig_local_map = -1469255984
        orig_keymap = 675054316
        localized_local_map = 0
        first_binding = 0
        first_unbound = 31
        mock_input = 0
        fkey = {map = -1472400872, parent = -1472400872, start = 0, end = 0}
        keytran = {map = -1471723376, parent = -1471723376, start = 0, end = 0}
        delayed_switch_frame = 675054316
        original_uppercase = 0
        original_uppercase_position = -1
        starting_buffer = (struct buffer *) 0x8632420
        fake_prefixed_keys = 675054316
        gcpro1 = {next = 0x0, var = 0x0, nvars = -1073745492}
#12 0x080df764 in command_loop_1 () at keyboard.c:1504
        cmd = 2
        lose = 2
        nonundocount = 0
        keybuf = {32, 98, -1073745220, 135131396, -1459750176, -1073745272, 
  -1073745220, 135131319, 0, 1, -1073743836, 1077983524, 135701888, 
  -1073744896, 17, 1076885774, 177478308, 1073775649, -1073745104, 32, 
  -1073745020, 0, -1073745312, -1073745452, 0, 1073741824, -1073744964, 
  135494457, -1073745148, -1073744768}
        i = 2
        no_direct = 0
        prev_modiff = 6467
        prev_buffer = (struct buffer *) 0x8632420
        was_locked = 0
        already_adjusted = 0
#13 0x08137b8d in internal_condition_case (bfun=0x80df450 <command_loop_1>, 
    handlers=675148004, hfun=0x80df030 <cmd_error>) at eval.c:1333
        val = 150339144
        c = {tag = 675054316, val = 675054316, next = 0xbffff404, gcpro = 0x0, 
  jmp = {{__jmpbuf = {0, 1, -1073743836, -1073744964, -1073745212, 135494457}, 
      __mask_was_saved = 0, __saved_mask = {__val = {3221222348, 3221222100, 
          135494457, 0, 134530924, 335544320, 1076991992, 1076844252, 
          1074843024, 0 <repeats 16 times>, 3221222356, 1073787006, 
          1073827532, 1078006536, 1, 0, 0}}}}, backlist = 0x0, 
  handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, 
  poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0}
        h = {handler = 675148004, var = 675054316, chosen_clause = 675054364, 
  tag = 0xbffff2f4, next = 0x0}
#14 0x080df2fe in command_loop_2 () at keyboard.c:1292
        val = 0
#15 0x081376f5 in internal_catch (tag=675109268, 
    func=0x80df2e0 <command_loop_2>, arg=675054316) at eval.c:1094
        tag = 150339144
        c = {tag = 675109268, val = 675054316, next = 0x0, gcpro = 0x0, jmp = {
    {__jmpbuf = {0, 1, -1073743836, -1073744692, -1073744924, 135493346}, 
      __mask_was_saved = 0, __saved_mask = {__val = {3221222620, 3221222388, 
          135493346, 0, 3221222528, 3221222539, 0, 1077983524, 808465724, 
          3221222428, 1077248756, 5, 1077986688, 138389272, 138411460, 
          1212131096, 3221222204, 138209992, 675054316, 3221222588, 135434098, 
          675282372, 1212131096, 675054316, 138231648, 138411460, 675282372, 
          1212131096, 0, 138411460, 675282372, 137907392}}}}, backlist = 0x0, 
  handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, 
  poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0}
#16 0x080df2a3 in command_loop () at keyboard.c:1271
No locals.
#17 0x080deda4 in recursive_edit_1 () at keyboard.c:987
        count = 1
        val = 0
#18 0x080deee1 in Frecursive_edit () at keyboard.c:1043
        count = 0
        buffer = 0
#19 0x080ddc35 in main (argc=1, argv=0xbffff824) at emacs.c:1666
        dummy = 0
        stack_bottom_variable = 0 '\0'
        skip_args = 0
        rlim = {rlim_cur = 8388608, rlim_max = 18446744073709551615}
        no_loadup = 0
        junk = 0x0
#20 0x403087ee in __libc_start_main () from /lib/libc.so.6

^ permalink raw reply	[flat|nested] 22+ messages in thread

* emacs crash
@ 2004-11-03  9:55 B. Anyos
  2004-11-03 10:28 ` Jason Rumney
  0 siblings, 1 reply; 22+ messages in thread
From: B. Anyos @ 2004-11-03  9:55 UTC (permalink / raw)


Hi,

I checked out the latest version form CVS.
I cleaned my version and compiled it from sratch.
Even tried "nmake bootstrap".

When I try to exeucte emacs it crashed with a message box:

   ==================
   Emacs Abort Dialog
   ==================
   "A fatal error occured!"
   "Select Abort to exit, Retry to debug, Ignore to continue"

Any idea how can I fix this.

Bela

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs crash
  2004-11-03  9:55 emacs crash B. Anyos
@ 2004-11-03 10:28 ` Jason Rumney
  2004-11-03 10:50   ` B. Anyos
  2004-11-03 11:06   ` Dhruva Krishnamurthy
  0 siblings, 2 replies; 22+ messages in thread
From: Jason Rumney @ 2004-11-03 10:28 UTC (permalink / raw)
  Cc: emacs-devel

B. Anyos wrote:

> When I try to exeucte emacs it crashed with a message box:
>
>   ==================
>   Emacs Abort Dialog
>   ==================
>   "A fatal error occured!"
>   "Select Abort to exit, Retry to debug, Ignore to continue"
>
Did you try pressing Retry? If you have a just-in-time debugger 
installed, that should show where the program is crashing.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs crash
  2004-11-03 10:28 ` Jason Rumney
@ 2004-11-03 10:50   ` B. Anyos
  2004-11-03 11:21     ` Jason Rumney
  2004-11-03 11:06   ` Dhruva Krishnamurthy
  1 sibling, 1 reply; 22+ messages in thread
From: B. Anyos @ 2004-11-03 10:50 UTC (permalink / raw)
  Cc: Jason Rumney

Jason Rumney said the following on 11/3/2004 11:28 AM:
> B. Anyos wrote:
> 
>> When I try to exeucte emacs it crashed with a message box:
>>
>>   ==================
>>   Emacs Abort Dialog
>>   ==================
>>   "A fatal error occured!"
>>   "Select Abort to exit, Retry to debug, Ignore to continue"
>>
> Did you try pressing Retry? If you have a just-in-time debugger 
> installed, that should show where the program is crashing.
>  
Sure in the meantime I did. It crashed in emacs\src\eval.c
at line 409.

	DEFUN ("progn", Fprogn, Sprogn, 0, UNEVALLED, 0,
        		doc: /* Eval BODY forms sequentially and return value of last one.
	usage: (progn BODY ...)  */)
	     (args)
	     Lisp_Object args;
	{
	  register Lisp_Object val = Qnil;
	  struct gcpro gcpro1;
	
	  GCPRO1 (args);
	
	  while (CONSP (args))
	    {
	      val = Feval (XCAR (args));
      ->	      args = XCDR (args);
	    }
	
	  UNGCPRO;
	  return val;
	}

Here is the stack trace:

NTDLL! 77f75a58()
Fprogn(int -1592181732) line 409
unbind_to(int 656, int 556594176) line 3124
Fbyte_code(int 18430916, int -2129052740, int 7) line 716 + 17 bytes
funcall_lambda(int -2129052976, int 3, int * 0x0082f188) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f188) line 2814 + 12 bytes
Fbyte_code(int 19015816, int -2128467840, int 4) line 688
funcall_lambda(int -2128467916, int 1, int * 0x0082f244) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f244) line 2814 + 12 bytes
Fbyte_code(int 19018312, int -2128465344, int 5) line 688
funcall_lambda(int -2128465448, int 2, int * 0x0082f304) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f304) line 2814 + 12 bytes
call2(int 556627832, int 1633770048, int -2127346688) line 2569 + 11 bytes
tty_lookup_color() line 1320
tty_defined_color() line 1385 + 18 bytes
load_face_colors(frame * 0x01334400, face * 0x015ce500, int * 0x61724310) line 1680 + 45 bytes
realize_x_face(face_cache * 0x01334400, int * 0x0082f3f8, int 0, face * 0x00000000) line 7144
realize_face(face_cache * 0x01710080, int * 0x0082f3f8, int 0, face * 0x00000000, int 0) line 7040 + 15 bytes
realize_default_face(frame * 0x812ca600) line 6967 + 17 bytes
realize_basic_faces(frame * 0x01334400) line 6834 + 9 bytes
Fdisplay_supports_face_attributes_p(int -1590125944, int -2127346688) line 6132 + 6 bytes
Ffuncall(int -2147483648, int * 0x0082f508) line 2761 + 8 bytes
Fbyte_code(int 18628360, int -2128855296, int 5) line 688
funcall_lambda(int -2128855556, int 2, int * 0x0082f5c8) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f5c8) line 2814 + 12 bytes
Fbyte_code(int 18628728, int -2128854928, int 4) line 688
funcall_lambda(int -2128855088, int 2, int * 0x0082f684) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f684) line 2814 + 12 bytes
Fbyte_code(int 18629200, int -2128854456, int 6) line 688
funcall_lambda(int -2128854656, int 3, int * 0x0082f748) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f748) line 2814 + 12 bytes
Fbyte_code(int 18634476, int -2128849180, int 5) line 688
Feval(int 8583088) line 2120
Fcondition_case(int -1589005424) line 1314 + 62 bytes
Fbyte_code(int 18634264, int -2128849392, int 9) line 864 + 17 bytes
funcall_lambda(int -2128849612, int 1, int * 0x0082f980) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
call1(int 556794192, int -2127346688) line 2547 + 11 bytes
Fx_create_frame(int 0) line 4355
Ffuncall(int -2147483648, int * 0x0082fa0c) line 2758
Fbyte_code(int 18633764, int -2128849892, int 5) line 688
funcall_lambda(int -2128850016, int 1, int * 0x0082fac4) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fac4) line 2814 + 12 bytes
Fbyte_code(int 19004120, int -2128479536, int 3) line 688
funcall_lambda(int -2128479620, int 1, int * 0x0082fb7c) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fb7c) line 2814 + 12 bytes
Fbyte_code(int 19000176, int -2128483480, int 4) line 688
funcall_lambda(int -2128483612, int 0, int * 0x0082fc38) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fc38) line 2814 + 12 bytes
Fbyte_code(int 19140348, int -2128343308, int 6) line 688
funcall_lambda(int -2128344604, int 0, int * 0x0082fcfc) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fcfc) line 2814 + 12 bytes
Fbyte_code(int 19134352, int -2128349304, int 7) line 688
funcall_lambda(int -2128349488, int 0, int * 0x0082fd8c) line 2946 + 17 bytes
apply_lambda(int -2128349488, int 556594176, int 1) line 2869
Feval(int -2147483648) line 2170 + 11 bytes
top_level_2() line 1317 + 11 bytes
internal_condition_case(int (void)* 0x0100e695 top_level_2(void), int 556679768, int (void)* 0x0100e3fd cmd_error(void)) line 1368
top_level_1() line 1326 + 21 bytes
internal_catch(int 556676056, int (void)* 0x0100e6a2 top_level_1(void), int 556594176) line 1128 + 6 bytes
command_loop() line 1288
recursive_edit_1() line 981 + 5 bytes
Frecursive_edit() line 1043
main() line 1738 + 5 bytes
EMACS! mainCRTStartup + 180 bytes
KERNEL32! 77e8141a()

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs crash
  2004-11-03 10:28 ` Jason Rumney
  2004-11-03 10:50   ` B. Anyos
@ 2004-11-03 11:06   ` Dhruva Krishnamurthy
  2004-11-03 14:09     ` CHENG Gao
  1 sibling, 1 reply; 22+ messages in thread
From: Dhruva Krishnamurthy @ 2004-11-03 11:06 UTC (permalink / raw)
  Cc: B. Anyos, emacs-devel

Hello,
 I had the same results on my XP box. Here goes the stack trace for
(runemacs -q):

NTDLL! 77f767cd()
Fprogn(int -1592177612) line 409
unbind_to(int 656, int 556578816) line 3124
Fbyte_code(int 18435036, int -2129048620, int 7) line 716 + 17 bytes
funcall_lambda(int -2129048856, int 3, int * 0x0082f188) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f188) line 2814 + 12 bytes
Fbyte_code(int 19019936, int -2128463720, int 4) line 688
funcall_lambda(int -2128463796, int 1, int * 0x0082f244) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f244) line 2814 + 12 bytes
Fbyte_code(int 19022432, int -2128461224, int 5) line 688
funcall_lambda(int -2128461328, int 2, int * 0x0082f304) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f304) line 2814 + 12 bytes
call2(int 556641144, int 1633580288, int -2127505408) line 2569 + 11 bytes
tty_lookup_color() line 1320
tty_defined_color() line 1385 + 18 bytes
load_face_colors(frame * 0x0130d800, face * 0x01541000, int *
0x61724310) line 1680 + 45 bytes
realize_x_face(face_cache * 0x0130d800, int * 0x0082f3f8, int 0, face
* 0x00000000) line 7144
realize_face(face_cache * 0x0170e540, int * 0x0082f3f8, int 0, face *
0x00000000, int 0) line 7040 + 15 bytes
realize_default_face(frame * 0x812cc800) line 6967 + 17 bytes
realize_basic_faces(frame * 0x0130d800) line 6834 + 9 bytes
Fdisplay_supports_face_attributes_p(int -1590109480, int -2127505408)
line 6132 + 6 bytes
Ffuncall(int -2147483648, int * 0x0082f508) line 2761 + 8 bytes
Fbyte_code(int 18632480, int -2128851176, int 5) line 688
funcall_lambda(int -2128851436, int 2, int * 0x0082f5c8) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f5c8) line 2814 + 12 bytes
Fbyte_code(int 18632848, int -2128850808, int 4) line 688
funcall_lambda(int -2128850968, int 2, int * 0x0082f684) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f684) line 2814 + 12 bytes
Fbyte_code(int 18633320, int -2128850336, int 6) line 688
funcall_lambda(int -2128850536, int 3, int * 0x0082f748) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f748) line 2814 + 12 bytes
Fbyte_code(int 18638596, int -2128845060, int 5) line 688
Feval(int 8583088) line 2120
Fcondition_case(int -1588988960) line 1314 + 62 bytes
Fbyte_code(int 18638384, int -2128845272, int 9) line 864 + 17 bytes
funcall_lambda(int -2128845492, int 1, int * 0x0082f980) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
call1(int 556796240, int -2127505408) line 2547 + 11 bytes
Fx_create_frame(int 0) line 4355
Ffuncall(int -2147483648, int * 0x0082fa0c) line 2758
Fbyte_code(int 18637884, int -2128845772, int 5) line 688
funcall_lambda(int -2128845896, int 1, int * 0x0082fac4) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fac4) line 2814 + 12 bytes
Fbyte_code(int 19008240, int -2128475416, int 3) line 688
funcall_lambda(int -2128475500, int 1, int * 0x0082fb7c) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fb7c) line 2814 + 12 bytes
Fbyte_code(int 19004296, int -2128479360, int 4) line 688
funcall_lambda(int -2128479492, int 0, int * 0x0082fc38) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fc38) line 2814 + 12 bytes
Fbyte_code(int 19144468, int -2128339188, int 6) line 688
funcall_lambda(int -2128340484, int 0, int * 0x0082fcfc) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fcfc) line 2814 + 12 bytes
Fbyte_code(int 19138472, int -2128345184, int 7) line 688
funcall_lambda(int -2128345368, int 0, int * 0x0082fd8c) line 2946 + 17 bytes
apply_lambda(int -2128345368, int 556578816, int 1) line 2869
Feval(int -2147483648) line 2170 + 11 bytes
top_level_2() line 1317 + 11 bytes
internal_condition_case(int (void)* 0x0100e695 top_level_2(void), int
556684888, int (void)* 0x0100e3fd cmd_error(void)) line 1368
top_level_1() line 1326 + 21 bytes
internal_catch(int 556681176, int (void)* 0x0100e6a2
top_level_1(void), int 556578816) line 1128 + 6 bytes
command_loop() line 1288
recursive_edit_1() line 981 + 5 bytes
Frecursive_edit() line 1043
main() line 1738 + 5 bytes
EMACS! mainCRTStartup + 180 bytes
KERNEL32! 77e814c7()



On Wed, 03 Nov 2004 10:28:43 +0000, Jason Rumney <jasonr@gnu.org> wrote:
> B. Anyos wrote:
> 
> > When I try to exeucte emacs it crashed with a message box:
> >
> >   ==================
> >   Emacs Abort Dialog
> >   ==================
> >   "A fatal error occured!"
> >   "Select Abort to exit, Retry to debug, Ignore to continue"
> >
> Did you try pressing Retry? If you have a just-in-time debugger
> installed, that should show where the program is crashing.

-dhruva

-- 
Proud FSF member: #1935
http://schemer.fateback.com/

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs crash
  2004-11-03 10:50   ` B. Anyos
@ 2004-11-03 11:21     ` Jason Rumney
  2004-11-03 11:29       ` Dhruva Krishnamurthy
  2004-11-03 12:02       ` B. Anyos
  0 siblings, 2 replies; 22+ messages in thread
From: Jason Rumney @ 2004-11-03 11:21 UTC (permalink / raw)
  Cc: emacs-devel

B. Anyos wrote:

> tty_lookup_color() line 1320
> tty_defined_color() line 1385 + 18 bytes

This looks suspicious. I don't think tty_lookup_color() should be called 
if you are not starting Emacs with -nw.

My guess is that something is trying to define a face before the initial 
frame is created.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs crash
  2004-11-03 11:21     ` Jason Rumney
@ 2004-11-03 11:29       ` Dhruva Krishnamurthy
  2004-11-03 12:02       ` B. Anyos
  1 sibling, 0 replies; 22+ messages in thread
From: Dhruva Krishnamurthy @ 2004-11-03 11:29 UTC (permalink / raw)
  Cc: B. Anyos, emacs-devel

On Wed, 03 Nov 2004 11:21:38 +0000, Jason Rumney <jasonr@gnu.org> wrote:
> B. Anyos wrote:
> 
> > tty_lookup_color() line 1320
> > tty_defined_color() line 1385 + 18 bytes
> 
> This looks suspicious. I don't think tty_lookup_color() should be called
> if you are not starting Emacs with -nw.
> 
> My guess is that something is trying to define a face before the initial
> frame is created.

BTW, emacs -q -nw works!

-- 
Proud FSF member: #1935
http://schemer.fateback.com/

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs crash
  2004-11-03 11:21     ` Jason Rumney
  2004-11-03 11:29       ` Dhruva Krishnamurthy
@ 2004-11-03 12:02       ` B. Anyos
  1 sibling, 0 replies; 22+ messages in thread
From: B. Anyos @ 2004-11-03 12:02 UTC (permalink / raw)
  Cc: Jason Rumney



Jason Rumney said the following on 11/3/2004 12:21 PM:
> B. Anyos wrote:
> 
>> tty_lookup_color() line 1320
>> tty_defined_color() line 1385 + 18 bytes
> 
> 
> This looks suspicious. I don't think tty_lookup_color() should be called 
> if you are not starting Emacs with -nw.
> 
> My guess is that something is trying to define a face before the initial 
> frame is created.
> 
> 
> 
It is interesting, though because it's been working recently. Only today I pulled
the latest sources and then it crashed.
BTW, 'emacs -nw' works fine. (Note that -q is omitted intentionally)

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs crash
  2004-11-03 11:06   ` Dhruva Krishnamurthy
@ 2004-11-03 14:09     ` CHENG Gao
  2004-11-03 15:02       ` B. Anyos
  2004-11-04  9:51       ` Richard Stallman
  0 siblings, 2 replies; 22+ messages in thread
From: CHENG Gao @ 2004-11-03 14:09 UTC (permalink / raw)


I think RMS' latest commit to eval.c caused this.

,----
| CVSROOT:	/cvsroot/emacs
| Module name:	emacs
| Branch: 	
| Changes by:	Richard M. Stallman <rms@gnu.org>	04/11/02 08:59:26
| 
| Modified files:
| 	src            : eval.c 
| 
| Log message:
| 	(Fcall_interactive_p): New function.
| 	(interactive_p): Don't test INTERACTIVE here.
| 	(Finteractive_p): Doc fix.
| 
| 	(Feval): Abort if INPUT_BLOCKED_P.
| 
| CVSWeb URLs:
| http://savannah.gnu.org/cgi-bin/viewcvs/emacs/emacs/src/eval.c.diff?tr1=1.221&tr2=1.222&r1=text&r2=text
`----

I have a temp solution:
open src/eval.c, go to line 1999, and change:

if (handling_signal || INPUT_BLOCKED_P)

to

if (handling_signal)

then rebuild Emacs.

Maybe it's only a workaround, not a real solution.

HTH,


-- 
花开花谢春不管,拂意事休对人言
水暖水寒鱼自知,会心处还期独赏

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs crash
  2004-11-03 14:09     ` CHENG Gao
@ 2004-11-03 15:02       ` B. Anyos
  2004-11-04  9:51         ` Richard Stallman
  2004-11-04  9:51       ` Richard Stallman
  1 sibling, 1 reply; 22+ messages in thread
From: B. Anyos @ 2004-11-03 15:02 UTC (permalink / raw)
  Cc: CHENG Gao

Hi,

Thanks for the tip.
It worked for me, too.

Bela

CHENG Gao said the following on 11/3/2004 15:09 PM:
> I think RMS' latest commit to eval.c caused this.
> 
> ,----
> | CVSROOT:	/cvsroot/emacs
> | Module name:	emacs
> | Branch: 	
> | Changes by:	Richard M. Stallman <rms@gnu.org>	04/11/02 08:59:26
> | 
> | Modified files:
> | 	src            : eval.c 
> | 
> | Log message:
> | 	(Fcall_interactive_p): New function.
> | 	(interactive_p): Don't test INTERACTIVE here.
> | 	(Finteractive_p): Doc fix.
> | 
> | 	(Feval): Abort if INPUT_BLOCKED_P.
> | 
> | CVSWeb URLs:
> | http://savannah.gnu.org/cgi-bin/viewcvs/emacs/emacs/src/eval.c.diff?tr1=1.221&tr2=1.222&r1=text&r2=text
> `----
> 
> I have a temp solution:
> open src/eval.c, go to line 1999, and change:
> 
> if (handling_signal || INPUT_BLOCKED_P)
> 
> to
> 
> if (handling_signal)
> 
> then rebuild Emacs.
> 
> Maybe it's only a workaround, not a real solution.
> 
> HTH,
> 
> 

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs crash
  2004-11-03 14:09     ` CHENG Gao
  2004-11-03 15:02       ` B. Anyos
@ 2004-11-04  9:51       ` Richard Stallman
  1 sibling, 0 replies; 22+ messages in thread
From: Richard Stallman @ 2004-11-04  9:51 UTC (permalink / raw)
  Cc: emacs-devel

If the crash is coming from my recent debugging check in eval.c,
and was not fixed by Jan's recent changes, then it is due to
a bug that is as yet unknown.

When a debugging assertion finds a problem, please do NOT suggest
removing the debugging assertion as a "workaround".  That is not
constructive; in fact, it is likely to interfere with fixing the real
bug.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs crash
  2004-11-03 15:02       ` B. Anyos
@ 2004-11-04  9:51         ` Richard Stallman
  2004-11-04 10:31           ` Jason Rumney
  0 siblings, 1 reply; 22+ messages in thread
From: Richard Stallman @ 2004-11-04  9:51 UTC (permalink / raw)
  Cc: chenggao, emacs-devel

    Thanks for the tip.
    It worked for me, too.

This may have "worked" in the sense of making the crash stop for you,
but it did not "work" for helping us to fix the bug.  We need more
information to do that.

For instance, there is something really strange here:

    funcall_lambda(int -2128849612, int 1, int * 0x0082f980) line 2946 + 17 bytes
    Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
    call1(int 556794192, int -2127346688) line 2547 + 11 bytes
    Fx_create_frame(int 0) line 4355

There is no call to Fx_create_frame in line 4355; in fact, line 4355
is far after the end of Fx_create_frame.  What's going on?  I need to
see where the call actually came from, and whether it was within
BLOCK_INPUT.

Can you examine the value 556794192 with xtype and see what sort of
Lisp object it is?  If it is a symbol, use xsymbol to see what its
name is.  See etc/DEBUG for more details on how to use these commands.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs crash
  2004-11-04  9:51         ` Richard Stallman
@ 2004-11-04 10:31           ` Jason Rumney
  2004-11-04 12:52             ` B. Anyos
                               ` (2 more replies)
  0 siblings, 3 replies; 22+ messages in thread
From: Jason Rumney @ 2004-11-04 10:31 UTC (permalink / raw)
  Cc: B. Anyos, emacs-devel, chenggao

Richard Stallman wrote:

>For instance, there is something really strange here:
>
>    funcall_lambda(int -2128849612, int 1, int * 0x0082f980) line 2946 + 17 bytes
>    Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
>    call1(int 556794192, int -2127346688) line 2547 + 11 bytes
>    Fx_create_frame(int 0) line 4355
>
>There is no call to Fx_create_frame in line 4355; in fact, line 4355
>is far after the end of Fx_create_frame.  What's going on?
>
I think the user is on Windows, so that would be line 4355 of w32fns.c, 
which is in Fx_create_frame.

My line numbers are slightly out, but I suspect this line (4350 in my 
version):

  /* Set up faces after all frame parameters are known.  This call
     also merges in face attributes specified for new frames.  If we
     don't do this, the `menu' face for instance won't have the right
     colors, and the menu bar won't appear in the specified colors for
     new frames.  */
  call1 (Qface_set_after_frame_default, frame);


It appears to be outside the BLOCK_INPUT blocks within x_create_frame.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs crash
  2004-11-04 10:31           ` Jason Rumney
@ 2004-11-04 12:52             ` B. Anyos
  2004-11-04 13:08               ` Dhruva Krishnamurthy
  2004-11-04 15:48             ` B. Anyos
  2004-11-04 17:05             ` Jan D.
  2 siblings, 1 reply; 22+ messages in thread
From: B. Anyos @ 2004-11-04 12:52 UTC (permalink / raw)
  Cc: chenggao, rms, emacs-devel

It is true, I'm running emacs on Windows. So stacktrace is stopped right in
the middle of Fx_create_frame, though it seems it is over BLOCK_INPUT.
(file w32fns.c)

Anyway I tried to do what you asked for. Here's what I could figure out.

   debug_print(args[0]):
	face-set-after-frame-default

  (struct Lisp_String *)(0xfffffff & ((struct Lisp_Symbol *) (0xfffffff & args[0]))->xname):
	size		28
	size_byte	-1
	intervals	0x00000000
	data		0x01185dd0 "face-set-after-frame-default"

I hope this helps.

Unfortunately those nice commands listed in .gdbinit do not exist on MS Windows.
Any alternatives to help debugging on Windows ?


Jason Rumney said the following on 11/4/2004 11:31 AM:
> Richard Stallman wrote:
> 
>> For instance, there is something really strange here:
>>
>>    funcall_lambda(int -2128849612, int 1, int * 0x0082f980) line 2946 
>> + 17 bytes
>>    Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
>>    call1(int 556794192, int -2127346688) line 2547 + 11 bytes
>>    Fx_create_frame(int 0) line 4355
>>
>> There is no call to Fx_create_frame in line 4355; in fact, line 4355
>> is far after the end of Fx_create_frame.  What's going on?
>>
> I think the user is on Windows, so that would be line 4355 of w32fns.c, 
> which is in Fx_create_frame.
> 
> My line numbers are slightly out, but I suspect this line (4350 in my 
> version):
> 
>  /* Set up faces after all frame parameters are known.  This call
>     also merges in face attributes specified for new frames.  If we
>     don't do this, the `menu' face for instance won't have the right
>     colors, and the menu bar won't appear in the specified colors for
>     new frames.  */
>  call1 (Qface_set_after_frame_default, frame);
> 
> 
> It appears to be outside the BLOCK_INPUT blocks within x_create_frame.
> 
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
> 
> 

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs crash
  2004-11-04 12:52             ` B. Anyos
@ 2004-11-04 13:08               ` Dhruva Krishnamurthy
  2004-11-05  8:38                 ` Cheng Gao
  0 siblings, 1 reply; 22+ messages in thread
From: Dhruva Krishnamurthy @ 2004-11-04 13:08 UTC (permalink / raw)
  Cc: Emacs-Devel

Hello,
 Now, this problem has encroached emacs-unicode-2 branch too. With the
automatic sync, which IMO has happened today, we have the same problem
(which leaves me with no working emacs).

-dhruva

On Thu, 04 Nov 2004 13:52:04 +0100, B. Anyos <banyos@freemail.hu> wrote:
> It is true, I'm running emacs on Windows. So stacktrace is stopped right in
> the middle of Fx_create_frame, though it seems it is over BLOCK_INPUT.
> (file w32fns.c)
> 
> Anyway I tried to do what you asked for. Here's what I could figure out.
> 
>    debug_print(args[0]):
>         face-set-after-frame-default
> 
>   (struct Lisp_String *)(0xfffffff & ((struct Lisp_Symbol *) (0xfffffff & args[0]))->xname):
>         size            28
>         size_byte       -1
>         intervals       0x00000000
>         data            0x01185dd0 "face-set-after-frame-default"
> 
> I hope this helps.
> 
> Unfortunately those nice commands listed in .gdbinit do not exist on MS Windows.
> Any alternatives to help debugging on Windows ?
> 
> Jason Rumney said the following on 11/4/2004 11:31 AM:
> > Richard Stallman wrote:
> >
> >> For instance, there is something really strange here:
> >>
> >>    funcall_lambda(int -2128849612, int 1, int * 0x0082f980) line 2946
> >> + 17 bytes
> >>    Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
> >>    call1(int 556794192, int -2127346688) line 2547 + 11 bytes
> >>    Fx_create_frame(int 0) line 4355
> >>
> >> There is no call to Fx_create_frame in line 4355; in fact, line 4355
> >> is far after the end of Fx_create_frame.  What's going on?
> >>
> > I think the user is on Windows, so that would be line 4355 of w32fns.c,
> > which is in Fx_create_frame.
> >
> > My line numbers are slightly out, but I suspect this line (4350 in my
> > version):
> >
> >  /* Set up faces after all frame parameters are known.  This call
> >     also merges in face attributes specified for new frames.  If we
> >     don't do this, the `menu' face for instance won't have the right
> >     colors, and the menu bar won't appear in the specified colors for
> >     new frames.  */
> >  call1 (Qface_set_after_frame_default, frame);
> >
> >
> > It appears to be outside the BLOCK_INPUT blocks within x_create_frame.
> >
> >
> >
> > _______________________________________________
> > Emacs-devel mailing list
> > Emacs-devel@gnu.org
> > http://lists.gnu.org/mailman/listinfo/emacs-devel
> >
> >
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
> 


-- 
Proud FSF member: #1935
http://schemer.fateback.com/

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs crash
  2004-11-04 10:31           ` Jason Rumney
  2004-11-04 12:52             ` B. Anyos
@ 2004-11-04 15:48             ` B. Anyos
  2004-11-05  0:15               ` Richard Stallman
  2004-11-04 17:05             ` Jan D.
  2 siblings, 1 reply; 22+ messages in thread
From: B. Anyos @ 2004-11-04 15:48 UTC (permalink / raw)
  Cc: chenggao, rms, Jason Rumney

It is true, I'm running emacs on Windows. So stacktrace is stopped right in
the middle of Fx_create_frame, though it seems it is over BLOCK_INPUT.
(file w32fns.c)

Anyway I tried to do what you asked for. Here's what I could figure out.

   debug_print(args[0]):
	face-set-after-frame-default

  (struct Lisp_String *)(0xfffffff & ((struct Lisp_Symbol *) (0xfffffff & args[0]))->xname):
	size		28
	size_byte	-1
	intervals	0x00000000
	data		0x01185dd0 "face-set-after-frame-default"

I hope this helps.

Unfortunately those nice commands listed in .gdbinit do not exist on MS Windows.
Any alternatives to help debugging on Windows ?


Jason Rumney said the following on 11/4/2004 11:31 AM:
> Richard Stallman wrote:
> 
>> For instance, there is something really strange here:
>>
>>    funcall_lambda(int -2128849612, int 1, int * 0x0082f980) line 2946 
>> + 17 bytes
>>    Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
>>    call1(int 556794192, int -2127346688) line 2547 + 11 bytes
>>    Fx_create_frame(int 0) line 4355
>>
>> There is no call to Fx_create_frame in line 4355; in fact, line 4355
>> is far after the end of Fx_create_frame.  What's going on?
>>
> I think the user is on Windows, so that would be line 4355 of w32fns.c, 
> which is in Fx_create_frame.
> 
> My line numbers are slightly out, but I suspect this line (4350 in my 
> version):
> 
>  /* Set up faces after all frame parameters are known.  This call
>     also merges in face attributes specified for new frames.  If we
>     don't do this, the `menu' face for instance won't have the right
>     colors, and the menu bar won't appear in the specified colors for
>     new frames.  */
>  call1 (Qface_set_after_frame_default, frame);
> 
> 
> It appears to be outside the BLOCK_INPUT blocks within x_create_frame.
> 
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
> 
> 

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs crash
  2004-11-04 10:31           ` Jason Rumney
  2004-11-04 12:52             ` B. Anyos
  2004-11-04 15:48             ` B. Anyos
@ 2004-11-04 17:05             ` Jan D.
  2004-11-05  8:03               ` Stefan
  2 siblings, 1 reply; 22+ messages in thread
From: Jan D. @ 2004-11-04 17:05 UTC (permalink / raw)
  Cc: B. Anyos, chenggao, rms, Jason Rumney

Jason Rumney wrote:
> Richard Stallman wrote:
> 
>> For instance, there is something really strange here:
>>
>>    funcall_lambda(int -2128849612, int 1, int * 0x0082f980) line 2946 
>> + 17 bytes
>>    Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
>>    call1(int 556794192, int -2127346688) line 2547 + 11 bytes
>>    Fx_create_frame(int 0) line 4355
>>
>> There is no call to Fx_create_frame in line 4355; in fact, line 4355
>> is far after the end of Fx_create_frame.  What's going on?
>>
> I think the user is on Windows, so that would be line 4355 of w32fns.c, 
> which is in Fx_create_frame.
> 
> My line numbers are slightly out, but I suspect this line (4350 in my 
> version):
> 
>  /* Set up faces after all frame parameters are known.  This call
>     also merges in face attributes specified for new frames.  If we
>     don't do this, the `menu' face for instance won't have the right
>     colors, and the menu bar won't appear in the specified colors for
>     new frames.  */
>  call1 (Qface_set_after_frame_default, frame);
> 
> 
> It appears to be outside the BLOCK_INPUT blocks within x_create_frame.

It is outside the BLOCK_INPUT in x_create_frame, but inside another 
BLOCK_INPUT.

Installed cygwin, and tried to build.  Here is what I get:

#19 0x0114b433 in realize_x_face (cache=0x1b86140, attrs=0x82ec40, c=0,
     base_face=0x0) at xfaces.c:7141
#20 0x0114b2ce in realize_face (cache=0x1b86140, attrs=0x82ec40, c=0,
     base_face=0x0, former_face_id=0) at xfaces.c:7040
#21 0x0114ac0b in realize_default_face (f=0x16ce800) at xfaces.c:6967
#22 0x0114a942 in realize_basic_faces (f=0x16ce800) at xfaces.c:6834
#23 0x01149879 in Fdisplay_supports_face_attributes_p (attributes=23649197,
     display=23914500) at xfaces.c:6132
#24 0x0101c9c6 in Ffuncall (nargs=3, args=0x82ede0) at eval.c:2760
#25 0x0110491e in Fbyte_code (bytestr=18487971, vector=18488188, 
maxdepth=40)
     at bytecode.c:686
#26 0x0101cdac in funcall_lambda (fun=18487924, nargs=2, 
arg_vector=0x82ef24)
     at eval.c:2944



Number 23:  Fdisplay_supports_face_attributes_p calls 
realize_basic_faces, which does BLOCK_INPUT before calling 
realize_default_face.

xbacktrace:

"replace-regexp-in-string"
"tty-color-canonicalize"
"tty-color-desc"
"display-supports-face-attributes-p"
"face-spec-set-match-display"
"face-spec-choose"
"face-spec-set"
"byte-code"
"face-set-after-frame-default"
"x-create-frame"
"x-create-frame-with-faces"
"make-frame"
"frame-initialize"
"command-line"
"normal-top-level"

Why does W32 have to do "call1 (Qface_set_after_frame_default, frame);"? 
  The other platforms (Mac and X) does not.  NOTE: I am not at all 
familiar with W32, there might be a good reason.

	Jan D.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs crash
  2004-11-04 15:48             ` B. Anyos
@ 2004-11-05  0:15               ` Richard Stallman
  0 siblings, 0 replies; 22+ messages in thread
From: Richard Stallman @ 2004-11-05  0:15 UTC (permalink / raw)
  Cc: chenggao, jasonr, emacs-devel

      (struct Lisp_String *)(0xfffffff & ((struct Lisp_Symbol *) (0xfffffff & args[0]))->xname):
	    size		28
	    size_byte	-1
	    intervals	0x00000000
	    data		0x01185dd0 "face-set-after-frame-default"

    I hope this helps.


It does help.  This shows that BLOCK_INPUT wasn't done in
Fx_create_frame.  I wonder where it was done?

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs crash
  2004-11-04 17:05             ` Jan D.
@ 2004-11-05  8:03               ` Stefan
  0 siblings, 0 replies; 22+ messages in thread
From: Stefan @ 2004-11-05  8:03 UTC (permalink / raw)
  Cc: B. Anyos, chenggao, Jason Rumney, rms, emacs-devel

> Why does W32 have to do "call1 (Qface_set_after_frame_default, frame);"?
> The other platforms (Mac and X) does not.  NOTE: I am not at all familiar
> with W32, there might be a good reason.

IIRC X used to do it as well, so maybe someone just forgot to remove it
from w32?


        Stefan

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs crash
  2004-11-04 13:08               ` Dhruva Krishnamurthy
@ 2004-11-05  8:38                 ` Cheng Gao
  0 siblings, 0 replies; 22+ messages in thread
From: Cheng Gao @ 2004-11-05  8:38 UTC (permalink / raw)


As I remember, this bug should occur since Nov. 2. You can use

cvs update -D "2004-11-1"

to revert to Nov. 1 source. Thus you can build a workable Emacs and wait
for fix of this bug.

HTH,

-- 
这去者,不能见他的脸,背影模糊。

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2004-11-05  8:38 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-11-03  9:55 emacs crash B. Anyos
2004-11-03 10:28 ` Jason Rumney
2004-11-03 10:50   ` B. Anyos
2004-11-03 11:21     ` Jason Rumney
2004-11-03 11:29       ` Dhruva Krishnamurthy
2004-11-03 12:02       ` B. Anyos
2004-11-03 11:06   ` Dhruva Krishnamurthy
2004-11-03 14:09     ` CHENG Gao
2004-11-03 15:02       ` B. Anyos
2004-11-04  9:51         ` Richard Stallman
2004-11-04 10:31           ` Jason Rumney
2004-11-04 12:52             ` B. Anyos
2004-11-04 13:08               ` Dhruva Krishnamurthy
2004-11-05  8:38                 ` Cheng Gao
2004-11-04 15:48             ` B. Anyos
2004-11-05  0:15               ` Richard Stallman
2004-11-04 17:05             ` Jan D.
2004-11-05  8:03               ` Stefan
2004-11-04  9:51       ` Richard Stallman
  -- strict thread matches above, loose matches on Subject: below --
2003-10-08 12:42 Werner LEMBERG
2003-08-16 13:56 Werner LEMBERG
2003-08-18  4:52 ` Richard Stallman

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).