Re: 22.0.50 SEGFAULT

[JD Smith <jdsmith@as.arizona.edu>]

On Wed, 03 Aug 2005 09:19:18 -0700, JD Smith wrote:

> On Sun, 31 Jul 2005 01:01:53 +0200, Kim F. Storm wrote:
> 
>> JD Smith writes:
>> 
>> 
>>>>> GNU Emacs 22.0.50.3 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
>>>>> of 2005-07-14 on turtle.as.arizona.edu
>> 
>> Sorry, but I cannot see any reason why it fails from the data you sent me.
>> 
>> Something tells me that the gdb output isn't quite right, as the
>> references (buffer) object is the same for all of these:
>> 
>>   p row->glyphs[area][i-1]  (if i > 0)
>>   p row->glyphs[area][i]
>>   p row->glyphs[area][i+1]
>> 
>> .. so why would it fail on [i] but not on [i-1].
>> 
>> 
>> My only suggestion to get to the bottom of this is to build emacs without
>> optimizations like this:
>> 
>> /configure "CFLAGS=-g -O0"    (that's letter O followed by digit 0). make

OK, I've built an Emacs without optimization as you suggest, and
eventually got a SEGFAULT.  This one feels much different, more like a
memory leak, and not involving the breakpoint glyph. Emacs got
progressively slower over a couple of days until:

Program received signal SIGSEGV, Segmentation fault.
0x0816c4f2 in Fcons (car=144218891, cdr=137711637) at alloc.c:2696
2696          cons_free_list = *(struct Lisp_Cons **)&cons_free_list->cdr;
(gdb) bt
#0  0x0816c4f2 in Fcons (car=144218891, cdr=137711637) at alloc.c:2696
#1  0x0816c6ae in Flist (nargs=0, args=0xbfffc960) at alloc.c:2784
#2  0x081bdf8f in Fbyte_code (bytestr=140897115, vector=141296740,
    maxdepth=120) at bytecode.c:977
#3  0x08189b92 in funcall_lambda (fun=141605820, nargs=0,
    arg_vector=0xbfffcaf0) at eval.c:3049
#4  0x08189802 in apply_lambda (fun=141605820, args=137711633, eval_flag=1)
    at eval.c:2971
#5  0x08188883 in Feval (form=139656485) at eval.c:2246
#6  0x08185966 in Fprogn (args=158408061) at eval.c:432
#7  0x081884ef in Feval (form=158408053) at eval.c:2151
#8  0x08189415 in Ffuncall (nargs=2, args=0xbfffcdf0) at eval.c:2862
#9  0x081bd1dc in Fbyte_code (bytestr=141672107, vector=140879548, maxdepth=40)
    at bytecode.c:690
#10 0x08189b92 in funcall_lambda (fun=141707116, nargs=2,
    arg_vector=0xbfffcfe4) at eval.c:3049
#11 0x081895cd in Ffuncall (nargs=3, args=0xbfffcfe0) at eval.c:2908
#12 0x08188c5b in Fapply (nargs=2, args=0xbfffd090) at eval.c:2356
#13 0x08189005 in apply1 (fn=146693321, arg=152427421) at eval.c:2620
#14 0x081c6481 in read_process_output_call (fun_and_args=152427413)
    at process.c:4717
#15 0x08187434 in internal_condition_case_1 (
    bfun=0x81c6462 <read_process_output_call>, arg=152427413,
    handlers=137772625, hfun=0x81c6486 <read_process_output_error_handler>)
    at eval.c:1493
#16 0x081c69cb in read_process_output (proc=143722748, channel=6)
    at process.c:4940
#17 0x081c605d in wait_reading_process_output (time_limit=30, microsecs=0,
    read_kbd=-1, do_display=1, wait_for_cell=137711633, wait_proc=0x0,
    just_wait_proc=0) at process.c:4557
#18 0x0805b1ba in sit_for (sec=30, usec=0, reading=1, display=1,
    initial_display=0) at dispnew.c:6400
#19 0x08111d70 in read_char (commandflag=1, nmaps=2, maps=0xbfffe7c0,
    prev_event=137711633, used_mouse_menu=0xbfffe8bc) at keyboard.c:2768
#20 0x0811aae5 in read_key_sequence (keybuf=0xbfffea20, bufsize=30,
    prompt=137711633, dont_downcase_last=0, can_return_switch_frame=1,
    fix_current_buffer=1) at keyboard.c:8817
#21 0x0810f11c in command_loop_1 () at keyboard.c:1528
#22 0x08187314 in internal_condition_case (bfun=0x810ee14 <command_loop_1>,
    handlers=137772625, hfun=0x810e95c <cmd_error>) at eval.c:1452
#23 0x0810ec8d in command_loop_2 () at keyboard.c:1318
#24 0x08186d9e in internal_catch (tag=137766633,
    func=0x810ec6f <command_loop_2>, arg=137711633) at eval.c:1211
#25 0x0810ec41 in command_loop () at keyboard.c:1297
#26 0x0810e6db in recursive_edit_1 () at keyboard.c:990
#27 0x0810e81c in Frecursive_edit () at keyboard.c:1051
#28 0x0810d128 in main (argc=3, argv=0xbffff064) at emacs.c:1782

which doesn't seem to relate to the other type of SEGFAULT I was getting
(unless optimizations were clouding things).  If I can use this hung
session to provide any information for you, do let me know.  For now I'm
considering this a separate and perhaps unrelated issue, likely in GC.

JD