emacs crash

emacs crash

[Werner LEMBERG]

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

Re: emacs crash

[Richard Stallman]

    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.

emacs crash

[Werner LEMBERG]

[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

emacs crash

[B. Anyos]

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

Re: emacs crash

[Jason Rumney]

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.

Re: emacs crash

[B. Anyos]

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()

Re: emacs crash

[Dhruva Krishnamurthy]

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/

Re: emacs crash

[Jason Rumney]

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.

Re: emacs crash

[Dhruva Krishnamurthy]

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/

Re: emacs crash

[B. Anyos]

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)

Re: emacs crash

[CHENG Gao]

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,


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

Re: emacs crash

[B. Anyos]

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,
> 
> 

Re: emacs crash

[Richard Stallman]

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.

Re: emacs crash

[Richard Stallman]

    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.

Re: emacs crash

[Jason Rumney]

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.

Re: emacs crash

[B. Anyos]

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

Re: emacs crash

[Dhruva Krishnamurthy]

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/

Re: emacs crash

[B. Anyos]

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

Re: emacs crash

[Jan D.]

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.

Re: emacs crash

[Richard Stallman]

      (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?

Re: emacs crash

[Stefan]

> 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

Re: emacs crash

[Cheng Gao]

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,

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

emacs crash

[joseph]

To: bug-gnu-emacs@gnu.org
Subject: emacs crash
Reply-to: joseph@vlsidesigntools.com
FCC: ~/rmail
--text follows this line--
This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.3.1 (i386-dell-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2003-09-02 on jtpc840
configured using `configure  i386-dell-linux-gnu --prefix=/home/joseph/gnu/emacs-21.3
--exec-prefix=/home/joseph/gnu/emacs-21.3/linux24 --with-x-toolkit=athena'
Important settings:
  value of $LC_ALL: C
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

22 Apr 2005

create a file with the following octal dump (i.e., od -c file) in emacs 21.3.1:


0000000   h   e   l   l   o 033   4 033   S 001   h   e   l   l   o  \n
0000020

These contents are "hello(esc)4(esc)S(ctrl-A)hello\n".  I type them here
in representational form rather than the exact form to avoid the potential 
problem of your emacs version crashing on reading this bug message and being
unable to decipher it.

When I read this very simple file with emacs version 21.3.1, the message
Fatal error (6).Aborted
appears and the emacs process aborts.  It will not read this file.  Interestingly,
emacs 21.3.1 will create this file and write it out.  Upon deleting the corresponding
buffer and re-reading the file, it crashes.  This happens every time.

Version 20.4.1 of emacs does not exhibit this problem.  It creates the test file,
writes it out, and re-reads it with no difficulty after deleting the corresponding
buffer.  Some problem has been introduced in the newer version leading to this
crash phenomenon.




Recent input:
C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n 
C-S-n C-S-n <return> <next> <next> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <up> <up> 
<return> C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n 
C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n 
C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n C-S-n <return> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <menu-bar> <help-menu> <emacs-version> 
<next> <next> <next> <next> <next> <next> <prior> <prior> 
<prior> <prior> <prior> <prior> <prior> <escape> x 
r e p o SPC r SPC SPC SPC <return>

Recent messages:
Loading apropos...done
Loading view...done
Loading info...done
Composing main Info directory...
Mark set
Composing main Info directory...done
GNU Emacs 21.3.1 (i386-dell-linux-gnu, X toolkit, Xaw3d scroll bars) of 2003-09-02 on jtpc840
call-interactively: End of buffer
Making completion list...
Loading emacsbug...done
Joseph Patterson
VLSI Design Tools
P.O. Box 378
W. Boxford, MA 01885-0378
(978)352-7976
joseph@vlsidesigntools.com

Re: emacs crash

[Richard Stallman]

This did not fail for me in the latest development Emacs from
CVS on savannah.gnu.org.

Thanks for reporting it.

emacs crash

[Philip B Giangarra]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.1.1 (sparc-sun-solaris2.8, X toolkit, Xaw3d scroll bars)
 of 2002-05-28 on tx30sws004
configured using `configure  --prefix=/_TOOLS_/dist/gnu-emacs-21.1/sparc-sun-solaris2.8 --with-tiff'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: en_US.ISO8859-1
  value of $LC_CTYPE: en_US.ISO8859-1
  value of $LC_MESSAGES: C
  value of $LC_MONETARY: en_US.ISO8859-1
  value of $LC_NUMERIC: en_US.ISO8859-1
  value of $LC_TIME: en_US.ISO8859-1
  value of $LANG: en_US.ISO8859-1
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

I closed a frame and buffer, and the entire emacs sessions crashed with the following error message:

X protocol error: BadDrawable (invalid Pixmap or Window parameter) on protocol request 69
 
This happens many times per week (I use emacs extensively every day).

Thank you,

Philip Giangarra
Freescale
781-932-6021
508-294-7066

Philip.Giangarra@freescale.com



Recent input:
<help-echo> <switch-frame> <prior> <switch-frame> <help-echo> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<S-down-mouse-3> <S-mouse-3> <pause> C-c C-a <pause> 
<switch-frame> <switch-frame> <switch-frame> <S-down-mouse-3> 
<S-mouse-3> <pause> C-c C-a <switch-frame> <switch-frame> 
<switch-frame> <S-down-mouse-3> <S-mouse-3> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <help-echo> <help-echo> <help-echo> 
<menu-bar> <help-menu> <emacs-problems> <help-echo> 
<help-echo> <help-echo> <switch-frame> <switch-frame> 
<help-echo> C-s p i x m a p <home> C-s c r a s h <help-echo> 
<help-echo> C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s 
C-s C-s C-s <switch-frame> <switch-frame> C-s C-s C-s 
C-s C-s C-s C-s C-s C-s C-s <help-echo> <help-echo> 
<help-echo> <menu-bar> <buffer> "lpg013*shell*<2>" 
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> 
<help-menu> <report-emacs-bug>

Recent messages:
Fontifying spu_ch.v... (regexps............)
Updating AUTOs...done (no changes)
/proj/.ppc_draco8_design_01/design_01/d8roc/u/philg/design/SPU/blocks/spu_ch/rtl_v/spu_ch_get_fsm.v and /proj/.ppc_draco8_design_01/design_01/d8roc/u/philg/design/SPU/blocks/state_machines/channel_state_machines/hdl/spu_ch_get_fsm.v are the same file
Loading view...done
Note: file is write protected
Type C-h for help, h for commands, q to quit.
Mark saved where search started
Mark set
Mark saved where search started [2 times]
Loading emacsbug...done

emacs crash

[Donald Zoch]

We think we've experienced a bug in emacs
It dies with a segmentation fault. 

GNU Emacs 21.4.1
Copyright (C) 2002 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

Backtrace:

#0  0x40294fd1 in kill () from /lib/tls/libc.so.6
#1  0x080decb2 in fatal_error_signal (sig=26106) at emacs.c:354
#2  <signal handler called>
#3  0x0804fd50 in increment_row_positions (row=0x85fdd10, delta=1, delta_bytes=4) at dispnew.c:1188
#4  0x0804fdef in increment_matrix_positions (matrix=0x84df150, start=65, end=65, delta=1, 
    delta_bytes=1) at dispnew.c:927
#5  0x0806c3eb in try_window_id (w=0x8498798) at xdisp.c:11883
#6  0x080711a0 in redisplay_window (window=1212778392, just_this_one_p=1) at xdisp.c:10260
#7  0x080736b1 in redisplay_internal (preserve_echo_area=4) at xdisp.c:8910
#8  0x080e8ceb in read_char (commandflag=1, nmaps=2, maps=0xffffaa10, prev_event=405378092, 
    used_mouse_menu=0xffffaa68) at keyboard.c:2299
