bug#19852: 25.0.50; show-paren-mode in sh-mode freezes Emacs

bug#19852: 25.0.50; show-paren-mode in sh-mode freezes Emacs

[Jorgen Schaefer]

Emacs 25.0.50, no GUI, git ref cf498e5b9a, run with -Q, will freeze hard
and dump core when using show-paren-mode in certain situations with
files not ending with a newline.

Reproduction:

Create a file with these contents:

----
#!/bin/bash

if true
then
----

Do *not* include a final newline after the "then" line, possibly using
(setq require-final-newline nil).

Move point to the beginning of the file, enable `show-paren-mode', and
go down line by line. Once you hit next-line on the "i" of "if", Emacs
freezes. C-g will make it ask to auto-save and dump core.

Backtrace at that point from gdb:

Program received signal SIGINT, Interrupt.
find_interval (tree=0x131d8a0, position=21) at intervals.c:670
670           if (BUFFERP (parent))
(gdb) bt
#0  find_interval (tree=0x131d8a0, position=21) at intervals.c:670
#1  0x0000000000546a34 in validate_interval_range (object=<optimized out>,
    begin=begin@entry=0x7fffffffb1e8, end=end@entry=0x7fffffffb1e8,
    force=force@entry=false) at textprop.c:194
#2  0x000000000054867b in Ftext_properties_at (position=position@entry=86,
    object=<optimized out>) at textprop.c:583
#3  0x00000000005486fc in Fget_text_property (position=position@entry=86,
    prop=prop@entry=17232, object=<optimized out>) at textprop.c:603
#4  0x00000000005488e7 in get_char_property_and_overlay (
    position=position@entry=86, prop=prop@entry=17232, object=<optimized out>,
    object@entry=0, overlay=overlay@entry=0x0) at textprop.c:673
#5  0x0000000000548c37 in Fget_char_property (position=position@entry=86,
    prop=prop@entry=17232, object=object@entry=0) at textprop.c:687
#6  0x00000000004f5334 in Fconstrain_to_field (new_pos=58, old_pos=86,
    escape_from_edge=0, only_in_line=only_in_line@entry=39696,
    inhibit_capture_property=inhibit_capture_property@entry=0) at editfns.c:714
#7  0x00000000004f5547 in Fline_beginning_position (n=<optimized out>)
    at editfns.c:802
#8  0x00000000004fdd55 in Ffuncall (nargs=1, args=<optimized out>)
    at eval.c:2718
#9  0x000000000053018d in exec_byte_code (bytestr=20043936, vector=21,
    maxdepth=15546869, args_template=0, nargs=75, args=0x1) at bytecode.c:919
#10 0x00000000004fd8e8 in funcall_lambda (fun=14270420, nargs=nargs@entry=0,
    arg_vector=0x7fffffffb550, arg_vector@entry=0x7fffffffb6a8) at eval.c:2885
#11 0x00000000004fdb73 in Ffuncall (nargs=1, args=0x7fffffffb6a0)
    at eval.c:2779
#12 0x000000000053018d in exec_byte_code (bytestr=20043936, vector=21,
    maxdepth=15546869, args_template=1, nargs=9, args=0x1) at bytecode.c:919
#13 0x00000000004fd8e8 in funcall_lambda (fun=14213108, nargs=nargs@entry=0,
    arg_vector=0x7fffffffb6a0, arg_vector@entry=0x7fffffffb808) at eval.c:2885
#14 0x00000000004fdb73 in Ffuncall (nargs=1, args=0x7fffffffb800)
    at eval.c:2779
#15 0x000000000053018d in exec_byte_code (bytestr=20043936, vector=21,
    maxdepth=15546869, args_template=0, nargs=61, args=0x1) at bytecode.c:919
#16 0x00000000004fd8e8 in funcall_lambda (fun=14270420, nargs=nargs@entry=0,
    arg_vector=0x7fffffffb800, arg_vector@entry=0x7fffffffb960) at eval.c:2885
#17 0x00000000004fdb73 in Ffuncall (nargs=1, args=0x7fffffffb958)
    at eval.c:2779
#18 0x000000000053018d in exec_byte_code (bytestr=20043936, vector=21,
    maxdepth=15546869, args_template=0, nargs=0, args=0x1) at bytecode.c:919
#19 0x00000000004fd8e8 in funcall_lambda (fun=14212852, nargs=nargs@entry=0, ---
    arg_vector=0x7fffffffb958, arg_vector@entry=0x7fffffffbac8) at eval.c:2885
#20 0x00000000004fdb73 in Ffuncall (nargs=1, args=0x7fffffffbac0)
    at eval.c:2779
#21 0x000000000053018d in exec_byte_code (bytestr=20043936, vector=21,
    maxdepth=15546869, args_template=1, nargs=17, args=0x1) at bytecode.c:919
#22 0x00000000004fd8e8 in funcall_lambda (fun=14268180, nargs=nargs@entry=1,
    arg_vector=0x7fffffffbac0, arg_vector@entry=0x7fffffffbc20) at eval.c:2885
#23 0x00000000004fdb73 in Ffuncall (nargs=2, args=0x7fffffffbc18)
---Type <return> to continue, or q <return> to quit---
    at eval.c:2779
#24 0x000000000053018d in exec_byte_code (bytestr=20043936, vector=21,
    maxdepth=15546869, args_template=0, nargs=146, args=0x2) at bytecode.c:919
#25 0x00000000004fd8e8 in funcall_lambda (fun=14270420, nargs=nargs@entry=0,
    arg_vector=0x7fffffffbc18, arg_vector@entry=0x7fffffffbd78) at eval.c:2885
#26 0x00000000004fdb73 in Ffuncall (nargs=1, args=0x7fffffffbd70)
    at eval.c:2779
#27 0x000000000053018d in exec_byte_code (bytestr=20043936, vector=21,
    maxdepth=15546869, args_template=1, nargs=9, args=0x1) at bytecode.c:919
#28 0x00000000004fd8e8 in funcall_lambda (fun=14213108, nargs=nargs@entry=0,
    arg_vector=0x7fffffffbd70, arg_vector@entry=0x7fffffffbed0) at eval.c:2885
#29 0x00000000004fdb73 in Ffuncall (nargs=1, args=0x7fffffffbec8)
    at eval.c:2779
#30 0x000000000053018d in exec_byte_code (bytestr=20043936, vector=21,
    maxdepth=15546869, args_template=0, nargs=37, args=0x1) at bytecode.c:919
#31 0x00000000004fd8e8 in funcall_lambda (fun=14269220, nargs=nargs@entry=0,
    arg_vector=0x7fffffffbec8, arg_vector@entry=0x7fffffffc068) at eval.c:2885
#32 0x00000000004fdb73 in Ffuncall (nargs=1, args=0x7fffffffc060)
    at eval.c:2779
#33 0x000000000053018d in exec_byte_code (bytestr=20043936, vector=21,
    maxdepth=15546869, args_template=140737488339064, nargs=81, args=0x1)
    at bytecode.c:919
#34 0x00000000004fd8e8 in funcall_lambda (fun=20004260, nargs=nargs@entry=5,
    arg_vector=0x7fffffffc060, arg_vector@entry=0x7fffffffc218) at eval.c:2885
#35 0x00000000004fdb73 in Ffuncall (nargs=6, args=0x7fffffffc210)
    at eval.c:2779
#36 0x000000000053018d in exec_byte_code (bytestr=20043936, vector=21,
    maxdepth=15546869, args_template=1, nargs=1, args=0x6) at bytecode.c:919
#37 0x00000000004fd8e8 in funcall_lambda (fun=20006292, nargs=nargs@entry=1,
    arg_vector=0x7fffffffc210, arg_vector@entry=0x7fffffffc398) at eval.c:2885
#38 0x00000000004fdb73 in Ffuncall (nargs=2, args=0x7fffffffc390)
    at eval.c:2779
#39 0x000000000053018d in exec_byte_code (bytestr=20043936, vector=21,
    maxdepth=15546869, args_template=1, nargs=108, args=0x2) at bytecode.c:919
#40 0x00000000004fd8e8 in funcall_lambda (fun=20010868, nargs=nargs@entry=1,
    arg_vector=0x7fffffffc390, arg_vector@entry=0x7fffffffc630) at eval.c:2885
#41 0x00000000004fdb73 in Ffuncall (nargs=nargs@entry=2,
    args=args@entry=0x7fffffffc628) at eval.c:2779
#42 0x00000000004fec3b in Fapply (nargs=3, args=0x7fffffffc628) at eval.c:2289
#43 0x00000000004fdc5a in Ffuncall (nargs=4, args=0x7fffffffc620)
    at eval.c:2698
#44 0x000000000053018d in exec_byte_code (bytestr=20043936, vector=21,
    maxdepth=15546869, args_template=0, nargs=0, args=0x4) at bytecode.c:919
#45 0x00000000004fd8e8 in funcall_lambda (fun=16412004, nargs=nargs@entry=0,
    arg_vector=0x7fffffffc620, arg_vector@entry=0x7fffffffc780) at eval.c:2885
#46 0x00000000004fdb73 in Ffuncall (nargs=1, args=0x7fffffffc778)
    at eval.c:2779
#47 0x000000000053018d in exec_byte_code (bytestr=20043936, vector=21,
    maxdepth=15546869, args_template=0, nargs=6, args=0x1) at bytecode.c:919
---Type <return> to continue, or q <return> to quit---
#48 0x00000000004fd7d3 in funcall_lambda (fun=17070101, nargs=nargs@entry=0,
    arg_vector=arg_vector@entry=0x7fffffffca58) at eval.c:2951
#49 0x00000000004fdb73 in Ffuncall (nargs=nargs@entry=1,
    args=args@entry=0x7fffffffca50) at eval.c:2779
#50 0x00000000004fec3b in Fapply (nargs=2, args=0x7fffffffca50) at eval.c:2289
#51 0x00000000004fdc5a in Ffuncall (nargs=3, args=0x7fffffffca48)
    at eval.c:2698
#52 0x000000000053018d in exec_byte_code (bytestr=20043936, vector=21,
    maxdepth=15546869, args_template=1, nargs=140737488341592, args=0x3)
    at bytecode.c:919
#53 0x00000000004fd7d3 in funcall_lambda (fun=9342949, nargs=nargs@entry=1,
    arg_vector=arg_vector@entry=0x7fffffffcc18) at eval.c:2951
#54 0x00000000004fdb73 in Ffuncall (nargs=nargs@entry=2,
    args=args@entry=0x7fffffffcc10) at eval.c:2779
#55 0x00000000004fdf2a in call1 (fn=fn@entry=40320, arg1=arg1@entry=17077685)
    at eval.c:2573
#56 0x000000000049220a in timer_check_2 (idle_timers=<optimized out>,
    timers=<optimized out>) at keyboard.c:4522
#57 timer_check () at keyboard.c:4589
#58 0x00000000004925a9 in readable_events (flags=<optimized out>)
    at keyboard.c:3422
#59 0x0000000000493888 in get_input_pending (flags=1) at keyboard.c:6804
#60 0x0000000000495ccc in detect_input_pending_run_timers (
    do_display=do_display@entry=true) at keyboard.c:9949
#61 0x0000000000537c76 in wait_reading_process_output (
    time_limit=time_limit@entry=30, nsecs=nsecs@entry=0,
    read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true,
    wait_for_cell=wait_for_cell@entry=0, wait_proc=wait_proc@entry=0x0,
    just_wait_proc=just_wait_proc@entry=0) at process.c:4689
#62 0x000000000040ff7c in sit_for (timeout=timeout@entry=122,
    reading=reading@entry=true, display_option=display_option@entry=1)
    at dispnew.c:5742
#63 0x0000000000498507 in read_char (commandflag=commandflag@entry=1,
    map=map@entry=14515971, prev_event=0,
    used_mouse_menu=used_mouse_menu@entry=0x7fffffffd90b,
    end_time=end_time@entry=0x0) at keyboard.c:2780
#64 0x0000000000498fd1 in read_key_sequence (
    keybuf=keybuf@entry=0x7fffffffd9e0, prompt=prompt@entry=0,
    dont_downcase_last=dont_downcase_last@entry=false,
    can_return_switch_frame=can_return_switch_frame@entry=true,
    fix_current_buffer=fix_current_buffer@entry=true,
    prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
    at keyboard.c:9144
#65 0x000000000049a3e2 in command_loop_1 () at keyboard.c:1407
#66 0x00000000004fc1d2 in internal_condition_case (
    bfun=bfun@entry=0x49a1b0 <command_loop_1>, handlers=handlers@entry=15792,
    hfun=hfun@entry=0x490d80 <cmd_error>) at eval.c:1348
#67 0x000000000048f33c in command_loop_2 (ignore=ignore@entry=0)
    at keyboard.c:1139
---Type <return> to continue, or q <return> to quit---
#68 0x00000000004fc0db in internal_catch (tag=tag@entry=40800,
    func=func@entry=0x48f320 <command_loop_2>, arg=arg@entry=0) at eval.c:1108
#69 0x000000000048f2f7 in command_loop () at keyboard.c:1118
#70 0x0000000000490983 in recursive_edit_1 () at keyboard.c:728
#71 0x0000000000490cad in Frecursive_edit () at keyboard.c:799
#72 0x0000000000406bc3 in main (argc=<optimized out>, argv=<optimized out>)
    at emacs.c:1607


In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu)
 of 2015-02-07 on loki.jorgenschaefer.de
Repository revision: cf498e5b9a73329edea0bdbf1bd8dfe06fdd75e2
System Description:	Debian GNU/Linux 7.8 (wheezy)

Configured using:
 `configure --without-x'

