From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Levi Newsgroups: gmane.emacs.bugs Subject: bug#28862: Emacs 25.3.1 segmentation fault on killing *Colors* buffer Date: Mon, 16 Oct 2017 19:30:33 -0700 Message-ID: References: <59E46AFA.8060502@gmx.at> <83vajff7rt.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c1913c45e6ed3055bb4e89d" X-Trace: blaine.gmane.org 1508207481 31735 195.159.176.226 (17 Oct 2017 02:31:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 17 Oct 2017 02:31:21 +0000 (UTC) To: 28862@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 17 04:31:16 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4Hev-0006tS-KQ for geb-bug-gnu-emacs@m.gmane.org; Tue, 17 Oct 2017 04:31:09 +0200 Original-Received: from localhost ([::1]:36144 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e4Hf3-0002qI-0r for geb-bug-gnu-emacs@m.gmane.org; Mon, 16 Oct 2017 22:31:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35734) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e4Hes-0002py-SA for bug-gnu-emacs@gnu.org; Mon, 16 Oct 2017 22:31:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e4Heo-0001rc-Gf for bug-gnu-emacs@gnu.org; Mon, 16 Oct 2017 22:31:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35859) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e4Heo-0001rO-BD for bug-gnu-emacs@gnu.org; Mon, 16 Oct 2017 22:31:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e4Heo-0000dj-1W for bug-gnu-emacs@gnu.org; Mon, 16 Oct 2017 22:31:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Levi Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 17 Oct 2017 02:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28862 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28862-submit@debbugs.gnu.org id=B28862.15082074432435 (code B ref 28862); Tue, 17 Oct 2017 02:31:01 +0000 Original-Received: (at 28862) by debbugs.gnu.org; 17 Oct 2017 02:30:43 +0000 Original-Received: from localhost ([127.0.0.1]:44540 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4HeV-0000dC-0P for submit@debbugs.gnu.org; Mon, 16 Oct 2017 22:30:43 -0400 Original-Received: from mail-oi0-f53.google.com ([209.85.218.53]:56305) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4HeS-0000cy-7w for 28862@debbugs.gnu.org; Mon, 16 Oct 2017 22:30:41 -0400 Original-Received: by mail-oi0-f53.google.com with SMTP id g125so397050oib.12 for <28862@debbugs.gnu.org>; Mon, 16 Oct 2017 19:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=1QUQTw+cJgoYBukNR76qB+ub6Y7Mp4TiHulE2h4pgi0=; b=hzmiJCQ0gyBQIxnVDP+UjKf810HkvxFXqtWQ2UtH+yoPPl1cimje30i4gHN21Ou1dN rZFL50WY02hpquVj11MltMbKH56wiEMx+cGWP2q9QsQzMWL1EmhYpE4BBfUULgv3Wy/0 p43yfFDKR8iX5JhcGMDlK4gqbSqxSZ7huOH6blAZc+VCOw0lSE/8u5jWykQCYj6HcgYg CCp8a+NRhgPbRJcd75gjlhj9epIL+vyltnP9osY6eTxFlJxZ13aVwoSCIRiS4g14P5Wh likMRzafD1fG7ubLZ0GJ7pW4wAMbYo7Jv2XWa0u9Qy2OkGNz95OvInfogRsR5AzLMzxO +8Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=1QUQTw+cJgoYBukNR76qB+ub6Y7Mp4TiHulE2h4pgi0=; b=h9grPAqTkFiBkj5W5jXANJ3lyPqER9nilbAeAEhYyYav+zpaxYfA1bcOfCzHCoRgFu SRp9oETLw5nA91cfxF6H7zpDqcTualNOht8xIa204v34lFTCofui5iHDcN523f0B3z1I 1AoA0MegEvXfHqa8UDj0uKjgGWxbZFaQQqNkLXx4no4L+QBwo4B7hO9oFUZoh8Izc/O0 BRRTGgZ5zt1YSYMGVe6l6fkzrfCcrrWpSP/bD0AJ0TOpOe0TKIN/8aZkzA0NFULtjieD 2d/oUU0hhXzSBrt7IeyvA17aNpYeLdNej6NWZWLwM9EqzdYr6vx53FohXuSYJqhQvFXi lwvg== X-Gm-Message-State: AMCzsaXfsZSmEo8ydrms2EXj4QUVGRRvrsAk8ORXBPLvUCQHTfTgBEWp D1QajT1qdYBu16eWefDbi8WthMiMCS32UjtXUyuuBg== X-Google-Smtp-Source: ABhQp+QFa6qj/2vPsMpoJ1smADB6I8PcH5dgy8bqNhabkl/nizoBlhG1/ZiD22ywk2+uikCkNH1evdhFIJ288OD6HJw= X-Received: by 10.157.17.220 with SMTP id y28mr1562649oty.296.1508207434295; Mon, 16 Oct 2017 19:30:34 -0700 (PDT) Original-Received: by 10.157.49.99 with HTTP; Mon, 16 Oct 2017 19:30:33 -0700 (PDT) In-Reply-To: <83vajff7rt.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:138569 Archived-At: --94eb2c1913c45e6ed3055bb4e89d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey, Emacs 26.0.90 seems to have a similar bug when going through the same steps on my system. If other users can't reproduce this, it may also be related to the window manager's behaviour -- although that would still be strange. With 26.0.90, Emacs always hangs when trying to reproduce the issue, and prints to stderr: 'Fatal error 11: Segmentation fault'. Sending SIGTERM or ^C does not terminate the process, only killing it works. I tried running emacs through GDB in order to get a backtrace, but couldn't reproduce the crash there (memory corruption issue). Attaching to the process with `gdb -p ` allowed me to obtain this dump: #0 0x00007f66ca0a038b in __lll_lock_wait_private () at /usr/lib/libc.so.6 #1 0x00007f66ca01c609 in _int_free () at /usr/lib/libc.so.6 #2 0x00007f66cc8a7a43 in xmlCleanupCharEncodingHandlers () at /usr/lib/libxml2.so.2 #3 0x00007f66cc8c6819 in xmlCleanupParser () at /usr/lib/libxml2.so.2 #4 0x00000000005c7a95 in xml_cleanup_parser () at xml.c:266 #5 0x00000000004f5cf2 in shut_down_emacs (sig=3Dsig@entry=3D11, stuff=3Dstuff@entry=3D0) at emacs.c:2122 #6 0x00000000004f5ec3 in terminate_due_to_signal (sig=3Dsig@entry=3D11, backtrace_limit=3Dbacktrace_limit@entry=3D40) at emacs.c:377 #7 0x000000000050e3ce in handle_fatal_signal (sig=3Dsig@entry=3D11) at sysdep.c:1768 #8 0x000000000050e5e8 in deliver_thread_signal (sig=3D11, handler=3D0x50e3= c0 ) at sysdep.c:1742 #9 0x000000000050e66c in deliver_fatal_thread_signal (sig=3D) at sysdep.c:1780 #10 0x000000000050e66c in handle_sigsegv (sig=3D, siginfo=3D, arg=3D) at sysdep.c:1865 #11 0x00007f66cac72da0 in () at /usr/lib/libpthread.so.0 #12 0x00007f66ca01afc3 in malloc_consolidate () at /usr/lib/libc.so.6 #13 0x00007f66ca01df52 in _int_malloc () at /usr/lib/libc.so.6 #14 0x00007f66ca01faf4 in malloc () at /usr/lib/libc.so.6 #15 0x00000000005eb6d5 in hybrid_malloc (size=3D) at gmalloc.c:1734 #16 0x000000000054faad in lmalloc (size=3D4096) at alloc.c:1450 #17 0x000000000054faad in xmalloc (size=3Dsize@entry=3D4096) at alloc.c:846 #18 0x0000000000550bb3 in allocate_vector_block () at alloc.c:3063 #19 0x0000000000550bb3 in allocate_vector_from_block (nbytes=3D1160) at alloc.c:3127 #20 0x0000000000550bb3 in allocate_vectorlike (len=3D144) at alloc.c:3332 #21 0x000000000055181d in allocate_vectorlike (len=3D144) at alloc.c:3376 #22 0x000000000055181d in allocate_vector (len=3Dlen@entry=3D144) at alloc.c:3372 #23 0x0000000000551967 in Fmake_vector (length=3Dlength@entry=3D578, init=3Dinit@entry=3D0) at alloc.c:3466 #24 0x0000000000575116 in concat (nargs=3Dnargs@entry=3D1, args=3Dargs@entry=3D0x7fff73dbe7f8, target_type=3DLisp_Vectorlike, last_special=3Dlast_special@entry=3Dfalse) a= t fns.c:648 #25 0x0000000000575260 in Fcopy_sequence (arg=3D) at fns.c:5= 14 #26 0x00000000004334d2 in update_tool_bar (f=3Df@entry=3D0x114dc30 , save_match_data=3Dsave_match_data@entry=3Dfalse)= at xdisp.c:12272 #27 0x00000000004579d3 in update_tool_bar (save_match_data=3Dfalse, f=3D) at xdisp.c:12217 #28 0x00000000004579d3 in prepare_menu_bars () at xdisp.c:12054 #29 0x00000000004579d3 in redisplay_internal () at xdisp.c:13907 #30 0x00000000004591d5 in redisplay_preserve_echo_area (from_where=3Dfrom_where@entry=3D5) at xdisp.c:14602 #31 0x00000000004fff3a in read_char (commandflag=3Dcommandflag@entry=3D1, map=3Dmap@entry=3D70360643, prev_event=3D0, used_mouse_menu=3Dused_mouse_menu@entry=3D0x7fff73dc027b, end_time=3Dend_time@entry=3D0x0) at keyboard.c:2478 #32 0x0000000000502dac in read_key_sequence (keybuf=3Dkeybuf@entry=3D0x7fff73dc0370, prompt=3Dprompt@entry=3D0, dont_downcase_last=3Ddont_downcase_last@entry=3D= false, can_return_switch_frame=3Dcan_return_switch_frame@entry=3Dtrue, fix_current_buffer=3Dfix_current_buffer@entry=3Dtrue, prevent_redisplay=3Dp= revent_ redisplay@entry=3Dfalse, bufsize=3D30) at keyboard.c:9147 #33 0x00000000005047e4 in command_loop_1 () at keyboard.c:1368 #34 0x000000000056a8be in internal_condition_case (bfun=3Dbfun@entry=3D0x50= 45c0 , handlers=3Dhandlers@entry=3D21024, hfun=3Dhfun@entry=3D0x= 4fb4d0 ) at eval.c:1332 #35 0x00000000004f62a4 in command_loop_2 (ignore=3Dignore@entry=3D0) at keyboard.c:1110 #36 0x000000000056a82d in internal_catch (tag=3Dtag@entry=3D50880, func=3Dfunc@entry=3D0x4f6280 , arg=3Darg@entry=3D0) at eval= .c:1097 #37 0x00000000004f623b in command_loop () at keyboard.c:1089 #38 0x00000000004fb0e3 in recursive_edit_1 () at keyboard.c:695 #39 0x00000000004fb3fe in Frecursive_edit () at keyboard.c:766 #40 0x0000000000419ffe in main (argc=3D, argv=3D0x7fff73dc07= 28) at emacs.c:1713 It looks like this time around the stack isn't corrupted, and symbol information is there. Another point is that during one of the runs (albiet with my own configuration, rather than `emacs -Q`) is that I got the process to hang with the following output instead: *** Error in `./emacs': malloc(): memory corruption (fast): 0x0000000004066390 *** Fatal error 6: Aborted Is there a quick workaround I can use to avoid this crash for the time being? I would like to close all visible buffers when a frame is closed/deleted, like how I was initially doing so via 'delete-frame-functions. Thanks in advance, -Levi On Mon, Oct 16, 2017 at 8:10 AM, Eli Zaretskii wrote: > > Date: Mon, 16 Oct 2017 10:16:58 +0200 > > From: martin rudalics > > > > Now if killing a buffer in =E2=80=98delete-frame-functions=E2=80=99 may= delete a frame > > because, for example, the buffer is shown in a dedicated window which i= s > > the only window on that frame, you may run exactly in the scenario > > described above. I hopefully fixed that for Emacs 26 so if you could > > try the release version ... > > FWIW, the recipe doesn't crash for me in Emacs 26.0.90, so I guess > your fix solved at least this case. > > Thanks. > --94eb2c1913c45e6ed3055bb4e89d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey, Emacs 26.0.90 seems to have a similar bug when g= oing through=20 the same steps on my system. If other users can't reproduce this, it ma= y also be related to the window manager's behaviour -- although that=20 would still be strange.