#9  0x080ea551 in read_key_sequence (keybuf=0xffffaba0, bufsize=30, prompt=405378092, 
    dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:8209
#10 0x080ec3eb in command_loop_1 () at keyboard.c:1451
#11 0x0813d39a in internal_condition_case (bfun=0x80ec1e0 <command_loop_1>, handlers=405474436, 
    hfun=0x80e5440 <cmd_error>) at eval.c:1267
#12 0x080e0d5e in command_loop_2 () at keyboard.c:1245
#13 0x0813d2a9 in internal_catch (tag=4, func=0x80e0d30 <command_loop_2>, arg=405378092)
    at eval.c:1030
#14 0x080e0b2e in command_loop () at keyboard.c:1224
#15 0x080e0bd9 in recursive_edit_1 () at keyboard.c:950
#16 0x080e0d0e in Frecursive_edit () at keyboard.c:1006
#17 0x080dff09 in main (argc=2, argv=0xffffb254, envp=0xffffb260) at emacs.c:1547


Detail from our user on what he was doing when it crashed:

Here's the detail that I have:
Similar to the last failure I had 2 files open in buffers (size:401204B
& 995B)
with the emacs panel split in 2 vertically and a separate buffer in each.
The 401204B file was in the left pane, 995B file in the right pane.
I had just copy/pasted the 995B into the 2nd file which hadn't yet been
saved.
I left clicked the mouse to place the cursor in the left window
and the session disappeared.