Configured features:
SOUND NOTIFY LIBXML2 ZLIB

Important settings:
  value of $LC_ALL: 
  value of $LC_COLLATE: de_DE.UTF-8
  value of $LC_CTYPE: de_DE.UTF-8
  value of $LC_MESSAGES: POSIX
  value of $LC_MONETARY: POSIX
  value of $LC_NUMERIC: POSIX
  value of $LC_TIME: POSIX
  value of $LANG: POSIX
  locale-coding-system: utf-8-unix

bug#19852: 25.0.50; show-paren-mode in sh-mode freezes Emacs

[Marcin Borkowski]

On 2015-02-13, at 12:26, Jorgen Schaefer <contact@jorgenschaefer.de> wrote:

> Emacs 25.0.50, no GUI, git ref cf498e5b9a, run with -Q, will freeze hard
> and dump core when using show-paren-mode in certain situations with
> files not ending with a newline.
>
> Reproduction:
>
> Create a file with these contents:
>
> ----
> #!/bin/bash
>
> if true
> then
> ----
>
> Do *not* include a final newline after the "then" line, possibly using
> (setq require-final-newline nil).
>
> Move point to the beginning of the file, enable `show-paren-mode', and
> go down line by line. Once you hit next-line on the "i" of "if", Emacs
> freezes. C-g will make it ask to auto-save and dump core.

Hi, I just checked on GNU Emacs 25.1.50.7 (commit fa2524b), and it seems
to work fine.  Can you confirm that the bug went away so that I could
close it?

Best,

-- 
Marcin

bug#19852: 25.0.50; show-paren-mode in sh-mode freezes Emacs

[Jorgen Schäfer]

[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]

Yep, looks like this is fixed now. Thanks for checking it!

On Sat, Mar 19, 2016 at 2:28 PM Marcin Borkowski <mbork@mbork.pl> wrote:

> On 2015-02-13, at 12:26, Jorgen Schaefer <contact@jorgenschaefer.de>
> wrote:
>
> > Emacs 25.0.50, no GUI, git ref cf498e5b9a, run with -Q, will freeze hard
> > and dump core when using show-paren-mode in certain situations with
> > files not ending with a newline.
> >
> > Reproduction:
> >
> > Create a file with these contents:
> >
> > ----
> > #!/bin/bash
> >
> > if true
> > then
> > ----
> >
> > Do *not* include a final newline after the "then" line, possibly using
> > (setq require-final-newline nil).
> >
> > Move point to the beginning of the file, enable `show-paren-mode', and
> > go down line by line. Once you hit next-line on the "i" of "if", Emacs
> > freezes. C-g will make it ask to auto-save and dump core.
>
> Hi, I just checked on GNU Emacs 25.1.50.7 (commit fa2524b), and it seems
> to work fine.  Can you confirm that the bug went away so that I could
> close it?
>
> Best,
>
> --
> Marcin
>

[-- Attachment #2: Type: text/html, Size: 1555 bytes --]

bug#19852: 25.0.50; show-paren-mode in sh-mode freezes Emacs

[Marcin Borkowski]

On 2016-03-19, at 14:31, Jorgen Schäfer <jorgen.schaefer@gmail.com> wrote:

> Yep, looks like this is fixed now. Thanks for checking it!

Thanks, so I'm closing this bug.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University