With 26.0.90, Emacs always hangs when trying to reproduce the issue, and prints to stderr:=20 'Fatal error 11: Segmentation fault'. Sending SIGTERM or ^C does no= t=20 terminate the process, only killing it works.

I tried=20 running emacs through GDB in order to get a backtrace, but couldn't=20 reproduce the crash there (memory corruption issue). Attaching to the=20 process with `gdb -p <pid>` allowed me to obtain this dump:

#0=C2=A0 0x00007f66ca0a038b i= n __lll_lock_wait_private () at /usr/lib/libc.so.6
#1=C2=A0 0x00007f66ca= 01c609 in _int_free () at /usr/lib/libc.so.6
#2=C2=A0 0x00007f66cc8a7a43= in xmlCleanupCharEncodingHandlers () at /usr/lib/libxml2.so.2
#3=C2=A0 = 0x00007f66cc8c6819 in xmlCleanupParser () at /usr/lib/libxml2.so.2
#4=C2= =A0 0x00000000005c7a95 in xml_cleanup_parser () at xml.c:266
#5=C2=A0 0x= 00000000004f5cf2 in shut_down_emacs (sig=3Dsig@entry=3D11, stuff=3Dstuff@en= try=3D0)
=C2=A0=C2=A0=C2=A0 at emacs.c:2122
#6=C2=A0 0x00000000004f5e= c3 in terminate_due_to_signal (sig=3Dsig@entry=3D11, backtrace_limit=3Dback= trace_limit@entry=3D40) at emacs.c:377
#7=C2=A0 0x000000000050e3ce = in handle_fatal_signal (sig=3Dsig@entry=3D11) at sysdep.c:1768
#8=C2=A0 = 0x000000000050e5e8 in deliver_thread_signal (sig=3D11, handler=3D0x50e3c0 &= lt;handle_fatal_signal>) at sysdep.c:1742
#9=C2=A0 0x000000000050e66c= in deliver_fatal_thread_signal (sig=3D<optimized out>)
=C2=A0=C2= =A0=C2=A0 at sysdep.c:1780
#10 0x000000000050e66c in handle_sigsegv (sig=3D<optimized out>,=20 siginfo=3D<optimized out>, arg=3D<optimized out>) at=20 sysdep.c:1865
#11 0x00007f66cac72da0 in <signal handler called> ()= at /usr/lib/libpthread.so.0
#12 0x00007f66ca01afc3 in malloc_consolidat= e () at /usr/lib/libc.so.6
#13 0x00007f66ca01df52 in _int_malloc () at /= usr/lib/libc.so.6
#14 0x00007f66ca01faf4 in malloc () at /usr/lib/libc.s= o.6
#15 0x00000000005eb6d5 in hybrid_malloc (size=3D<optimized out>= ;) at gmalloc.c:1734
#16 0x000000000054faad in lmalloc (size=3D4096) at = alloc.c:1450
#17 0x000000000054faad in xmalloc (size=3Dsize@entry=3D4096= ) at alloc.c:846
#18 0x0000000000550bb3 in allocate_vector_block () at a= lloc.c:3063
#19 0x0000000000550bb3 in allocate_vector_from_block (nbytes= =3D1160) at alloc.c:3127
#20 0x0000000000550bb3 in allocate_vectorlike (= len=3D144) at alloc.c:3332
#21 0x000000000055181d in allocate_vectorlike= (len=3D144) at alloc.c:3376
#22 0x000000000055181d in allocate_vector (= len=3Dlen@entry=3D144) at alloc.c:3372
#23 0x0000000000551967 in Fmake_v= ector (length=3Dlength@entry=3D578, init=3Dinit@entry=3D0)
=C2=A0=C2=A0= =C2=A0 at alloc.c:3466
#24 0x0000000000575116 in concat (nargs=3Dnargs@e= ntry=3D1, args=3Dargs@entry=3D0x7fff73dbe7f8, target_type=3DLisp_Vecto= rlike, last_special=3Dlast_special@entry=3Dfalse) at fns.c:648
#25 = 0x0000000000575260 in Fcopy_sequence (arg=3D<optimized out>) at fns.c= :514
#26 0x00000000004334d2 in update_tool_bar (f=3Df@entry=3D0x114dc30 = <bss_sbrk_buffer+5520464>, save_match_data=3Dsave_match_data@ent= ry=3Dfalse) at xdisp.c:12272
#27 0x00000000004579d3 in update_tool_bar (= save_match_data=3Dfalse, f=3D<optimized out>)
=C2=A0=C2=A0=C2=A0 a= t xdisp.c:12217
#28 0x00000000004579d3 in prepare_menu_bars () at xdisp.= c:12054
#29 0x00000000004579d3 in redisplay_internal () at xdisp.c:13907=
#30 0x00000000004591d5 in redisplay_preserve_echo_area (from_where=3Dfr= om_where@entry=3D5) at xdisp.c:14602
#31 0x00000000004fff3a in read= _char (commandflag=3Dcommandflag@entry=3D1, map=3Dmap@entry=3D70360643= , prev_event=3D0, used_mouse_menu=3Dused_mouse_menu@entry=3D0x7fff73dc= 027b, end_time=3Dend_time@entry=3D0x0) at keyboard.c:2478
#32 0x00000000= 00502dac in read_key_sequence (keybuf=3Dkeybuf@entry=3D0x7fff73dc0370,= prompt=3Dprompt@entry=3D0, dont_downcase_last=3Ddont_downcase_last@en= try=3Dfalse, can_return_switch_frame=3Dcan_return_switch_frame@entry= =3Dtrue, fix_current_buffer=3Dfix_current_buffer@entry=3Dtrue, pr= event_redisplay=3Dprevent_redisplay@entry=3Dfalse, bufsize=3D30)
= =C2=A0=C2=A0=C2=A0 at keyboard.c:9147
#33 0x00000000005047e4 in command_= loop_1 () at keyboard.c:1368
#34 0x000000000056a8be in internal_condition_case (bfun=3Dbfun@entry=3D0x5045c= 0 <command_loop_1>, handlers=3Dhandlers@entry=3D21024,=20 hfun=3Dhfun@entry=3D0x4fb4d0 <cmd_error>)
=C2=A0=C2=A0=C2=A0 at ev= al.c:1332
#35 0x00000000004f62a4 in command_loop_2 (ignore=3Dignore@entr= y=3D0) at keyboard.c:1110
#36 0x000000000056a82d in internal_catch (tag=3Dtag@entry=3D50880,=20 func=3Dfunc@entry=3D0x4f6280 <command_loop_2>, arg=3Darg@entry=3D0) a= t=20 eval.c:1097
#37 0x00000000004f623b in command_loop () at keyboard.c:1089=
#38 0x00000000004fb0e3 in recursive_edit_1 () at keyboard.c:695
#39 = 0x00000000004fb3fe in Frecursive_edit () at keyboard.c:766
#40 0x0000000= 000419ffe in main (argc=3D<optimized out>, argv=3D0x7fff73dc0728)
= =C2=A0=C2=A0=C2=A0 at emacs.c:1713

