freed-memory use in very recent emacs

freed-memory use in very recent emacs

[Jim Meyering]

I was running emacs+gnus under gdb on debian unstable amd64
(built from emacs.git sources of ~2 days ago) and got a segfault.
I'll keep the gdb session around for a few days in case anyone
wants more info than this backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000543018 in mark_object (arg=<value optimized out>)
    at /mirror/d/emacs/src/alloc.c:5476
5476            MARK_INTERVAL_TREE (ptr->intervals);
(gdb) p ptr
$1 = (struct Lisp_String *) 0xb18a00
(gdb) p ptr->intervals
$2 = (INTERVAL) 0x3d3d3d3d3d3d3d3d
(gdb) bt
#0  0x0000000000543018 in mark_object (arg=<value optimized out>)
    at /mirror/d/emacs/src/alloc.c:5476
#1  0x0000000000543c82 in mark_maybe_pointer ()
    at /mirror/d/emacs/src/alloc.c:4245
#2  mark_memory () at /mirror/d/emacs/src/alloc.c:4297
#3  mark_stack () at /mirror/d/emacs/src/alloc.c:4530
#4  0x0000000000546d58 in Fgarbage_collect ()
    at /mirror/d/emacs/src/alloc.c:5112
#5  0x000000000055c90d in Ffuncall (nargs=2, args=0x7fffffffa0f0)
    at /mirror/d/emacs/src/eval.c:2949
#6  0x000000000055db5a in call1 (fn=<value optimized out>,
    arg1=<value optimized out>) at /mirror/d/emacs/src/eval.c:2796
#7  0x000000000044403b in decode_mode_spec (it=0x7fffffffa400,
    depth=<value optimized out>, field_width=<value optimized out>,
    precision=<value optimized out>, elt=<value optimized out>,
    props=<value optimized out>, risky=0) at /mirror/d/emacs/src/xdisp.c:18633
#8  display_mode_element (it=0x7fffffffa400, depth=<value optimized out>,
    field_width=<value optimized out>, precision=<value optimized out>,
    elt=<value optimized out>, props=<value optimized out>, risky=0)
    at /mirror/d/emacs/src/xdisp.c:17591
#9  0x00000000004446f5 in display_mode_element (it=0x7fffffffa400,
    depth=<value optimized out>, field_width=<value optimized out>,
    precision=-5, elt=<value optimized out>, props=<value optimized out>,
    risky=0) at /mirror/d/emacs/src/xdisp.c:17785
#10 0x00000000004446f5 in display_mode_element (it=0x7fffffffa400,
    depth=<value optimized out>, field_width=<value optimized out>,
    precision=0, elt=<value optimized out>, props=<value optimized out>,
    risky=0) at /mirror/d/emacs/src/xdisp.c:17785
#11 0x0000000000444d2c in display_mode_line (w=<value optimized out>,
    face_id=MODE_LINE_FACE_ID, format=<value optimized out>)
    at /mirror/d/emacs/src/xdisp.c:17297
#12 0x0000000000444ff7 in display_mode_lines (w=0x3bf8670)
    at /mirror/d/emacs/src/xdisp.c:17241
#13 0x000000000044b3b5 in redisplay_window (window=62883445,
    just_this_one_p=<value optimized out>) at /mirror/d/emacs/src/xdisp.c:13868
#14 0x000000000044d707 in redisplay_window_1 (window=4412750543122677053)
    at /mirror/d/emacs/src/xdisp.c:12287
#15 0x000000000055bbf7 in internal_condition_case_1 (
    bfun=<value optimized out>, arg=<value optimized out>,
    handlers=<value optimized out>, hfun=<value optimized out>)
    at /mirror/d/emacs/src/eval.c:1538
#16 0x000000000044f542 in redisplay_internal (
    preserve_echo_area=<value optimized out>)
    at /mirror/d/emacs/src/xdisp.c:11905
#17 0x000000000044fe58 in redisplay_preserve_echo_area (
    from_where=<value optimized out>) at /mirror/d/emacs/src/xdisp.c:12077
#18 0x00000000004ec030 in detect_input_pending_run_timers (do_display=1)
    at /mirror/d/emacs/src/keyboard.c:10678
#19 0x000000000059f481 in wait_reading_process_output (
    time_limit=<value optimized out>, microsecs=<value optimized out>,
    read_kbd=<value optimized out>, do_display=<value optimized out>,
    wait_for_cell=<value optimized out>, wait_proc=<value optimized out>,
    just_wait_proc=0) at /mirror/d/emacs/src/process.c:5022
#20 0x0000000000415784 in sit_for (timeout=120, reading=1, do_display=1)
    at /mirror/d/emacs/src/dispnew.c:6654
#21 0x00000000004ee269 in read_char (commandflag=<value optimized out>,
    nmaps=<value optimized out>, maps=<value optimized out>,
    prev_event=<value optimized out>, used_mouse_menu=<value optimized out>,
    end_time=<value optimized out>) at /mirror/d/emacs/src/keyboard.c:2953
#22 0x00000000004ef2f5 in read_key_sequence (keybuf=0x7fffffffdf10,
    bufsize=<value optimized out>, prompt=11635410,
    dont_downcase_last=<value optimized out>,
    can_return_switch_frame=<value optimized out>,
    fix_current_buffer=<value optimized out>)
    at /mirror/d/emacs/src/keyboard.c:9485
#23 0x00000000004f1790 in command_loop_1 ()
    at /mirror/d/emacs/src/keyboard.c:1643
#24 0x000000000055bd5f in internal_condition_case (bfun=<value optimized out>,
    handlers=<value optimized out>, hfun=<value optimized out>)
    at /mirror/d/emacs/src/eval.c:1490
#25 0x00000000004ea22e in command_loop_2 ()
    at /mirror/d/emacs/src/keyboard.c:1360
#26 0x000000000055be8a in internal_catch (tag=<value optimized out>,
    func=<value optimized out>, arg=<value optimized out>)
    at /mirror/d/emacs/src/eval.c:1226
#27 0x00000000004eac31 in command_loop ()
    at /mirror/d/emacs/src/keyboard.c:1339
#28 0x00000000004eb00a in recursive_edit_1 ()
    at /mirror/d/emacs/src/keyboard.c:954
#29 0x00000000004eb147 in Frecursive_edit ()
    at /mirror/d/emacs/src/keyboard.c:1016
#30 0x00000000004de85c in main (argc=0, argv=0x7fffffffe748)
    at /mirror/d/emacs/src/emacs.c:1833
(gdb)

Re: freed-memory use in very recent emacs

[Chong Yidong]

Jim Meyering <jim@meyering.net> writes:

> I was running emacs+gnus under gdb on debian unstable amd64
> (built from emacs.git sources of ~2 days ago) and got a segfault.
> I'll keep the gdb session around for a few days in case anyone
> wants more info than this backtrace

Hmm, I think decode_mode_spec probably needs to inhibit garbage
collection while it is calling file-remote-p.  I've checked in a fix.

Re: freed-memory use in very recent emacs

[Jim Meyering]

Chong Yidong wrote:

> Jim Meyering <jim@meyering.net> writes:
>
>> I was running emacs+gnus under gdb on debian unstable amd64
>> (built from emacs.git sources of ~2 days ago) and got a segfault.
>> I'll keep the gdb session around for a few days in case anyone
>> wants more info than this backtrace
>
> Hmm, I think decode_mode_spec probably needs to inhibit garbage
> collection while it is calling file-remote-p.  I've checked in a fix.

Thanks for the quick work.
I'll give it a try, though I don't know precisely what
I was doing at the time.