I think that this time was slightly different than the last time it failed.
Last time I wasn't doing copy/paste, but was typing text,
I left clicked and then when I typed the 1st character the session
disappeared.
I think that I didn't hit a character this time.


Thanks for any help you can provide.

Donald
--
Donald Zoch                    
donald.zoch@amd.com             

emacs crash

[Rusi]

emacs crashes with this (below)

Does not happen with -Q
Happens with -q
Can file bug report but not clear whether its debian or emacs.

Happens as follows:
Start emacs -q
Goto options set default font and pull slider to a large value
Click once -- beep.
Click again -- crash!
=================================
Fatal error 11: Segmentation fault
Backtrace:
emacs[0x8138719]
emacs[0x8120446]
emacs[0x813758e]
emacs[0x81375fb]
linux-gate.so.1(__kernel_sigreturn+0x0)[0xb7723d18]
/lib/i386-linux-gnu/libglib-2.0.so.0(g_main_loop_quit+0x18)[0xb6809548]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_cclosure_marshal_VOID__INTv+0x50)[0xb68fa920]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(+0xda5f)[0xb68f8a5f]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x889)[0xb69127f9]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x25)[0xb69130d5]
/usr/lib/i386-linux-gnu/libgtk-3.so.0(gtk_dialog_response+0x72)[0xb6f22042]
/usr/lib/i386-linux-gnu/libgtk-3.so.0(+0x1583e7)[0xb6f223e7]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID+0x6c)[0xb68fa46c]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x14b)[0xb68f883b]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(+0x1f855)[0xb690a855]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xf6a)[0xb6912eda]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x25)[0xb69130d5]
/usr/lib/i386-linux-gnu/libgtk-3.so.0(gtk_button_clicked+0x71)[0xb6ebb6f1]
/usr/lib/i386-linux-gnu/libgtk-3.so.0(+0xf18cd)[0xb6ebb8cd]
/usr/lib/i386-linux-gnu/libgtk-3.so.0(+0xf1926)[0xb6ebb926]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOIDv+0x27)[0xb68fa4c7]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(+0xc2e2)[0xb68f72e2]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(+0xda5f)[0xb68f8a5f]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x889)[0xb69127f9]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x25)[0xb69130d5]
/usr/lib/i386-linux-gnu/libgtk-3.so.0(+0xef71b)[0xb6eb971b]
/usr/lib/i386-linux-gnu/libffi.so.6(ffi_call_SYSV+0x1a)[0xb5744a82]
/usr/lib/i386-linux-gnu/libffi.so.6(ffi_call+0x76)[0xb5744556]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_cclosure_marshal_generic_va+0x21d)[0xb68f93bd]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(+0xda5f)[0xb68f8a5f]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x889)[0xb69127f9]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x25)[0xb69130d5]
/usr/lib/i386-linux-gnu/libgtk-3.so.0(+0x19d354)[0xb6f67354]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_cclosure_marshal_VOID__BOXEDv+0x4e)[0xb68fb47e]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(+0xc2e2)[0xb68f72e2]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(+0xda5f)[0xb68f8a5f]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x889)[0xb69127f9]
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x25)[0xb69130d5]
/usr/lib/i386-linux-gnu/libgtk-3.so.0(+0x19a94d)[0xb6f6494d]
/usr/lib/i386-linux-gnu/libgtk-3.so.0(+0x19be51)[0xb6f65e51]
/usr/lib/i386-linux-gnu/libgtk-3.so.0(+0x19e9e4)[0xb6f689e4]
...
Segmentation fault

Re: emacs crash

[Rusi]