It l= ooks like this time around the stack isn't corrupted, and symbol inform= ation is there.

Another point is that during one of the runs (albiet with my own configuration, rather than `emacs -Q`) is that I got the process to hang with the=20 following output instead:

*** Error in `./emacs': malloc(): memory corruption (fast): 0x000= 0000004066390 ***
Fatal error 6: Aborted

Is there a quick workaround I can use to avoid this crash for the time=20 being? I would like to close all visible buffers when a frame is=20 closed/deleted, like how I was initially doing so via=20 'delete-frame-functions.

Thanks in advance,

-Levi

On Mon, Oct 16, 2017 = at 8:10 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> Date: Mon, 16 Oct 2017 10:16:58 +0200
> From: martin rudalics <rudalics@= gmx.at>
>
> Now if killing a buffer in =E2=80=98delete-frame-functions=E2=80=99 ma= y delete a frame
> because, for example, the buffer is shown in a dedicated window which = is
> the only window on that frame, you may run exactly in the scenario
> described above.=C2=A0 I hopefully fixed that for Emacs 26 so if you c= ould
> try the release version ...

FWIW, the recipe doesn't crash for me in Emacs 26.0.90, so I gue= ss
your fix solved at least this case.

Thanks.

--94eb2c1913c45e6ed3055bb4e89d--