On Friday, February 13, 2015 at 9:26:37 PM UTC+5:30, Rusi wrote:
> emacs crashes with this (below)

Should have said:
emacs 24.4.1
on debian testing
xfce4 

Re: emacs crash

[Alexis]

 
On 2015-02-14T02:56:34+1100, Rusi said: 
 
 R> emacs crashes with this (below) 
 
 R> Does not happen with -Q Happens with -q Can file bug report 
 but R> not clear whether its debian or emacs. 
 
 R> Happens as follows: Start emacs -q Goto options set default 
 font R> and pull slider to a large value Click once -- beep. 
 Click again R> -- crash!  ================================= Fatal 
 error 11: R> Segmentation fault

i'm on Debian Wheezy x86_64 (+updates), running a manually 
compiled Emacs 24.4.1, and have not so far managed to reproduce 
this. However, i'm not sure what you mean by "Click once" and 
"Click again" - where are you clicking in each instance?


Alexis.

Re: emacs crash

[Rusi]

On Saturday, February 14, 2015 at 12:15:02 PM UTC+5:30, Alexis wrote:
> On 2015-02-14T02:56:34+1100, Rusi said: 
>  
>  R> emacs crashes with this (below) 
>  
>  R> Does not happen with -Q Happens with -q Can file bug report 
>  but R> not clear whether its debian or emacs. 
>  
>  R> Happens as follows: Start emacs -q Goto options set default 
>  font R> and pull slider to a large value Click once -- beep. 
>  Click again R> -- crash!  ================================= Fatal 
>  error 11: R> Segmentation fault
> 
> i'm on Debian Wheezy x86_64 (+updates), running a manually 
> compiled Emacs 24.4.1, and have not so far managed to reproduce 
> this. However, i'm not sure what you mean by "Click once" and 
> "Click again" - where are you clicking in each instance?
> 
> 
> Alexis.

Menu → Options → Set Default Font → (Slide the font value up and then) SELECT (button)

Re: emacs crash

[Alexis]

On 2015-02-14T21:23:49+1100, Rusi said:

 R> Menu → Options → Set Default Font → (Slide the font value up 
 and R> then) SELECT (button)

That's what i guessed, and that's what i did - i don't get a 
segfault. However, i'm on Debian stable, not testing, so it might 
be an issue with one of the libraries used by testing to build 
Emacs; you might like to report it as a Debian bug:

https://www.debian.org/Bugs/Reporting

Existing bug reports for Emacs on testing can be found here:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=emacs;dist=testing


Alexis.

Re: emacs crash

[Robert Thorpe]

Rusi <rustompmody@gmail.com> writes:

> emacs crashes with this (below)
>
> Does not happen with -Q
> Happens with -q
> Can file bug report but not clear whether its debian or emacs.

-Q disables loading of .emacs/init.el and site-start.el.  -q disables
loading of .emacs/init.el but not site-start.el.  So, the problem is
probably in site-start.el which is a debian file.

> Happens as follows:
> Start emacs -q
> Goto options set default font and pull slider to a large value
> Click once -- beep.
> Click again -- crash!

I see no problem on Xubuntu.  You clarified that "click once" means
click on "Select".  What does "Click again" mean?  When I click on
select the pop-up window disappears and I see the Emacs frame with huge
text.  I can click on things in the frame with no problem.

BR,
Robert Thorpe

Emacs crash

[Rusi]

Can someone check this recipe for crashing emacs please?

Ubuntu 16.4 running vanilla Unity -- yes this is likely related to X/WM stuff
emacs 24.5.1

1 Start emacs with
$ emacs --daemon

init contains just this 2 line function:

(defun kill-later ()
  (run-with-timer 1 nil 'save-buffers-kill-emacs))


2. 
$ emacsclient -n -c somefile
[somefile exists]

3. Write something there (ie dirty it and get a '*' in modeline)

4. Remove the frame by clicking the X in the frame

5. Try to kill emacs with
$ emacsclient -c  -e '(kill-later)'

6. top shows emacs running at 100% usage

7. killing it in top causes an apport crash

Note 1 Why is kill-later defined in that round-about way?
Because directly invoking save-buffers-kill-emacs from emacsclient
makes the -n option ignored
This in turn causes the save-buffers-kill-emacs to say "You have clients"

Note 2 If an emacs frame is present the save-buffer dialog appears as expected
and there is no issue