From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 07 19:13:02 2016 Received: (at submit) by debbugs.gnu.org; 7 Oct 2016 23:13:02 +0000 Received: from localhost ([127.0.0.1]:48120 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bseK5-000257-9S for submit@debbugs.gnu.org; Fri, 07 Oct 2016 19:13:02 -0400 Received: from eggs.gnu.org ([208.118.235.92]:59444) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bseK2-00024q-Mu for submit@debbugs.gnu.org; Fri, 07 Oct 2016 19:13:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bseJs-0003ax-Qd for submit@debbugs.gnu.org; Fri, 07 Oct 2016 19:12:53 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,HTML_MESSAGE, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:47872) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bseJs-0003ab-Mm for submit@debbugs.gnu.org; Fri, 07 Oct 2016 19:12:48 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bseJm-00007c-N6 for bug-gnu-emacs@gnu.org; Fri, 07 Oct 2016 19:12:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bseJi-0003V4-Au for bug-gnu-emacs@gnu.org; Fri, 07 Oct 2016 19:12:42 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36844) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bseJi-0003TD-5g for bug-gnu-emacs@gnu.org; Fri, 07 Oct 2016 19:12:38 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43014) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1bseJg-00047A-Fi for bug-emacs@gnu.org; Fri, 07 Oct 2016 19:12:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bseJa-0003Oy-QW for bug-emacs@gnu.org; Fri, 07 Oct 2016 19:12:35 -0400 Received: from mail-lf0-x22c.google.com ([2a00:1450:4010:c07::22c]:34046) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bseJa-0003Nk-5D for bug-emacs@gnu.org; Fri, 07 Oct 2016 19:12:30 -0400 Received: by mail-lf0-x22c.google.com with SMTP id b81so51332741lfe.1 for ; Fri, 07 Oct 2016 16:12:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=TiXQ7MCAtzoXrkVubx28Lls98aqbVWTGhquQm5LjlPU=; b=BAP8yZuHfjnK3mYX8aTntsaEmsXhyxgL9vQKI9QKXy4Kpb28jMjPM+/b+nmtCJyndN HGOBbIW3Ks1TTGwiadjvD3Y57oIOQDE/dCfCCFbYsTqmI5z2K3ODRshKeQO4buTda/Ge T2Flxy+/vwADij3SM3q3iyAU/GBkyUBgSqHYo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TiXQ7MCAtzoXrkVubx28Lls98aqbVWTGhquQm5LjlPU=; b=M7mGktPwC30o2EKpaiLuXbGdfzOmnoHQcFtvjgI3KIjbK1fo4TRkuO2Ed/MB8t2APD YpQ9qES9lUqPigBuaYa5fJtAwtjIqGdRx6PUEhYo7ofc3cMpdiEl2yrs2WHHEMPJW3Au aM3Gb4BKqD4fhvLSDWpXdYQON47bfzVHbQ+3H+5AKqERHhn9258SN0WTxLizlfDj1llO IphN16qEs851iKYoubOLpqsHl/QSizM1g74wVI2TRnQXWFHUh/bI2tbbEmER5iOQU/up rX7LDJuREyOReYGjWd3VvxbiaBGSV9Rw0UNyoTv+Na0nnz5kqA+IEBsENwYiVIJswlFG FUmQ== X-Gm-Message-State: AA6/9RkBH9H+BM/+wFU0hEPu11tXv6Ez/PUs7dzPyilJrb3PdpM3pv7zGhjB6zUwqmHVTaxqGwbylUcBBRZHMr+4 X-Received: by 10.46.1.166 with SMTP id f38mr3024142lji.76.1475881946804; Fri, 07 Oct 2016 16:12:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.66.211 with HTTP; Fri, 7 Oct 2016 16:12:26 -0700 (PDT) From: Reuben Thomas Date: Sat, 8 Oct 2016 00:12:26 +0100 Message-ID: Subject: Crashes in 25.1 To: bug-emacs Content-Type: multipart/alternative; boundary=001a1142bb4a2b8bbe053e4e8bf2 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.1 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.1 (----) --001a1142bb4a2b8bbe053e4e8bf2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Using 25.1 Ubuntu packages from https://launchpad.net/~adrozdoff Core was generated by `/home/rrt/.local/bin/emacs'. Program terminated with signal SIGABRT, Aborted. #0 0x00007fe0d911f2a9 in raise (sig=3Dsig@entry=3D6) at ../sysdeps/unix/sysv/linux/pt-raise.c:35 35 ../sysdeps/unix/sysv/linux/pt-raise.c: No such file or directory. [Current thread is 1 (Thread 0x7fe0e00bab00 (LWP 16170))] (gdb) where #0 0x00007fe0d911f2a9 in raise (sig=3Dsig@entry=3D6) at ../sysdeps/unix/sysv/linux/pt-raise.c:35 #1 0x00000000004ef104 in terminate_due_to_signal (sig=3Dsig@entry=3D6, backtrace_limit=3Dbacktrace_limit@entry=3D40) at emacs.c:381 #2 0x0000000000508383 in emacs_abort () at sysdep.c:2247 #3 0x0000000000563540 in Fsignal (error_symbol=3Derror_symbol@entry=3D2865= 6, data=3D101381475) at eval.c:1478 #4 0x0000000000563549 in xsignal (error_symbol=3Derror_symbol@entry=3D2865= 6, data=3D) at eval.c:1577 #5 0x0000000000563577 in xsignal1 (error_symbol=3Derror_symbol@entry=3D286= 56, arg=3D) at eval.c:1592 #6 0x00000000005330db in compile_pattern (posix=3D, translate=3D0, pattern=3D, cp=3D0xb90db8 ) = at search.c:154 #7 0x00000000005330db in compile_pattern (pattern=3Dpattern@entry=3D520398= 44, regp=3Dregp@entry=3D0x0, translate=3Dtranslate@entry=3D0, posix=3Dposix@ent= ry=3Dfalse, multibyte=3D) at search.c:237 #8 0x00000000005352a1 in fast_string_match_internal (regexp=3Dregexp@entry=3D52039844, string=3Dstring@entry=3D91929188, table=3Dtable@entry=3D0) at search.c:471 #9 0x000000000051cf51 in Ffind_file_name_handler (string=3D91929188, regexp=3D52039844) at lisp.h:4010 #10 0x000000000051cf51 in Ffind_file_name_handler (filename=3Dfilename@entry=3D91929188, operation=3Doperation@entry=3D19872) at fileio.c:292 #11 0x000000000051e460 in Fexpand_file_name (name=3D91929188, default_directory=3Ddefault_directory@entry=3D0) at fileio.c:809 #12 0x000000000052425d in Fdo_auto_save (no_message=3D, no_message@entry=3D44448, current_only=3Dcurrent_only@entry=3D0) at fileio.c:5521 #13 0x00000000004eef20 in shut_down_emacs (sig=3Dsig@entry=3D11, stuff=3Dstuff@entry=3D0) at emacs.c:2000 #14 0x00000000004ef0d5 in terminate_due_to_signal (sig=3Dsig@entry=3D11, backtrace_limit=3Dbacktrace_limit@entry=3D40) at emacs.c:365 #15 0x0000000000506fce in handle_fatal_signal (sig=3Dsig@entry=3D11) at sysdep.c:1601 #16 0x00000000005071f3 in deliver_thread_signal (sig=3Dsig@entry=3D11, handler=3D0x506fc0 ) at sysdep.c:1575 #17 0x000000000050725f in handle_sigsegv (sig=3D11) at sysdep.c:1613 #18 0x000000000050725f in handle_sigsegv (sig=3D11, siginfo=3D, arg=3D) at sysdep.c:1695 #19 0x00007fe0d911f3d0 in () at /lib/x86_64-linux-gnu/libpthread.so.0 #20 0x000000000054a8e9 in mark_object (arg=3D) at alloc.c:64= 46 #21 0x000000000054a9cb in mark_object (arg=3D) at alloc.c:65= 39 #22 0x000000000054a9cb in mark_object (arg=3D) at alloc.c:65= 39 #23 0x000000000054b20c in Fgarbage_collect (end=3D0x7fff0376df88) at alloc.c:5745 #24 0x000000000054b20c in Fgarbage_collect () at alloc.c:5979 #25 0x000000000059979e in exec_byte_code () at lisp.h:4656 #26 0x000000000059979e in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3Dargs_template@entry=3D0, nargs=3Dnargs@entry=3D0, args=3D, args@entry=3D0x0) at bytecode.c:714 #27 0x000000000056283f in funcall_lambda (fun=3D78975333, nargs=3Dnargs@ent= ry=3D1, arg_vector=3Darg_vector@entry=3D0x7fff0376e300) at eval.c:2921 #28 0x0000000000562c3b in Ffuncall (nargs=3D2, args=3Dargs@entry=3D0x7fff03= 76e2f8) at eval.c:2754 #29 0x00000000005975d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3Dargs_template@entry=3D0, nargs=3Dnargs@entry=3D0, args=3D, args@entry=3D0x0) at bytecode.c:880 #30 0x000000000056283f in funcall_lambda (fun=3D78974597, nargs=3Dnargs@ent= ry=3D2, arg_vector=3Darg_vector@entry=3D0x7fff0376e520) at eval.c:2921 #31 0x0000000000562c3b in Ffuncall (nargs=3D3, args=3Dargs@entry=3D0x7fff03= 76e518) at eval.c:2754 #32 0x00000000005975d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3Dargs_template@entry=3D0, nargs=3Dnargs@entry=3D0, args=3D, args@entry=3D0x0) at bytecode.c:880 #33 0x000000000056283f in funcall_lambda (fun=3D78926773, nargs=3Dnargs@ent= ry=3D1, arg_vector=3Darg_vector@entry=3D0x7fff0376e740) at eval.c:2921 #34 0x0000000000562c3b in Ffuncall (nargs=3D2, args=3Dargs@entry=3D0x7fff03= 76e738) at eval.c:2754 #35 0x00000000005975d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3Dargs_template@entry=3D0, nargs=3Dnargs@entry=3D0, args=3D, args@entry=3D0x0) at bytecode.c:880 #36 0x000000000056283f in funcall_lambda (fun=3D78925797, nargs=3Dnargs@ent= ry=3D2, arg_vector=3Darg_vector@entry=3D0x7fff0376e958) at eval.c:2921 #37 0x0000000000562c3b in Ffuncall (nargs=3Dnargs@entry=3D3, args=3D0x7fff0376e950) at eval.c:2754 #38 0x0000000000564020 in Fapply (nargs=3Dnargs@entry=3D2, args=3Dargs@entry=3D0x7fff0376ea10) at eval.c:2321 #39 0x000000000056425c in apply1 (fn=3D56303360, arg=3D) at eval.c:2537 #40 0x000000000056163e in internal_condition_case_1 (bfun=3Dbfun@entry=3D0x= 59b3f0 , arg=3D103083523, handlers=3Dhandlers@entry=3D19= 056, hfun=3Dhfun@entry=3D0x59b370 ) at eval.c= :1333 #41 0x000000000059af2d in read_process_output (coding=3D0x53b3920, nbytes=3D652, chars=3D0x7fff0376eaa0 "Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\\\\begin{ <-- HERE tex}(.*?)\\\\end{tex}/ at /usr/bin/texify line 521.\nUnescaped left brace in regex is depre"..., p=3D0x287) at process.c:5440 #42 0x000000000059af2d in read_process_output (proc=3Dproc@entry=3D86121909= , channel=3D) at process.c:5351 #43 0x000000000059cd88 in status_notify (deleting_process=3Ddeleting_process@entry=3D0x0, wait_proc=3Dwait_proc@ent= ry=3D0x0) at process.c:6655 #44 0x00000000005a37ae in wait_reading_process_output (time_limit=3D, nsecs=3D, read_kbd=3Dread_kbd= @entry=3D-1, do_display=3Ddo_display@entry=3Dtrue, wait_for_cell=3Dwait_for_cell@entry= =3D0, wait_proc=3Dwait_proc@entry=3D0x0, just_wait_proc=3D0) at process.c:4663 #45 0x00000000004fa0b4 in read_char (end_time=3D0x7fff037706f0, used_mouse_menu=3D0x0, kbp=3D) at keyboard.c:3798 #46 0x00000000004fa0b4 in read_char (used_mouse_menu=3D, local_getcjmp=3D, end_time=3D) at keyboard.c:= 2148 #47 0x00000000004fa0b4 in read_char (used_mouse_menu=3D, prev_event=3D, local_getcjmp=3D, end_time=3D) at keyboard.c:2211 #48 0x00000000004fa0b4 in read_char (commandflag=3Dcommandflag@entry=3D0, map=3Dmap@entry=3D0, prev_event=3Dprev_event@entry=3D0, used_mouse_menu=3Dused_mouse_menu@entry=3D0x0, end_time=3D0x7fff037706f0) a= t keyboard.c:2799 ---Type to continue, or q to quit--- #49 0x0000000000580baf in read_filtered_event (no_switch_frame=3Dfalse, ascii_required=3Dfalse, error_nonascii=3Dfalse, input_method=3D, seconds=3D) at lread.c:614 #50 0x0000000000562e1f in Ffuncall (nargs=3D4, args=3Dargs@entry=3D0x7fff03= 770810) at eval.c:2700 #51 0x00000000005975d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3D, nargs=3Dnargs@entry=3D1, args=3D, args@entry=3D0x877d4= c ) at bytecode.c:880 #52 0x0000000000562976 in funcall_lambda (fun=3D140733251521104, nargs=3Dnargs@entry=3D1, arg_vector=3D0x877d4c , arg_vector@entry=3D0x7fff037709b8) at eval.c:2855 #53 0x0000000000562c3b in Ffuncall (nargs=3D2, args=3Dargs@entry=3D0x7fff03= 7709b0) at eval.c:2754 #54 0x00000000005975d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3D, nargs=3Dnargs@entry=3D0, args=3D, args@entry=3D0x3dd8d= a4) at bytecode.c:880 #55 0x0000000000562976 in funcall_lambda (fun=3D140733251521824, nargs=3Dnargs@entry=3D0, arg_vector=3D0x3dd8da4, arg_vector@entry=3D0x7fff03770c98) at eval.c:2855 #56 0x0000000000562c3b in Ffuncall (nargs=3Dnargs@entry=3D1, args=3Dargs@entry=3D0x7fff03770c90) at eval.c:2754 #57 0x00000000005641bc in Fapply (nargs=3D2, args=3D0x7fff03770c90) at eval.c:2274 #58 0x0000000000562d41 in Ffuncall (nargs=3D3, args=3Dargs@entry=3D0x7fff03= 770c88) at eval.c:2673 #59 0x00000000005975d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3Dargs_template@entry=3D0, nargs=3Dnargs@entry=3D0, args=3D, args@entry=3D0x0) at bytecode.c:880 #60 0x000000000056283f in funcall_lambda (fun=3D10146693, nargs=3Dnargs@ent= ry=3D1, arg_vector=3Darg_vector@entry=3D0x7fff03770ea8) at eval.c:2921 #61 0x0000000000562c3b in Ffuncall (nargs=3Dnargs@entry=3D2, args=3Dargs@entry=3D0x7fff03770ea0) at eval.c:2754 #62 0x0000000000562f3a in call1 (fn=3Dfn@entry=3D45264, arg1=3Darg1@entry= =3D80505365) at eval.c:2552 #63 0x00000000004f49c8 in timer_check (idle_timers=3D, timers=3D) at keyboard.c:4427 #64 0x00000000004f49c8 in timer_check () at keyboard.c:4489 #65 0x00000000004f4d89 in readable_events (flags=3Dflags@entry=3D1) at keyboard.c:3328 #66 0x00000000004f6608 in get_input_pending (flags=3Dflags@entry=3D1) at keyboard.c:6725 #67 0x00000000004f8d78 in detect_input_pending_run_timers (do_display=3Ddo_display@entry=3Dtrue) at keyboard.c:9862 #68 0x00000000005a2abb in wait_reading_process_output (time_limit=3Dtime_limit@entry=3D30, nsecs=3Dnsecs@entry=3D0, read_kbd=3Dread_kbd@entry=3D-1, do_display=3Ddo_display@entry=3Dtrue, wait_for_cell=3Dwait_for_cell@entry=3D0, wait_proc=3Dwait_proc@entry=3D0x0, just_wait_proc=3D0) at process.c:4958 #69 0x0000000000422e12 in sit_for (timeout=3D, reading=3Dreading@entry=3Dtrue, display_option=3Ddisplay_option@entry=3D1) = at dispnew.c:5762 #70 0x00000000004fb273 in read_char (commandflag=3Dcommandflag@entry=3D1, map=3Dmap@entry=3D94322451, prev_event=3D0, used_mouse_menu=3Dused_mouse_menu@entry=3D0x7fff03771b4b, end_time=3Dend_time@entry=3D0x0) at keyboard.c:2714 #71 0x00000000004fbeda in read_key_sequence (keybuf=3Dkeybuf@entry=3D0x7fff03771c20, 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=3Dprevent_redisplay@entry=3Dfalse, bufsize=3D30) at keyboard.c:9063 #72 0x00000000004fdb26 in command_loop_1 () at keyboard.c:1365 #73 0x00000000005615b2 in internal_condition_case (bfun=3Dbfun@entry=3D0x4f= d920 , handlers=3Dhandlers@entry=3D19056, hfun=3Dhfun@entry=3D0x= 4f4080 ) at eval.c:1309 #74 0x00000000004ef54c in command_loop_2 (ignore=3Dignore@entry=3D0) at keyboard.c:1107 #75 0x0000000000561553 in internal_catch (tag=3Dtag@entry=3D45840, func=3Dfunc@entry=3D0x4ef530 , arg=3Darg@entry=3D0) at eval.c:1074 #76 0x00000000004ef509 in command_loop () at keyboard.c:1086 #77 0x00000000004f3c77 in recursive_edit_1 () at keyboard.c:692 #78 0x00000000004f3fb8 in Frecursive_edit () at keyboard.c:763 #79 0x0000000000418dfe in main (argc=3D1, argv=3D0x7fff03771fa8) at emacs.c= :1626 (gdb) =E2=80=8BI tried =E2=80=8Bbuilding the current emacs-25 branch with ./confi= gure --with-xwidgets --with-cairo --with-modules, I get a different crash: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f1fd486a2a9 in raise (sig=3Dsig@entry=3D11) at ../sysdeps/unix/sysv/linux/pt-raise.c:35 35 ../sysdeps/unix/sysv/linux/pt-raise.c: No such file or directory. [Current thread is 1 (Thread 0x7f1fdd77ab00 (LWP 2411))] (gdb) where #0 0x00007f1fd486a2a9 in raise (sig=3Dsig@entry=3D11) at ../sysdeps/unix/sysv/linux/pt-raise.c:35 #1 0x00000000004f11c4 in terminate_due_to_signal (sig=3Dsig@entry=3D11, backtrace_limit=3Dbacktrace_limit@entry=3D40) at emacs.c:381 #2 0x000000000050901e in handle_fatal_signal (sig=3Dsig@entry=3D11) at sysdep.c:1601 #3 0x0000000000509243 in deliver_thread_signal (sig=3Dsig@entry=3D11, handler=3D0x509010 ) at sysdep.c:1575 #4 0x00000000005092af in handle_sigsegv (sig=3D11) at sysdep.c:1613 #5 0x00000000005092af in handle_sigsegv (sig=3D11, siginfo=3D, arg=3D) at sysdep.c:1695 #6 0x00007f1fd486a3d0 in () at /lib/x86_64-linux-gnu/libpthread.so.0 #7 0x000000000056dd24 in sxhash (y=3D, x=3D0) at lisp.h:2025 #8 0x000000000056dd24 in sxhash (len=3D, ptr=3D) at fns.c:4246 #9 0x000000000056dd24 in sxhash (len=3D, ptr=3D) at fns.c:4258 #10 0x000000000056dd24 in sxhash (obj=3D, depth=3Ddepth@entr= y=3D1) at fns.c:4371 #11 0x000000000056dd8e in sxhash (depth=3D1, obj=3D) at fns.c:4296 #12 0x000000000056dd8e in sxhash (depth=3D0, list=3D12657603) at fns.c:4298 #13 0x000000000056dd8e in sxhash (obj=3D, depth=3D0) at fns.c:4391 #14 0x00000000005700f1 in hash_lookup (h=3Dh@entry=3D0x123d968, key=3Dkey@entry=3D12657603, hash=3Dhash@entry=3D0x0) at fns.c:3944 #15 0x00000000005701c6 in Fgethash (key=3Dkey@entry=3D12657603, table=3D191= 26637, dflt=3Ddflt@entry=3D0) at fns.c:4621 #16 0x00000000005c4462 in ftfont_lookup_cache (key=3D12657603, cache_for=3Dcache_for@entry=3DFTFONT_CACHE_FOR_FACE) at ftfont.c:375 #17 0x00000000005c557e in ftfont_close (font=3D0x13399f0) at ftfont.c:1329 #18 0x000000000054964d in sweep_vectors () at alloc.c:3219 #19 0x000000000054d747 in Fgarbage_collect () at alloc.c:6981 #20 0x000000000054d747 in Fgarbage_collect (end=3D0x7ffe7d9773f8) at alloc.c:5795 #21 0x000000000054d747 in Fgarbage_collect () at alloc.c:5979 #22 0x0000000000564b54 in Ffuncall () at lisp.h:4656 #23 0x0000000000564b54 in Ffuncall (nargs=3Dnargs@entry=3D2, args=3Dargs@entry=3D0x7ffe7d9775c0) at eval.c:2648 #24 0x0000000000564f7a in call1 (fn=3Dfn@entry=3D21648, arg1=3Darg1@entry= =3D71809572) at eval.c:2557 #25 0x0000000000588064 in readevalloop (readcharfun=3Dreadcharfun@entry=3D2= 4384, stream=3Dstream@entry=3D0x447bd50, sourcename=3Dsourcename@entry=3D71809572= , printflag=3Dprintflag@entry=3Dfalse, unibyte=3Dunibyte@entry=3D0, readfun=3Dreadfun@entry=3D0, start=3D0, end=3D0) at lread.c:1830 #26 0x000000000058874c in Fload (file=3D9181396, noerror=3Dnoerror@entry=3D= 0, nomessage=3Dnomessage@entry=3D44784, nosuffix=3Dnosuffix@entry=3D0, must_suffix=3D, must_suffix@entry=3D44784) at lread.c:1335 #27 0x000000000056658f in Fautoload_do_load (fundef=3D9508451, funname=3D4814608, macro_only=3D0) at eval.c:1962 #28 0x0000000000564e5f in Ffuncall (nargs=3D3, args=3Dargs@entry=3D0x7ffe7d= 977940) at eval.c:2705 #29 0x000000000059c8d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3D, nargs=3Dnargs@entry=3D1, args=3D, args@entry=3D0x41316= 64) at bytecode.c:880 #30 0x00000000005649b6 in funcall_lambda (fun=3D140731005500480, nargs=3Dnargs@entry=3D1, arg_vector=3D0x4131664, arg_vector@entry=3D0x7ffe7d977b98) at eval.c:2860 #31 0x0000000000564c7b in Ffuncall (nargs=3D2, args=3Dargs@entry=3D0x7ffe7d= 977b90) at eval.c:2759 #32 0x000000000059c8d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3D, nargs=3Dnargs@entry=3D10, args=3D, args@entry=3D0x4130= fc4) at bytecode.c:880 #33 0x00000000005649b6 in funcall_lambda (fun=3D140731005501328, nargs=3Dnargs@entry=3D10, arg_vector=3D0x4130fc4, arg_vector@entry=3D0x7ffe7d977d58) at eval.c:2860 #34 0x0000000000564c7b in Ffuncall (nargs=3Dnargs@entry=3D11, args=3D0x7ffe7d977d50) at eval.c:2759 #35 0x0000000000566060 in Fapply (nargs=3D, args=3D0x7ffe7d977f10) at eval.c:2326 #36 0x0000000000564d81 in Ffuncall (nargs=3D3, args=3Dargs@entry=3D0x7ffe7d= 977f08) at eval.c:2678 #37 0x000000000059c8d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3D, nargs=3Dnargs@entry=3D0, args=3D, args@entry=3D0x41306= c4) at bytecode.c:880 #38 0x00000000005649b6 in funcall_lambda (fun=3D140731005501776, nargs=3Dnargs@entry=3D0, arg_vector=3D0x41306c4, arg_vector@entry=3D0x7ffe7d9780c0) at eval.c:2860 #39 0x0000000000564c7b in Ffuncall (nargs=3D1, args=3Dargs@entry=3D0x7ffe7d= 9780b8) at eval.c:2759 #40 0x000000000059c8d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3D, nargs=3Dnargs@entry=3D0, args=3D, args@entry=3D0x41303= f4) at bytecode.c:880 #41 0x00000000005649b6 in funcall_lambda (fun=3D140731005502496, nargs=3Dnargs@entry=3D0, arg_vector=3D0x41303f4, arg_vector@entry=3D0x7ffe7d978398) at eval.c:2860 #42 0x0000000000564c7b in Ffuncall (nargs=3Dnargs@entry=3D1, args=3Dargs@entry=3D0x7ffe7d978390) at eval.c:2759 #43 0x00000000005661fc in Fapply (nargs=3D2, args=3D0x7ffe7d978390) at eval.c:2279 #44 0x0000000000564d81 in Ffuncall (nargs=3D3, args=3Dargs@entry=3D0x7ffe7d= 978388) at eval.c:2678 #45 0x000000000059c8d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3Dargs_template@entry=3D0, nargs=3Dnargs@entry=3D0, args=3D, args@entry=3D0x0) at bytecode.c:880 #46 0x000000000056487f in funcall_lambda (fun=3D10158805, nargs=3Dnargs@ent= ry=3D1, arg_vector=3Darg_vector@entry=3D0x7ffe7d9785a8) at eval.c:2926 #47 0x0000000000564c7b in Ffuncall (nargs=3Dnargs@entry=3D2, args=3Dargs@entry=3D0x7ffe7d9785a0) at eval.c:2759 #48 0x0000000000564f7a in call1 (fn=3Dfn@entry=3D45600, arg1=3Darg1@entry= =3D89586453) at eval.c:2557 #49 0x00000000004f6a98 in timer_check (idle_timers=3D, timers=3D) at keyboard.c:4427 #50 0x00000000004f6a98 in timer_check () at keyboard.c:4489 #51 0x00000000004f6e59 in readable_events (flags=3Dflags@entry=3D1) at keyboard.c:3328 #52 0x00000000004f86d8 in get_input_pending (flags=3Dflags@entry=3D1) at keyboard.c:6725 #53 0x00000000004fadb8 in detect_input_pending_run_timers (do_display=3Ddo_display@entry=3Dtrue) at keyboard.c:9862 #54 0x00000000005a7d9b in wait_reading_process_output (time_limit=3Dtime_limit@entry=3D30, nsecs=3Dnsecs@entry=3D0, read_kbd=3Dread_kbd@entry=3D-1, do_display=3Ddo_display@entry=3Dtrue, wait_for_cell=3Dwait_for_cell@entry=3D0, wait_proc=3Dwait_proc@entry=3D0x0, just_wait_proc=3D0) at process.c:4958 #55 0x0000000000423b12 in sit_for (timeout=3D, reading=3Dreading@entry=3Dtrue, display_option=3Ddisplay_option@entry=3D1) = at dispnew.c:5762 ---Type to continue, or q to quit--- #56 0x00000000004fd092 in read_char (commandflag=3Dcommandflag@entry=3D1, map=3Dmap@entry=3D40733251, prev_event=3D0, used_mouse_menu=3Dused_mouse_menu@entry=3D0x7ffe7d97924b, end_time=3Dend_time@entry=3D0x0) at keyboard.c:2714 #57 0x00000000004fdf2a in read_key_sequence (keybuf=3Dkeybuf@entry=3D0x7ffe7d979320, 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=3Dprevent_redisplay@entry=3Dfalse, bufsize=3D30) at keyboard.c:9063 #58 0x00000000004ffb76 in command_loop_1 () at keyboard.c:1365 #59 0x00000000005635f2 in internal_condition_case (bfun=3Dbfun@entry=3D0x4f= f970 , handlers=3Dhandlers@entry=3D18912, hfun=3Dhfun@entry=3D0x= 4f6160 ) at eval.c:1314 #60 0x00000000004f160c in command_loop_2 (ignore=3Dignore@entry=3D0) at keyboard.c:1107 #61 0x0000000000563593 in internal_catch (tag=3Dtag@entry=3D46176, func=3Dfunc@entry=3D0x4f15f0 , arg=3Darg@entry=3D0) at eval.c:1079 #62 0x00000000004f15c9 in command_loop () at keyboard.c:1086 #63 0x00000000004f5d57 in recursive_edit_1 () at keyboard.c:692 #64 0x00000000004f6098 in Frecursive_edit () at keyboard.c:763 #65 0x000000000041a7ce in main (argc=3D1, argv=3D0x7ffe7d9796a8) at emacs.c= :1626 In both cases, the crash occurs while Emacs is lazy-loading my desktop. I can't tell exactly what it's doing, but it appears to be about the same place each time. The crash happens most times, but at least once I started emacs and it didn't crash.=E2=80=8B=E2=80=8B --=20 http://rrt.sc3d.org --001a1142bb4a2b8bbe053e4e8bf2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Usi= ng 25.1 Ubuntu packages from=C2=A0https://launchpad.net/~adrozdoff

Core was generated by `/home/rrt/.local/bin/emacs'.<= /div>
Program terminated with signal SIGABRT, A= borted.
#0 =C2=A00x00007fe0d911f2a9 in ra= ise (sig=3Dsig@entry=3D6) at ../sysdeps/unix/sysv/linux/pt-raise.c:35
=
35 ../sysdeps/unix/sysv/linux/pt-raise.c: No such= file or directory.
[Current thread is 1 = (Thread 0x7fe0e00bab00 (LWP 16170))]
(gdb= ) where
#0 =C2=A00x00007fe0d911f2a9 in ra= ise (sig=3Dsig@entry=3D6) at ../sysdeps/unix/sysv/linux/pt-raise.c:35
=
#1 =C2=A00x00000000004ef104 in terminate_due_t= o_signal (sig=3Dsig@entry=3D6, backtrace_limit=3Dbacktrace_limit@entry=3D40= ) at emacs.c:381
#2 =C2=A00x0000000000508= 383 in emacs_abort () at sysdep.c:2247
#3= =C2=A00x0000000000563540 in Fsignal (error_symbol=3Derror_symbol@entry=3D2= 8656, data=3D101381475) at eval.c:1478
#4= =C2=A00x0000000000563549 in xsignal (error_symbol=3Derror_symbol@entry=3D2= 8656, data=3D<optimised out>) at eval.c:1577
#5 =C2=A00x0000000000563577 in xsignal1 (error_symbol=3Derror_sym= bol@entry=3D28656, arg=3D<optimised out>) at eval.c:1592
#6 =C2=A00x00000000005330db in compile_pattern (posix= =3D<optimised out>, translate=3D0, pattern=3D<optimised out>, c= p=3D0xb90db8 <searchbufs+1080>) at search.c:154
#7 =C2=A00x00000000005330db in compile_pattern (pattern=3Dpatt= ern@entry=3D52039844, regp=3Dregp@entry=3D0x0, translate=3Dtranslate@entry= =3D0, posix=3Dposix@entry=3Dfalse, multibyte=3D<optimised out>) at se= arch.c:237
#8 =C2=A00x00000000005352a1 in= fast_string_match_internal (regexp=3Dregexp@entry=3D52039844, string=3Dstr= ing@entry=3D91929188, table=3Dtable@entry=3D0) at search.c:471
#9 =C2=A00x000000000051cf51 in Ffind_file_name_handle= r (string=3D91929188, regexp=3D52039844) at lisp.h:4010
#10 0x000000000051cf51 in Ffind_file_name_handler (filename= =3Dfilename@entry=3D91929188, operation=3Doperation@entry=3D19872)
=C2=A0 =C2=A0 at fileio.c:292
#11 0x000000000051e460 in Fexpand_file_name (name=3D91929188= , default_directory=3Ddefault_directory@entry=3D0) at fileio.c:809
#12 0x000000000052425d in Fdo_auto_save (no_messa= ge=3D<optimised out>,=C2=A0
=C2=A0 = =C2=A0 no_message@entry=3D44448, current_only=3Dcurrent_only@entry=3D0) at = fileio.c:5521
#13 0x00000000004eef20 in s= hut_down_emacs (sig=3Dsig@entry=3D11, stuff=3Dstuff@entry=3D0) at emacs.c:2= 000
#14 0x00000000004ef0d5 in terminate_d= ue_to_signal (sig=3Dsig@entry=3D11, backtrace_limit=3Dbacktrace_limit@entry= =3D40) at emacs.c:365
#15 0x0000000000506= fce in handle_fatal_signal (sig=3Dsig@entry=3D11) at sysdep.c:1601
#16 0x00000000005071f3 in deliver_thread_signal (= sig=3Dsig@entry=3D11, handler=3D0x506fc0 <handle_fatal_signal>) at sy= sdep.c:1575
#17 0x000000000050725f in han= dle_sigsegv (sig=3D11) at sysdep.c:1613
#= 18 0x000000000050725f in handle_sigsegv (sig=3D11, siginfo=3D<optimised = out>, arg=3D<optimised out>) at sysdep.c:1695
#19 0x00007fe0d911f3d0 in <signal handler called> () at= /lib/x86_64-linux-gnu/libpthread.so.0
#2= 0 0x000000000054a8e9 in mark_object (arg=3D<optimised out>) at alloc.= c:6446
#21 0x000000000054a9cb in mark_obj= ect (arg=3D<optimised out>) at alloc.c:6539
#22 0x000000000054a9cb in mark_object (arg=3D<optimised out>= ) at alloc.c:6539
#23 0x000000000054b20c = in Fgarbage_collect (end=3D0x7fff0376df88) at alloc.c:5745
#24 0x000000000054b20c in Fgarbage_collect () at alloc.c= :5979
#25 0x000000000059979e in exec_byte= _code () at lisp.h:4656
#26 0x00000000005= 9979e in exec_byte_code (bytestr=3D<optimised out>, vector=3D<opti= mised out>, maxdepth=3D<optimised out>, args_template=3Dargs_templ= ate@entry=3D0, nargs=3Dnargs@entry=3D0, args=3D<optimised out>, args@= entry=3D0x0) at bytecode.c:714
#27 0x0000= 00000056283f in funcall_lambda (fun=3D78975333, nargs=3Dnargs@entry=3D1, ar= g_vector=3Darg_vector@entry=3D0x7fff0376e300)
=C2=A0 =C2=A0 at eval.c:2921
#28 0x0= 000000000562c3b in Ffuncall (nargs=3D2, args=3Dargs@entry=3D0x7fff0376e2f8)= at eval.c:2754
#29 0x00000000005975d3 in= exec_byte_code (bytestr=3D<optimised out>, vector=3D<optimised ou= t>, maxdepth=3D<optimised out>, args_template=3Dargs_template@entr= y=3D0, nargs=3Dnargs@entry=3D0, args=3D<optimised out>, args@entry=3D= 0x0) at bytecode.c:880
#30 0x000000000056= 283f in funcall_lambda (fun=3D78974597, nargs=3Dnargs@entry=3D2, arg_vector= =3Darg_vector@entry=3D0x7fff0376e520)
=C2= =A0 =C2=A0 at eval.c:2921
#31 0x000000000= 0562c3b in Ffuncall (nargs=3D3, args=3Dargs@entry=3D0x7fff0376e518) at eval= .c:2754
#32 0x00000000005975d3 in exec_by= te_code (bytestr=3D<optimised out>, vector=3D<optimised out>, m= axdepth=3D<optimised out>, args_template=3Dargs_template@entry=3D0, n= args=3Dnargs@entry=3D0, args=3D<optimised out>, args@entry=3D0x0) at = bytecode.c:880
#33 0x000000000056283f in = funcall_lambda (fun=3D78926773, nargs=3Dnargs@entry=3D1, arg_vector=3Darg_v= ector@entry=3D0x7fff0376e740)
=C2=A0 =C2= =A0 at eval.c:2921
#34 0x0000000000562c3b= in Ffuncall (nargs=3D2, args=3Dargs@entry=3D0x7fff0376e738) at eval.c:2754=
#35 0x00000000005975d3 in exec_byte_code= (bytestr=3D<optimised out>, vector=3D<optimised out>, maxdepth= =3D<optimised out>, args_template=3Dargs_template@entry=3D0, nargs=3D= nargs@entry=3D0, args=3D<optimised out>, args@entry=3D0x0) at bytecod= e.c:880
#36 0x000000000056283f in funcall= _lambda (fun=3D78925797, nargs=3Dnargs@entry=3D2, arg_vector=3Darg_vector@e= ntry=3D0x7fff0376e958)
=C2=A0 =C2=A0 at e= val.c:2921
#37 0x0000000000562c3b in Ffun= call (nargs=3Dnargs@entry=3D3, args=3D0x7fff0376e950) at eval.c:2754
<= div class=3D"gmail_default">#38 0x0000000000564020 in Fapply (nargs=3Dnargs= @entry=3D2, args=3Dargs@entry=3D0x7fff0376ea10) at eval.c:2321
#39 0x000000000056425c in apply1 (fn=3D56303360, arg= =3D<optimised out>) at eval.c:2537
= #40 0x000000000056163e in internal_condition_case_1 (bfun=3Dbfun@entry=3D0x= 59b3f0 <read_process_output_call>, arg=3D103083523, handlers=3Dhandle= rs@entry=3D19056, hfun=3Dhfun@entry=3D0x59b370 <read_process_output_erro= r_handler>) at eval.c:1333
#41 0x00000= 0000059af2d in read_process_output (coding=3D0x53b3920, nbytes=3D652, chars= =3D0x7fff0376eaa0 "Unescaped left brace in regex is deprecated, passed= through in regex; marked by <-- HERE in m/\\\\begin{ <-- HERE tex}(.= *?)\\\\end{tex}/ at /usr/bin/texify line 521.\nUnescaped left brace in rege= x is depre"..., p=3D0x287) at process.c:5440
#42 0x000000000059af2d in read_process_output (proc=3Dproc@entry= =3D86121909, channel=3D<optimised out>) at process.c:5351
#43 0x000000000059cd88 in status_notify (deleting_pr= ocess=3Ddeleting_process@entry=3D0x0, wait_proc=3Dwait_proc@entry=3D0x0)
=C2=A0 =C2=A0 at process.c:6655
#44 0x00000000005a37ae in wait_reading_process_outpu= t (time_limit=3D<optimised out>, nsecs=3D<optimised out>, read_= kbd=3Dread_kbd@entry=3D-1, do_display=3Ddo_display@entry=3Dtrue, wait_for_c= ell=3Dwait_for_cell@entry=3D0, wait_proc=3Dwait_proc@entry=3D0x0, just_wait= _proc=3D0) at process.c:4663
#45 0x000000= 00004fa0b4 in read_char (end_time=3D0x7fff037706f0, used_mouse_menu=3D0x0, = kbp=3D<synthetic pointer>)
=C2=A0 = =C2=A0 at keyboard.c:3798
#46 0x000000000= 04fa0b4 in read_char (used_mouse_menu=3D<optimised out>, local_getcjm= p=3D<optimised out>, end_time=3D<optimised out>) at keyboard.c:= 2148
#47 0x00000000004fa0b4 in read_char = (used_mouse_menu=3D<optimised out>, prev_event=3D<optimised out>= ;, local_getcjmp=3D<optimised out>, end_time=3D<optimised out>)= at keyboard.c:2211
#48 0x00000000004fa0b= 4 in read_char (commandflag=3Dcommandflag@entry=3D0, map=3Dmap@entry=3D0, p= rev_event=3Dprev_event@entry=3D0, used_mouse_menu=3Dused_mouse_menu@entry= =3D0x0, end_time=3D0x7fff037706f0) at keyboard.c:2799
---Type <return> to continue, or q <return> to qui= t---
#49 0x0000000000580baf in read_filte= red_event (no_switch_frame=3Dfalse, ascii_required=3Dfalse, error_nonascii= =3Dfalse, input_method=3D<optimised out>, seconds=3D<optimised out= >) at lread.c:614
#50 0x0000000000562e= 1f in Ffuncall (nargs=3D4, args=3Dargs@entry=3D0x7fff03770810) at eval.c:27= 00
#51 0x00000000005975d3 in exec_byte_co= de (bytestr=3D<optimised out>, vector=3D<optimised out>, maxdep= th=3D<optimised out>, args_template=3D<optimised out>, nargs=3D= nargs@entry=3D1, args=3D<optimised out>, args@entry=3D0x877d4c <pu= re+126988>) at bytecode.c:880
#52 0x00= 00000000562976 in funcall_lambda (fun=3D140733251521104, nargs=3Dnargs@entr= y=3D1, arg_vector=3D0x877d4c <pure+126988>,=C2=A0
=C2=A0 =C2=A0 arg_vector@entry=3D0x7fff037709b8) at eval.c:2= 855
#53 0x0000000000562c3b in Ffuncall (n= args=3D2, args=3Dargs@entry=3D0x7fff037709b0) at eval.c:2754
#54 0x00000000005975d3 in exec_byte_code (bytestr=3D<= ;optimised out>, vector=3D<optimised out>, maxdepth=3D<optimise= d out>, args_template=3D<optimised out>, nargs=3Dnargs@entry=3D0, = args=3D<optimised out>, args@entry=3D0x3dd8da4) at bytecode.c:880
#55 0x0000000000562976 in funcall_lambda (fu= n=3D140733251521824, nargs=3Dnargs@entry=3D0, arg_vector=3D0x3dd8da4,=C2=A0=
=C2=A0 =C2=A0 arg_vector@entry=3D0x7fff0= 3770c98) at eval.c:2855
#56 0x00000000005= 62c3b in Ffuncall (nargs=3Dnargs@entry=3D1, args=3Dargs@entry=3D0x7fff03770= c90) at eval.c:2754
#57 0x00000000005641b= c in Fapply (nargs=3D2, args=3D0x7fff03770c90) at eval.c:2274
#58 0x0000000000562d41 in Ffuncall (nargs=3D3, args=3D= args@entry=3D0x7fff03770c88) at eval.c:2673
#59 0x00000000005975d3 in exec_byte_code (bytestr=3D<optimised out>= ;, vector=3D<optimised out>, maxdepth=3D<optimised out>, args_t= emplate=3Dargs_template@entry=3D0, nargs=3Dnargs@entry=3D0, args=3D<opti= mised out>, args@entry=3D0x0) at bytecode.c:880
#60 0x000000000056283f in funcall_lambda (fun=3D10146693, nargs= =3Dnargs@entry=3D1, arg_vector=3Darg_vector@entry=3D0x7fff03770ea8)
=C2=A0 =C2=A0 at eval.c:2921
#61 0x0000000000562c3b in Ffuncall (nargs=3Dnargs@entry=3D2,= args=3Dargs@entry=3D0x7fff03770ea0) at eval.c:2754
#62 0x0000000000562f3a in call1 (fn=3Dfn@entry=3D45264, arg1=3Da= rg1@entry=3D80505365) at eval.c:2552
#63 = 0x00000000004f49c8 in timer_check (idle_timers=3D<optimised out>, tim= ers=3D<optimised out>) at keyboard.c:4427
#64 0x00000000004f49c8 in timer_check () at keyboard.c:4489
#65 0x00000000004f4d89 in readable_events (flags= =3Dflags@entry=3D1) at keyboard.c:3328
#6= 6 0x00000000004f6608 in get_input_pending (flags=3Dflags@entry=3D1) at keyb= oard.c:6725
#67 0x00000000004f8d78 in det= ect_input_pending_run_timers (do_display=3Ddo_display@entry=3Dtrue) at keyb= oard.c:9862
#68 0x00000000005a2abb in wai= t_reading_process_output (time_limit=3Dtime_limit@entry=3D30, nsecs=3Dnsecs= @entry=3D0, read_kbd=3Dread_kbd@entry=3D-1, do_display=3Ddo_display@entry= =3Dtrue, wait_for_cell=3Dwait_for_cell@entry=3D0, wait_proc=3Dwait_proc@ent= ry=3D0x0, just_wait_proc=3D0) at process.c:4958
#69 0x0000000000422e12 in sit_for (timeout=3D<optimised out>, = reading=3Dreading@entry=3Dtrue, display_option=3Ddisplay_option@entry=3D1) = at dispnew.c:5762
#70 0x00000000004fb273 = in read_char (commandflag=3Dcommandflag@entry=3D1, map=3Dmap@entry=3D943224= 51, prev_event=3D0, used_mouse_menu=3Dused_mouse_menu@entry=3D0x7fff03771b4= b, end_time=3Dend_time@entry=3D0x0) at keyboard.c:2714
#71 0x00000000004fbeda in read_key_sequence (keybuf=3Dkeybuf@= entry=3D0x7fff03771c20, prompt=3Dprompt@entry=3D0, dont_downcase_last=3Ddon= t_downcase_last@entry=3Dfalse, can_return_switch_frame=3Dcan_return_switch_= frame@entry=3Dtrue, fix_current_buffer=3Dfix_current_buffer@entry=3Dtrue, p= revent_redisplay=3Dprevent_redisplay@entry=3Dfalse, bufsize=3D30) at keyboa= rd.c:9063
#72 0x00000000004fdb26 in comma= nd_loop_1 () at keyboard.c:1365
#73 0x000= 00000005615b2 in internal_condition_case (bfun=3Dbfun@entry=3D0x4fd920 <= command_loop_1>, handlers=3Dhandlers@entry=3D19056, hfun=3Dhfun@entry=3D= 0x4f4080 <cmd_error>) at eval.c:1309
#74 0x00000000004ef54c in command_loop_2 (ignore=3Dignore@entry=3D0) at k= eyboard.c:1107
#75 0x0000000000561553 in = internal_catch (tag=3Dtag@entry=3D45840, func=3Dfunc@entry=3D0x4ef530 <c= ommand_loop_2>, arg=3Darg@entry=3D0)
= =C2=A0 =C2=A0 at eval.c:1074
#76 0x000000= 00004ef509 in command_loop () at keyboard.c:1086
#77 0x00000000004f3c77 in recursive_edit_1 () at keyboard.c:692
#78 0x00000000004f3fb8 in Frecursive_edit ()= at keyboard.c:763
#79 0x0000000000418dfe= in main (argc=3D1, argv=3D0x7fff03771fa8) at emacs.c:1626
(gdb)

=E2=80=8BI tried =E2=80=8Bbuilding the = current emacs-25 branch with=C2=A0./configure --with-xwidgets --with-cairo = --with-modules, I get a different crash:

Program terminated with signal SIGSEGV, Segmentation fau= lt.
#0 =C2=A00x00007f1fd486a2a9 in raise = (sig=3Dsig@entry=3D11) at ../sysdeps/unix/sysv/linux/pt-raise.c:35
35 ../sysdeps/unix/sysv/linux/pt-raise.c: No such file= or directory.
[Current thread is 1 (Thre= ad 0x7f1fdd77ab00 (LWP 2411))]
(gdb) wher= e
#0 =C2=A00x00007f1fd486a2a9 in raise (s= ig=3Dsig@entry=3D11) at ../sysdeps/unix/sysv/linux/pt-raise.c:35
#1 =C2=A00x00000000004f11c4 in terminate_due_to_sig= nal (sig=3Dsig@entry=3D11, backtrace_limit=3Dbacktrace_limit@entry=3D40) at= emacs.c:381
#2 =C2=A00x000000000050901e = in handle_fatal_signal (sig=3Dsig@entry=3D11) at sysdep.c:1601
#3 =C2=A00x0000000000509243 in deliver_thread_signal = (sig=3Dsig@entry=3D11, handler=3D0x509010 <handle_fatal_signal>) at s= ysdep.c:1575
#4 =C2=A00x00000000005092af = in handle_sigsegv (sig=3D11) at sysdep.c:1613
#5 =C2=A00x00000000005092af in handle_sigsegv (sig=3D11, siginfo=3D<= ;optimised out>, arg=3D<optimised out>) at sysdep.c:1695
#6 =C2=A00x00007f1fd486a3d0 in <signal handler = called> () at /lib/x86_64-linux-gnu/libpthread.so.0
#7 =C2=A00x000000000056dd24 in sxhash (y=3D<error reading = variable: Cannot access memory at address 0x0>, x=3D0) at lisp.h:2025
#8 =C2=A00x000000000056dd24 in sxhash (len= =3D<optimised out>, ptr=3D<optimised out>) at fns.c:4246
<= div class=3D"gmail_default">#9 =C2=A00x000000000056dd24 in sxhash (len=3D&l= t;optimised out>, ptr=3D<optimised out>) at fns.c:4258
#10 0x000000000056dd24 in sxhash (obj=3D<optimise= d out>, depth=3Ddepth@entry=3D1) at fns.c:4371
#11 0x000000000056dd8e in sxhash (depth=3D1, obj=3D<optimised o= ut>) at fns.c:4296
#12 0x000000000056d= d8e in sxhash (depth=3D0, list=3D12657603) at fns.c:4298
#13 0x000000000056dd8e in sxhash (obj=3D<optimised out&g= t;, depth=3D0) at fns.c:4391
#14 0x000000= 00005700f1 in hash_lookup (h=3Dh@entry=3D0x123d968, key=3Dkey@entry=3D12657= 603, hash=3Dhash@entry=3D0x0) at fns.c:3944
#15 0x00000000005701c6 in Fgethash (key=3Dkey@entry=3D12657603, table=3D= 19126637, dflt=3Ddflt@entry=3D0) at fns.c:4621
#16 0x00000000005c4462 in ftfont_lookup_cache (key=3D12657603, cache_= for=3Dcache_for@entry=3DFTFONT_CACHE_FOR_FACE) at ftfont.c:375
#17 0x00000000005c557e in ftfont_close (font=3D0x1339= 9f0) at ftfont.c:1329
#18 0x0000000000549= 64d in sweep_vectors () at alloc.c:3219
#= 19 0x000000000054d747 in Fgarbage_collect () at alloc.c:6981
#20 0x000000000054d747 in Fgarbage_collect (end=3D0x7ff= e7d9773f8) at alloc.c:5795
#21 0x00000000= 0054d747 in Fgarbage_collect () at alloc.c:5979
#22 0x0000000000564b54 in Ffuncall () at lisp.h:4656
#23 0x0000000000564b54 in Ffuncall (nargs=3Dnargs@entry= =3D2, args=3Dargs@entry=3D0x7ffe7d9775c0) at eval.c:2648
#24 0x0000000000564f7a in call1 (fn=3Dfn@entry=3D21648, arg= 1=3Darg1@entry=3D71809572) at eval.c:2557
#25 0x0000000000588064 in readevalloop (readcharfun=3Dreadcharfun@entry=3D= 24384, stream=3Dstream@entry=3D0x447bd50, sourcename=3Dsourcename@entry=3D7= 1809572, printflag=3Dprintflag@entry=3Dfalse, unibyte=3Dunibyte@entry=3D0, = readfun=3Dreadfun@entry=3D0, start=3D0, end=3D0)
=C2=A0 =C2=A0 at lread.c:1830
#26= 0x000000000058874c in Fload (file=3D9181396, noerror=3Dnoerror@entry=3D0, = nomessage=3Dnomessage@entry=3D44784, nosuffix=3Dnosuffix@entry=3D0, must_su= ffix=3D<optimised out>, must_suffix@entry=3D44784) at lread.c:1335
#27 0x000000000056658f in Fautoload_do_load= (fundef=3D9508451, funname=3D4814608, macro_only=3D0) at eval.c:1962
=
#28 0x0000000000564e5f in Ffuncall (nargs=3D3,= args=3Dargs@entry=3D0x7ffe7d977940) at eval.c:2705
#29 0x000000000059c8d3 in exec_byte_code (bytestr=3D<optimise= d out>, vector=3D<optimised out>, maxdepth=3D<optimised out>= , args_template=3D<optimised out>, nargs=3Dnargs@entry=3D1, args=3D&l= t;optimised out>, args@entry=3D0x4131664) at bytecode.c:880
#30 0x00000000005649b6 in funcall_lambda (fun=3D14073= 1005500480, nargs=3Dnargs@entry=3D1, arg_vector=3D0x4131664,=C2=A0
=C2=A0 =C2=A0 arg_vector@entry=3D0x7ffe7d977b98) = at eval.c:2860
#31 0x0000000000564c7b in = Ffuncall (nargs=3D2, args=3Dargs@entry=3D0x7ffe7d977b90) at eval.c:2759
#32 0x000000000059c8d3 in exec_byte_code (by= testr=3D<optimised out>, vector=3D<optimised out>, maxdepth=3D&= lt;optimised out>, args_template=3D<optimised out>, nargs=3Dnargs@= entry=3D10, args=3D<optimised out>, args@entry=3D0x4130fc4) at byteco= de.c:880
#33 0x00000000005649b6 in funcal= l_lambda (fun=3D140731005501328, nargs=3Dnargs@entry=3D10, arg_vector=3D0x4= 130fc4,=C2=A0
=C2=A0 =C2=A0 arg_vector@en= try=3D0x7ffe7d977d58) at eval.c:2860
#34 = 0x0000000000564c7b in Ffuncall (nargs=3Dnargs@entry=3D11, args=3D0x7ffe7d97= 7d50) at eval.c:2759
#35 0x00000000005660= 60 in Fapply (nargs=3D<optimised out>, args=3D0x7ffe7d977f10) at eval= .c:2326
#36 0x0000000000564d81 in Ffuncal= l (nargs=3D3, args=3Dargs@entry=3D0x7ffe7d977f08) at eval.c:2678
#37 0x000000000059c8d3 in exec_byte_code (bytestr= =3D<optimised out>, vector=3D<optimised out>, maxdepth=3D<op= timised out>, args_template=3D<optimised out>, nargs=3Dnargs@entry= =3D0, args=3D<optimised out>, args@entry=3D0x41306c4) at bytecode.c:8= 80
#38 0x00000000005649b6 in funcall_lamb= da (fun=3D140731005501776, nargs=3Dnargs@entry=3D0, arg_vector=3D0x41306c4,= =C2=A0
=C2=A0 =C2=A0 arg_vector@entry=3D0= x7ffe7d9780c0) at eval.c:2860
#39 0x00000= 00000564c7b in Ffuncall (nargs=3D1, args=3Dargs@entry=3D0x7ffe7d9780b8) at = eval.c:2759
#40 0x000000000059c8d3 in exe= c_byte_code (bytestr=3D<optimised out>, vector=3D<optimised out>= ;, maxdepth=3D<optimised out>, args_template=3D<optimised out>,= nargs=3Dnargs@entry=3D0, args=3D<optimised out>, args@entry=3D0x4130= 3f4) at bytecode.c:880
#41 0x000000000056= 49b6 in funcall_lambda (fun=3D140731005502496, nargs=3Dnargs@entry=3D0, arg= _vector=3D0x41303f4,=C2=A0
=C2=A0 =C2=A0 = arg_vector@entry=3D0x7ffe7d978398) at eval.c:2860
#42 0x0000000000564c7b in Ffuncall (nargs=3Dnargs@entry=3D1, args= =3Dargs@entry=3D0x7ffe7d978390) at eval.c:2759
#43 0x00000000005661fc in Fapply (nargs=3D2, args=3D0x7ffe7d978390) a= t eval.c:2279
#44 0x0000000000564d81 in F= funcall (nargs=3D3, args=3Dargs@entry=3D0x7ffe7d978388) at eval.c:2678
#45 0x000000000059c8d3 in exec_byte_code (byt= estr=3D<optimised out>, vector=3D<optimised out>, maxdepth=3D&l= t;optimised out>, args_template=3Dargs_template@entry=3D0, nargs=3Dnargs= @entry=3D0, args=3D<optimised out>, args@entry=3D0x0) at bytecode.c:8= 80
#46 0x000000000056487f in funcall_lamb= da (fun=3D10158805, nargs=3Dnargs@entry=3D1, arg_vector=3Darg_vector@entry= =3D0x7ffe7d9785a8)
=C2=A0 =C2=A0 at eval.= c:2926
#47 0x0000000000564c7b in Ffuncall= (nargs=3Dnargs@entry=3D2, args=3Dargs@entry=3D0x7ffe7d9785a0) at eval.c:27= 59
#48 0x0000000000564f7a in call1 (fn=3D= fn@entry=3D45600, arg1=3Darg1@entry=3D89586453) at eval.c:2557
#49 0x00000000004f6a98 in timer_check (idle_timers=3D= <optimised out>, timers=3D<optimised out>) at keyboard.c:4427
#50 0x00000000004f6a98 in timer_check () a= t keyboard.c:4489
#51 0x00000000004f6e59 = in readable_events (flags=3Dflags@entry=3D1) at keyboard.c:3328
#52 0x00000000004f86d8 in get_input_pending (flags= =3Dflags@entry=3D1) at keyboard.c:6725
#5= 3 0x00000000004fadb8 in detect_input_pending_run_timers (do_display=3Ddo_di= splay@entry=3Dtrue) at keyboard.c:9862
#5= 4 0x00000000005a7d9b in wait_reading_process_output (time_limit=3Dtime_limi= t@entry=3D30, nsecs=3Dnsecs@entry=3D0, read_kbd=3Dread_kbd@entry=3D-1, do_d= isplay=3Ddo_display@entry=3Dtrue, wait_for_cell=3Dwait_for_cell@entry=3D0, = wait_proc=3Dwait_proc@entry=3D0x0, just_wait_proc=3D0) at process.c:4958
#55 0x0000000000423b12 in sit_for (timeout= =3D<optimised out>, reading=3Dreading@entry=3Dtrue, display_option=3D= display_option@entry=3D1) at dispnew.c:5762
---Type <return> to continue, or q <return> to quit---
=
#56 0x00000000004fd092 in read_char (commandfl= ag=3Dcommandflag@entry=3D1, map=3Dmap@entry=3D40733251, prev_event=3D0, use= d_mouse_menu=3Dused_mouse_menu@entry=3D0x7ffe7d97924b, end_time=3Dend_time@= entry=3D0x0) at keyboard.c:2714
#57 0x000= 00000004fdf2a in read_key_sequence (keybuf=3Dkeybuf@entry=3D0x7ffe7d979320,= prompt=3Dprompt@entry=3D0, dont_downcase_last=3Ddont_downcase_last@entry= =3Dfalse, can_return_switch_frame=3Dcan_return_switch_frame@entry=3Dtrue, f= ix_current_buffer=3Dfix_current_buffer@entry=3Dtrue, prevent_redisplay=3Dpr= event_redisplay@entry=3Dfalse, bufsize=3D30) at keyboard.c:9063
#58 0x00000000004ffb76 in command_loop_1 () at keybo= ard.c:1365
#59 0x00000000005635f2 in inte= rnal_condition_case (bfun=3Dbfun@entry=3D0x4ff970 <command_loop_1>, h= andlers=3Dhandlers@entry=3D18912, hfun=3Dhfun@entry=3D0x4f6160 <cmd_erro= r>) at eval.c:1314
#60 0x00000000004f1= 60c in command_loop_2 (ignore=3Dignore@entry=3D0) at keyboard.c:1107
<= div class=3D"gmail_default">#61 0x0000000000563593 in internal_catch (tag= =3Dtag@entry=3D46176, func=3Dfunc@entry=3D0x4f15f0 <command_loop_2>, = arg=3Darg@entry=3D0)
=C2=A0 =C2=A0 at eva= l.c:1079
#62 0x00000000004f15c9 in comman= d_loop () at keyboard.c:1086
#63 0x000000= 00004f5d57 in recursive_edit_1 () at keyboard.c:692
#64 0x00000000004f6098 in Frecursive_edit () at keyboard.c:763
#65 0x000000000041a7ce in main (argc=3D1, = argv=3D0x7ffe7d9796a8) at emacs.c:1626
=
In both cases, the crash occurs wh= ile Emacs is lazy-loading my desktop. I can't tell exactly what it'= s doing, but it appears to be about the same place each time.

The crash h= appens most times, but at least once I started emacs and it didn't cras= h.=E2=80=8B=E2=80=8B

--
http= ://rrt.sc3d.org
--001a1142bb4a2b8bbe053e4e8bf2-- From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 08 01:54:05 2016 Received: (at 24640) by debbugs.gnu.org; 8 Oct 2016 05:54:05 +0000 Received: from localhost ([127.0.0.1]:48220 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bskaD-0003Kc-7e for submit@debbugs.gnu.org; Sat, 08 Oct 2016 01:54:05 -0400 Received: from eggs.gnu.org ([208.118.235.92]:56177) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bskaB-0003K6-Jk for 24640@debbugs.gnu.org; Sat, 08 Oct 2016 01:54:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bska1-000148-FY for 24640@debbugs.gnu.org; Sat, 08 Oct 2016 01:53:58 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41003) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bska1-00013n-CA; Sat, 08 Oct 2016 01:53:53 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2327 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bskZy-0008Cc-P4; Sat, 08 Oct 2016 01:53:51 -0400 Date: Sat, 08 Oct 2016 08:53:58 +0300 Message-Id: <83int3idxl.fsf@gnu.org> From: Eli Zaretskii To: Reuben Thomas In-reply-to: (message from Reuben Thomas on Sat, 8 Oct 2016 00:12:26 +0100) Subject: Re: bug#24640: Crashes in 25.1 References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.7 (-------) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.7 (-------) > From: Reuben Thomas > Date: Sat, 8 Oct 2016 00:12:26 +0100 > > In both cases, the crash occurs while Emacs is lazy-loading my desktop. What does "lazy-loading" mean in this context? > I can't tell exactly what it's doing, but it appears to be about the > same place each time. If you run Emacs under GDB, and source the src/.gdbinit file provided in the source tree, the backtrace command will automatically try to produce a Lisp-level backtrace as well. That could be helpful. This string in the 1st backtrace you show could help figure out what form was being evaluated: #41 0x000000000059af2d in read_process_output (coding=0x53b3920, nbytes=652, chars=0x7fff0376eaa0 "Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\\\\begin{ <-- HERE tex}(.*?)\\\\end{tex}/ at /usr/bin/texify line 521.\nUnescaped left brace in regex is depre"..., p=0x287) at process.c:5440 The SIGSEGV happens here: nextsym: if (ptr->gcmarkbit) <<<<<<<<<<<<<<<<<< break; So the value of 'ptr' there (frame 20 in the 1st backtrace) is of interest. > ​I tried ​building the current emacs-25 branch with ./configure --with-xwidgets --with-cairo --with-modules, I get > a different crash: > [...] > #6 0x00007f1fd486a3d0 in () at /lib/x86_64-linux-gnu/libpthread.so.0 > #7 0x000000000056dd24 in sxhash (y=, > x=0) at lisp.h:2025 > #8 0x000000000056dd24 in sxhash (len=, ptr=) at fns.c:4246 This part of the backtrace, right before the SIGSEGV, makes no sense: the code at line 2025 of lisp.h does bitwise operations on scalar values, and y is one such scalar value. Please build without optimizations, that would make the backtraces more reliable and detailed. Was the Ubuntu package also compiled with Cairo? (I cannot figure out the build details from the URL you provided, and your report lacks the details collected by "M-x report-emacs-bug".) If so, please try building without Cairo, as that option is not yet recommended for prime time. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 08 09:28:58 2016 Received: (at 24640) by debbugs.gnu.org; 8 Oct 2016 13:28:58 +0000 Received: from localhost ([127.0.0.1]:48371 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bsrgQ-0000hs-4d for submit@debbugs.gnu.org; Sat, 08 Oct 2016 09:28:58 -0400 Received: from mail-lf0-f50.google.com ([209.85.215.50]:34415) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bsrgN-0000hd-Hw for 24640@debbugs.gnu.org; Sat, 08 Oct 2016 09:28:56 -0400 Received: by mail-lf0-f50.google.com with SMTP id b81so58991643lfe.1 for <24640@debbugs.gnu.org>; Sat, 08 Oct 2016 06:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jNC0n/P8t/y5YgUjNqv1lGn2cASR5dJyCliIlL36uOI=; b=UKGUoimQL9d35jml7o3ffMlj7gLplPT7Y+kNAxd6BnhF2yc+bklkHWh/6MOckKoaN9 q+7luu77DcGV+DpylWBUF6EPVL3tJYivdOGRiTjTiRGHhZ0F8Z7IM2MSzwfatcX0ZOtJ gtqfi14KFZNgxaDCjSc7lnafT9AJ7YrIX5hEc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jNC0n/P8t/y5YgUjNqv1lGn2cASR5dJyCliIlL36uOI=; b=bNHhopFRG78OYiRbKUEVJKnv7W4diaIZ9ULavT9N2ojHO1mGxsIu4O3yUAKk8KkGiq LdnId0gQiQDI5uKwwK0GwQ07BVW+FWRiqqylXRarahnQ8yLWNOOL24xePtbdcAckf+zt sQ+4eX5wyis0VmQUkcKhjAwSo01MAhfKjL+3In9ycZUXlJuqhd3dEqcMHBMI96EQW+bm GLon1ibOSnxec+8MCUqr/u6HZAkcZIxGxFdunAtWCO5SQUwUHL3eqZDz0eC0ITG6vh2I j5hfYzfw0jQ7OBykvmXLaqoxpe74/IXm+2q+0qmaB/zRDwyljItmpTAqrR2GxiRIR5lA vOxw== X-Gm-Message-State: AA6/9RnayWyg71XXq3HBPMkTeEbZ52i4pqAKewNSPmJzos8PQDv+AUvFc71WzhmnRoHANhlA90YZl7RzXuaQtgh3 X-Received: by 10.46.71.69 with SMTP id u66mr4473346lja.74.1475933329551; Sat, 08 Oct 2016 06:28:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.66.211 with HTTP; Sat, 8 Oct 2016 06:28:48 -0700 (PDT) In-Reply-To: <83int3idxl.fsf@gnu.org> References: <83int3idxl.fsf@gnu.org> From: Reuben Thomas Date: Sat, 8 Oct 2016 14:28:48 +0100 Message-ID: Subject: Re: bug#24640: Crashes in 25.1 To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a114013b4d20718053e5a810a X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) --001a114013b4d20718053e5a810a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8 October 2016 at 06:53, Eli Zaretskii wrote: > > From: Reuben Thomas > > Date: Sat, 8 Oct 2016 00:12:26 +0100 > > > > In both cases, the crash occurs while Emacs is lazy-loading my desktop. > > What does "lazy-loading" mean in this context? > =E2=80=8BWhen desktop(.el) is run at startup, it loads a fixed number of bu= ffers immediately, then lazy-loads the rest. It's during the lazy loading that the crash happens.=E2=80=8B > > I can't tell exactly what it's doing, but it appears to be about the > > same place each time. > > If you run Emacs under GDB, and source the src/.gdbinit file provided > in the source tree, the backtrace command will automatically try to > produce a Lisp-level backtrace as well. That could be helpful. > =E2=80=8BFortunately(!) it is still crashing the same way. Here you go:=E2= =80=8B [New Thread 0x7fffe5960700 (LWP 19613)] [New Thread 0x7fffe4cf1700 (LWP 19614)] [New Thread 0x7fffdfd2d700 (LWP 19615)] Thread 1 "emacs25" received signal SIGSEGV, Segmentation fault. mark_object (arg=3D) at alloc.c:6488 6488 alloc.c: No such file or directory. (gdb) bt 1 #0 0x000000000054aa44 in mark_object (arg=3D) at alloc.c:64= 88 #1 0x000000000054a8fe in mark_object (arg=3D) at alloc.c:64= 52 Lisp Backtrace: "Automatic GC" (0x0) "process-file" (0xffff9ea0) "apply" (0xffff9e98) "vc-git--call" (0xffffa188) "apply" (0xffffa180) "vc-git--out-ok" (0xffffa318) "apply" (0xffffa488) "vc-git--run-command-string" (0xffffa638) "vc-git--symbolic-ref" (0xffffa800) "vc-git-mode-line-string" (0xffffab08) "apply" (0xffffab00) "vc-call-backend" (0xffffad20) "vc-mode-line" (0xffffaf60) "vc-refresh-state" (0xffffb1a8) "auto-revert-handler" (0xffffb388) "auto-revert-buffers" (0xffffb530) "auto-revert-mode" (0xffffb7b0) "desktop-create-buffer" (0xffffb948) "apply" (0xffffbb00) "desktop-lazy-create-buffer" (0xffffbcb0) "desktop-idle-create-buffers" (0xffffbf88) "apply" (0xffffbf80) "timer-event-handler" (0xffffc198)=E2=80=8B > This part of the backtrace, right before the SIGSEGV, makes no sense: > the code at line 2025 of lisp.h does bitwise operations on scalar > values, and y is one such scalar value. Please build without > optimizations, that would make the backtraces more reliable and > detailed. > =E2=80=8BFor now I'll concentrate on the Ubuntu build; I can go back to the self-build later; I've reconfigured the source tree=E2=80=8B with default o= ptions. > Was the Ubuntu package also compiled with Cairo? =E2=80=8BI had a look at the source package, and it doesn't build with --with-cairo, so no. On 8 October 2016 at 06:53, Eli Zaretskii wrote: > > From: Reuben Thomas > > Date: Sat, 8 Oct 2016 00:12:26 +0100 > > > > In both cases, the crash occurs while Emacs is lazy-loading my desktop. > > What does "lazy-loading" mean in this context? > > > I can't tell exactly what it's doing, but it appears to be about the > > same place each time. > > If you run Emacs under GDB, and source the src/.gdbinit file provided > in the source tree, the backtrace command will automatically try to > produce a Lisp-level backtrace as well. That could be helpful. > > This string in the 1st backtrace you show could help figure out what > form was being evaluated: > > #41 0x000000000059af2d in read_process_output (coding=3D0x53b3920, > nbytes=3D652, chars=3D0x7fff0376eaa0 > "Unescaped left brace in regex is deprecated, passed through in regex; > marked by <-- HERE in m/\\\\begin{ > <-- HERE tex}(.*?)\\\\end{tex}/ at /usr/bin/texify line 521.\nUnescaped > left brace in regex is depre"..., p=3D0x287) > at process.c:5440 > > The SIGSEGV happens here: > > nextsym: > if (ptr->gcmarkbit) <<<<<<<<<<<<<<<<<< > break; > > So the value of 'ptr' there (frame 20 in the 1st backtrace) is of > interest. > > > =E2=80=8BI tried =E2=80=8Bbuilding the current emacs-25 branch with ./c= onfigure > --with-xwidgets --with-cairo --with-modules, I get > > a different crash: > > [...] > > #6 0x00007f1fd486a3d0 in () at > /lib/x86_64-linux-gnu/libpthread.so.0 > > #7 0x000000000056dd24 in sxhash (y=3D access memory at address 0x0>, > > x=3D0) at lisp.h:2025 > > #8 0x000000000056dd24 in sxhash (len=3D, ptr=3D out>) at fns.c:4246 > > This part of the backtrace, right before the SIGSEGV, makes no sense: > the code at line 2025 of lisp.h does bitwise operations on scalar > values, and y is one such scalar value. Please build without > optimizations, that would make the backtraces more reliable and > detailed. > > Was the Ubuntu package also compiled with Cairo? (I cannot figure out > the build details from the URL you provided, and your report lacks the > details collected by "M-x report-emacs-bug".) If so, please try > building without Cairo, as that option is not yet recommended for > prime time. > > Thanks. > --=20 http://rrt.sc3d.org --001a114013b4d20718053e5a810a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 8 October 2016 at 06:53= , Eli Zaretskii <eliz@gnu.org> wrote:
> From: Reuben Thomas <rrt@sc3d.org>
> Date: Sat, 8 Oct 2016 00:12:26 +0100
>
> In both cases, the crash occurs while Emacs is lazy-loading my desktop= .

What does "lazy-loading" mean in this context?

=E2=80= =8BWhen desktop(.el) is run at startup, it loads a fixed number of buffers=20 immediately, then lazy-loads the rest. It's during the lazy loading tha= t the crash happens.=E2=80=8B
=C2=A0
> I can't tell exactly what it's doing, but it appears to be abo= ut the
> same place each time.

If you run Emacs under GDB, and source the src/.gdbinit file provided
in the source tree, the backtrace command will automatically try to
produce a Lisp-level backtrace as well.=C2=A0 That could be helpful.

=E2=80=8BFortunately(!) it is still crashing the same way. Here you g= o:=E2=80=8B

[New Thread 0x7fffe5960700 (LWP 19613)]
[New Thread= 0x7fffe4cf1700 (LWP 19614)]
[New Thread 0x7fffdfd2d700 (LWP 19615)]
=
Thread 1 "emacs25" received signal SIGSEGV, Segmentation faul= t.
mark_object (arg=3D<optimised out>) at alloc.c:6488
6488=C2= =A0=C2=A0=C2=A0 alloc.c: No such file or directory.
(gdb) bt 1
#0=C2= =A0 0x000000000054aa44 in mark_object (arg=3D<optimised out>) at allo= c.c:6488
#1=C2=A0 0x000000000054a8fe in mark_object (arg=3D<optimised= out>) at alloc.c:6452

Lisp Backtrace:
"Automatic GC"= ; (0x0)
"process-file" (0xffff9ea0)
"apply" (0xff= ff9e98)
"vc-git--call" (0xffffa188)
"apply" (0xff= ffa180)
"vc-git--out-ok" (0xffffa318)
"apply" (0x= ffffa488)
"vc-git--run-command-string" (0xffffa638)
"v= c-git--symbolic-ref" (0xffffa800)
"vc-git-mode-line-string&quo= t; (0xffffab08)
"apply" (0xffffab00)
"vc-call-backend&= quot; (0xffffad20)
"vc-mode-line" (0xffffaf60)
"vc-ref= resh-state" (0xffffb1a8)
"auto-revert-handler" (0xffffb38= 8)
"auto-revert-buffers" (0xffffb530)
"auto-revert-mod= e" (0xffffb7b0)
"desktop-create-buffer" (0xffffb948)
&= quot;apply" (0xffffbb00)
"desktop-lazy-create-buffer" (0x= ffffbcb0)
"desktop-idle-create-buffers" (0xffffbf88)
"= apply" (0xffffbf80)
"timer-event-handler" (0xffffc198)=E2= =80=8B
=C2=A0
This part of the backtrace, right before the SIGSEGV,= makes no sense:
the code at line 2025 of lisp.h does bitwise operations on scalar
values, and y is one such scalar value.=C2=A0 Please build without
optimizations, that would make the backtraces more reliable and
detailed.

=E2=80=8BFor now I'll concentrate on the Ubuntu build; I can go back to the=20 self-build later; I've reconfigured the source tree=E2=80=8B with defau= lt=20 options.
=C2=A0
Was the Ubuntu package also compiled with Cairo?
=E2=80=8BI had a l= ook at the source package, and it doesn't build with --with-cairo, so n= o.

On 8 October 2016 at 06:53, Eli Zaretskii <eliz@gnu.org>= ; wrote:
> From: Reuben Thomas = <rrt@sc3d.org>
> Date: Sat, 8 Oct 2016 00:12:26 +0100
>
> In both cases, the crash occurs while Emacs is lazy-loading my desktop= .

What does "lazy-loading" mean in this context?

> I can't tell exactly what it's doing, but it appears to be abo= ut the
> same place each time.

If you run Emacs under GDB, and source the src/.gdbinit file provided
in the source tree, the backtrace command will automatically try to
produce a Lisp-level backtrace as well.=C2=A0 That could be helpful.

This string in the 1st backtrace you show could help figure out what
form was being evaluated:

=C2=A0 #41 0x000000000059af2d in read_process_output (coding=3D0x53b3920, n= bytes=3D652, chars=3D0x7fff0376eaa0
=C2=A0 "Unescaped left brace in regex is deprecated, passed through in= regex; marked by <-- HERE in m/\\\\begin{
=C2=A0 <-- HERE tex}(.*?)\\\\end{tex}/ at /usr/bin/texify line 521.\nUne= scaped left brace in regex is depre"..., p=3D0x287)
=C2=A0 at process.c:5440

The SIGSEGV happens here:

=C2=A0 =C2=A0 =C2=A0 nextsym:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (ptr->gcmarkbit)=C2=A0 <<<<&l= t;<<<<<<<<<<<<<
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;

So the value of 'ptr' there (frame 20 in the 1st backtrace) is of interest.

> =E2=80=8BI tried =E2=80=8Bbuilding the current emacs-25 branch with ./= configure --with-xwidgets --with-cairo --with-modules, I get
> a different crash:
> [...]
> #6 0x00007f1fd486a3d0 in <signal handler called> () at /lib/x86_= 64-linux-gnu/libpthread.so.0
> #7 0x000000000056dd24 in sxhash (y=3D<error reading variable: Canno= t access memory at address 0x0>,
> x=3D0) at lisp.h:2025
> #8 0x000000000056dd24 in sxhash (len=3D<optimised out>, ptr=3D&l= t;optimised out>) at fns.c:4246

This part of the backtrace, right before the SIGSEGV, makes no sense:
the code at line 2025 of lisp.h does bitwise operations on scalar
values, and y is one such scalar value.=C2=A0 Please build without
optimizations, that would make the backtraces more reliable and
detailed.

Was the Ubuntu package also compiled with Cairo?=C2=A0 (I cannot figure out=
the build details from the URL you provided, and your report lacks the
details collected by "M-x report-emacs-bug".)=C2=A0 If so, please= try
building without Cairo, as that option is not yet recommended for
prime time.

Thanks.



--
http://rrt.sc3d.org
--001a114013b4d20718053e5a810a-- From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 08 09:30:49 2016 Received: (at 24640) by debbugs.gnu.org; 8 Oct 2016 13:30:49 +0000 Received: from localhost ([127.0.0.1]:48375 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bsriC-0000mH-OR for submit@debbugs.gnu.org; Sat, 08 Oct 2016 09:30:48 -0400 Received: from mail-lf0-f46.google.com ([209.85.215.46]:33646) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bsriB-0000lx-AT for 24640@debbugs.gnu.org; Sat, 08 Oct 2016 09:30:47 -0400 Received: by mail-lf0-f46.google.com with SMTP id x79so59261297lff.0 for <24640@debbugs.gnu.org>; Sat, 08 Oct 2016 06:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NG+4WeRhwljtYeNbTNHy3fLECXRec9xumTD5uY3aGJc=; b=vstR4F5Oia+X4CJcwZIXfLbAcjbICSJlEZoSsYAuTNQyQK/3/uV30IDBcGZTimWzax LxluDrKaetHvN+pyHG72kw+l8vz4qVMBaeu0n/lN+oyyk0efPnygeiRlSegQQfcnpCh7 IniunZtrYe3IhUglNN1NBJWo5i6NRlMpcY1kY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NG+4WeRhwljtYeNbTNHy3fLECXRec9xumTD5uY3aGJc=; b=F+7Rj2sKbiDR0zYBC2atXHc+TAdfvLFSpTfQLGyFYuXIK9yiCN3a3VjvTgMvbnBeE/ s1cQmjUlQ4B2erm7SO6oE95Seei2wUx0WkVHeu+qGnGnHFK7cUKOXqLxo+BmEgDrDZ4m 2qJuh/rHyKoq+Y8kEhBUZ+PuLQ0n2kJjfgsozzhHwtyhpAw9llTJKTd3mt4xXz/GnhxJ GImpq3/i/kqlMwaK6YsjQ+AO58P6uNKAV7ZI+OcyUryCg9TLlZ361N2pj3zEjU1SWBi7 VDpdfkAzxBkMvEzScI0nefGXdCnMBxUA8EblsFbzOnWyiN/Af9p43hVrTNgSt5B155LQ d3gw== X-Gm-Message-State: AA6/9Rmko3YkaDz57OYThZCi2nsMS8ihv4UH4M0yVNGdNGBRB4tnQtU7DySMVcCNH7pdAopaUAgoVeIjdGxReinJ X-Received: by 10.46.0.5 with SMTP id 5mr8535052lja.1.1475933441529; Sat, 08 Oct 2016 06:30:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.66.211 with HTTP; Sat, 8 Oct 2016 06:30:41 -0700 (PDT) In-Reply-To: <83int3idxl.fsf@gnu.org> References: <83int3idxl.fsf@gnu.org> From: Reuben Thomas Date: Sat, 8 Oct 2016 14:30:41 +0100 Message-ID: Subject: Re: bug#24640: Crashes in 25.1 To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a1142b9987eb335053e5a88f3 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a1142b9987eb335053e5a88f3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8 October 2016 at 06:53, Eli Zaretskii wrote: > > From: Reuben Thomas > > Date: Sat, 8 Oct 2016 00:12:26 +0100 > > > > In both cases, the crash occurs while Emacs is lazy-loading my desktop. > > What does "lazy-loading" mean in this context? > > > I can't tell exactly what it's doing, but it appears to be about the > > same place each time. > > If you run Emacs under GDB, and source the src/.gdbinit file provided > in the source tree, the backtrace command will automatically try to > produce a Lisp-level backtrace as well. That could be helpful. > > This string in the 1st backtrace you show could help figure out what > form was being evaluated: > > #41 0x000000000059af2d in read_process_output (coding=3D0x53b3920, > nbytes=3D652, chars=3D0x7fff0376eaa0 > "Unescaped left brace in regex is deprecated, passed through in regex; > marked by <-- HERE in m/\\\\begin{ > <-- HERE tex}(.*?)\\\\end{tex}/ at /usr/bin/texify line 521.\nUnescaped > left brace in regex is depre"..., p=3D0x287) > at process.c:5440 > > The SIGSEGV happens here: > > nextsym: > if (ptr->gcmarkbit) <<<<<<<<<<<<<<<<<< > break; > > So the value of 'ptr' there (frame 20 in the 1st backtrace) is of > interest. > =E2=80=8BThe current backtrace seems to have crashed at a different point, = and doesn't even include this line, but this time I've kept the gdb session running in case I can tell you anything else of =E2=80=8B =E2=80=8Binterest.=E2=80=8B --001a1142b9987eb335053e5a88f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 8= October 2016 at 06:53, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Reuben Thomas <rrt@sc3d.org>
> Date: Sat, 8 Oct 2016 00:12:26 +0100
>
> In both cases, the crash occurs while Emacs is lazy-loading my desktop= .

What does "lazy-loading" mean in this context?

> I can't tell exactly what it's doing, but it appears to be abo= ut the
> same place each time.

If you run Emacs under GDB, and source the src/.gdbinit file provided
in the source tree, the backtrace command will automatically try to
produce a Lisp-level backtrace as well.=C2=A0 That could be helpful.

This string in the 1st backtrace you show could help figure out what
form was being evaluated:

=C2=A0 #41 0x000000000059af2d in read_process_output (coding=3D0x53b3920, n= bytes=3D652, chars=3D0x7fff0376eaa0
=C2=A0 "Unescaped left brace in regex is deprecated, passed through in= regex; marked by <-- HERE in m/\\\\begin{
=C2=A0 <-- HERE tex}(.*?)\\\\end{tex}/ at /usr/bin/texify line 521.\nUne= scaped left brace in regex is depre"..., p=3D0x287)
=C2=A0 at process.c:5440

The SIGSEGV happens here:

=C2=A0 =C2=A0 =C2=A0 nextsym:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (ptr->gcmarkbit)=C2=A0 <<<<&l= t;<<<<<<<<<<<<<
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;

So the value of 'ptr' there (frame 20 in the 1st backtrace) is of interest.

=E2=80=8BThe current backtrace seems to have = crashed at a different point, and doesn't even include this line, but t= his time I've kept the gdb session running in case I can tell you anyth= ing else of =E2=80=8B
=C2=A0
=E2=80=8Binterest.=E2=80=8B
--001a1142b9987eb335053e5a88f3-- From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 08 10:30:35 2016 Received: (at 24640) by debbugs.gnu.org; 8 Oct 2016 14:30:35 +0000 Received: from localhost ([127.0.0.1]:48836 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bsse2-0002Oq-5b for submit@debbugs.gnu.org; Sat, 08 Oct 2016 10:30:34 -0400 Received: from eggs.gnu.org ([208.118.235.92]:58952) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bsse0-0002Od-Ji for 24640@debbugs.gnu.org; Sat, 08 Oct 2016 10:30:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bssdr-0003Ve-BE for 24640@debbugs.gnu.org; Sat, 08 Oct 2016 10:30:27 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47689) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bssdr-0003V4-82; Sat, 08 Oct 2016 10:30:23 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2794 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bssdp-0006XF-F1; Sat, 08 Oct 2016 10:30:21 -0400 Date: Sat, 08 Oct 2016 17:30:30 +0300 Message-Id: <83mviehq0p.fsf@gnu.org> From: Eli Zaretskii To: Reuben Thomas In-reply-to: (message from Reuben Thomas on Sat, 8 Oct 2016 14:30:41 +0100) Subject: Re: bug#24640: Crashes in 25.1 References: <83int3idxl.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.7 (-------) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.7 (-------) > From: Reuben Thomas > Date: Sat, 8 Oct 2016 14:30:41 +0100 > Cc: 24640@debbugs.gnu.org > > So the value of 'ptr' there (frame 20 in the 1st backtrace) is of > interest. > > ​The current backtrace seems to have crashed at a different point, and doesn't even include this line, but this > time I've kept the gdb session running in case I can tell you anything else of ​ > ​interest.​ Well, can you tell why it crashed this time? IOW, what was the immediate cause of SIGSEGV? From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 08 11:26:45 2016 Received: (at 24640) by debbugs.gnu.org; 8 Oct 2016 15:26:45 +0000 Received: from localhost ([127.0.0.1]:48874 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bstWM-0003lS-3o for submit@debbugs.gnu.org; Sat, 08 Oct 2016 11:26:45 -0400 Received: from mail-lf0-f42.google.com ([209.85.215.42]:35252) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bstWG-0003l8-SS for 24640@debbugs.gnu.org; Sat, 08 Oct 2016 11:26:40 -0400 Received: by mail-lf0-f42.google.com with SMTP id l131so60130002lfl.2 for <24640@debbugs.gnu.org>; Sat, 08 Oct 2016 08:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E4LoXhczBGtnvnd5taARTEoIOaItI61hmlnL8tWyMTg=; b=H0R1darDiiDh00WQs1/f8wy+wVnbBcpdXwW9faJcAnkAXsaMbhjGhZOJVCYjE/VRIa ToIl4AzVWHOhGlsxog7erpZkQpAPvCKSh2VAErkwb34w5Ysik5RzigRXahxD9HFvb6j0 XN3bQN2C2/6A5zzqjVKgfFkhXEPVCrzTgrEOc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=E4LoXhczBGtnvnd5taARTEoIOaItI61hmlnL8tWyMTg=; b=WhAuxU+1v5AbF2vy4uNqB13eyqMDW/gnerEKziXMPqL/pYwdKQZqV7o9khbtkxmmzR adhv3rxwgeV1S3i+b2d6c5HSpbcPWF/X7fFaijhQ0yitMvpZXVtOMJMG73n97mbHxQ4w IM2DR8gouxLz2SF65n0jshBNSxLEvOYm0M34I/GLkmvDyj0Gqq2gLTKAXPwL8RaG7IZg VRaAVucO8kjSqXZmTofkpNsQ73ZUttIiR1Jn1r7LK/BhKAH73bOapKmHiqXOhNENaT6j 9Np8Ox1PvXKLM2Ce/iDX5Rohp9sFMnYFAk4I4eM1ISNLf0GVggiTWxyIPDjZvwp7U01L Vsxw== X-Gm-Message-State: AA6/9Rm8JaFJLspfP7NJtSrbuyPINtMULVPjtgiJtCVunBPj7bpKAIzKPQGG8lAYAg2TsWe9nxdz4vjGRn2JzIcB X-Received: by 10.46.71.69 with SMTP id u66mr4573468lja.74.1475940390956; Sat, 08 Oct 2016 08:26:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.66.211 with HTTP; Sat, 8 Oct 2016 08:26:30 -0700 (PDT) In-Reply-To: <83mviehq0p.fsf@gnu.org> References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> From: Reuben Thomas Date: Sat, 8 Oct 2016 16:26:30 +0100 Message-ID: Subject: Re: bug#24640: Crashes in 25.1 To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a114013b4b689e5053e5c26db X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --001a114013b4b689e5053e5c26db Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BO=E2=80=8B n 8 October 2016 at 15:30, Eli Zaretskii wrote: > > From: Reuben Thomas > > Date: Sat, 8 Oct 2016 14:30:41 +0100 > > Cc: 24640@debbugs.gnu.org > > > > So the value of 'ptr' there (frame 20 in the 1st backtrace) is of > > interest. > > > > =E2=80=8BThe current backtrace seems to have crashed at a different poi= nt, and > doesn't even include this line, but this > > time I've kept the gdb session running in case I can tell you anything > else of =E2=80=8B > > =E2=80=8Binterest.=E2=80=8B > > Well, can you tell why it crashed this time? IOW, what was the > immediate cause of SIGSEGV? > =E2=80=8BExactly the same as before: crashed while lazy-reloading in deskto= p.el. At the same point as before, as far as I can tell. =E2=80=8B=E2=80=8B --=20 http://rrt.sc3d.org --001a114013b4b689e5053e5c26db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8B= O=E2=80=8B
n 8 October 2016 at 15:30, Eli Zaretskii = <eliz@gnu.org><= /span> wrote:
> From: Reuben Thomas &l= t;rrt@sc3d.org>
> Date: Sat, 8 Oct 2016 14:30:41 +0100
> Cc: 24640@debbugs.gnu.org=
>
>=C2=A0 So the value of 'ptr' there (frame 20 in the 1st backtra= ce) is of
>=C2=A0 interest.
>
> =E2=80=8BThe current backtrace seems to have crashed at a different po= int, and doesn't even include this line, but this
> time I've kept the gdb session running in case I can tell you anyt= hing else of =E2=80=8B
> =E2=80=8Binterest.=E2=80=8B

Well, can you tell why it crashed this time?=C2=A0 IOW, what was the=
immediate cause of SIGSEGV?

=E2=80=8BExactly the same as before: crashed while lazy-reloading in des= ktop.el. At the same point as before, as far as I can tell.
=E2=80=8B=E2= =80=8B

--
http://rrt.= sc3d.org
--001a114013b4b689e5053e5c26db-- From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 08 11:34:24 2016 Received: (at 24640) by debbugs.gnu.org; 8 Oct 2016 15:34:24 +0000 Received: from localhost ([127.0.0.1]:48883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bstdo-0003yF-DL for submit@debbugs.gnu.org; Sat, 08 Oct 2016 11:34:24 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42519) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bstdn-0003y4-PB for 24640@debbugs.gnu.org; Sat, 08 Oct 2016 11:34:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bstdd-0005va-Uh for 24640@debbugs.gnu.org; Sat, 08 Oct 2016 11:34:18 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48331) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bstdd-0005vG-Rs; Sat, 08 Oct 2016 11:34:13 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2942 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bstdd-00058m-0o; Sat, 08 Oct 2016 11:34:13 -0400 Date: Sat, 08 Oct 2016 18:34:22 +0300 Message-Id: <83eg3qhn29.fsf@gnu.org> From: Eli Zaretskii To: Reuben Thomas In-reply-to: (message from Reuben Thomas on Sat, 8 Oct 2016 16:26:30 +0100) Subject: Re: bug#24640: Crashes in 25.1 References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.7 (-------) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.7 (-------) > From: Reuben Thomas > Date: Sat, 8 Oct 2016 16:26:30 +0100 > Cc: 24640@debbugs.gnu.org > > Well, can you tell why it crashed this time? IOW, what was the > immediate cause of SIGSEGV? > > ​Exactly the same as before: crashed while lazy-reloading in desktop.el. At the same point as before, as far as > I can tell. No, I meant the immediate cause of SIGSEGV, one frame below the one which invokes the signal handler. There must be some bad data there, what it is? From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 08 18:09:03 2016 Received: (at 24640) by debbugs.gnu.org; 8 Oct 2016 22:09:03 +0000 Received: from localhost ([127.0.0.1]:49092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bszni-0006qf-Pv for submit@debbugs.gnu.org; Sat, 08 Oct 2016 18:09:03 -0400 Received: from mail-lf0-f44.google.com ([209.85.215.44]:33955) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bsznf-0006q7-UE for 24640@debbugs.gnu.org; Sat, 08 Oct 2016 18:09:01 -0400 Received: by mail-lf0-f44.google.com with SMTP id b81so63762764lfe.1 for <24640@debbugs.gnu.org>; Sat, 08 Oct 2016 15:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jN83vi18Rfr14b05Q/ryKNHGHfyRn/DJKvUaB74unc4=; b=2HzvsTmCB9YTWehbX/1d2ScIPaYiTAPrRiiEW545nuYfZJeU+K9cGCjaIHinI3rcSH fh7Q0BrQL2gKvm/tkBfGiZEqHTWZaUYjQmIhwnC0k/h7DMCoR7x6vureO0H/98r4YE1m s2w83wVJj3KsQuPiwqFUIl312H7cko06r2lrw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jN83vi18Rfr14b05Q/ryKNHGHfyRn/DJKvUaB74unc4=; b=E3l9SUvvTmj/g01TKz+xiL/EXAiv867x7T20JXWuXmi0fwjOiVwMSXEZAnxVy+xuBV jBkHXILVBnskfJ9pAf1m2e2CQg8wR6+bNCsB7GjZJnpuzS9k1EsH/3U3byGcNTb81ETw YwZJogBog1FkR1wMxHgPJvXHUsK45UGqrIRafx9V8tYhz4Ndi0qUklxIkKG+XSqkVGaC I8qm/XfzBW2HOTpfeGMxvD73ru3Gz1lLOrbWxGMcDnvNuUZfLoRw+q+f1sBkbF40EXdg 5IOQOpqsHIPskYA9CK/gtD85cLJF4ayMdBXf3jqTdS1OvxlXQNP2VAldvRFfvJwzgkg/ w9rQ== X-Gm-Message-State: AA6/9RnKt2CgRyEb2lwf0NwyShx0qdoBR9VJO/u9t2uazW4XFXwzyKJDq7JOtqS10TbhwOewKOJmQQvybzbZ/VpI X-Received: by 10.25.134.139 with SMTP id i133mr8999436lfd.27.1475964532374; Sat, 08 Oct 2016 15:08:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.66.211 with HTTP; Sat, 8 Oct 2016 15:08:51 -0700 (PDT) In-Reply-To: <83eg3qhn29.fsf@gnu.org> References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> From: Reuben Thomas Date: Sat, 8 Oct 2016 23:08:51 +0100 Message-ID: Subject: Re: bug#24640: Crashes in 25.1 To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a113fc314a7546b053e61c5ae X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --001a113fc314a7546b053e61c5ae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8 October 2016 at 16:34, Eli Zaretskii wrote: > > From: Reuben Thomas > > Date: Sat, 8 Oct 2016 16:26:30 +0100 > > Cc: 24640@debbugs.gnu.org > > > > Well, can you tell why it crashed this time? IOW, what was the > > immediate cause of SIGSEGV? > > > > =E2=80=8BExactly the same as before: crashed while lazy-reloading in de= sktop.el. > At the same point as before, as far as > > I can tell. > > No, I meant the immediate cause of SIGSEGV, one frame below the one > which invokes the signal handler. There must be some bad data there, > what it is? > =E2=80=8BHere's the current C backtrace: #0 0x000000000054aa44 in mark_object (arg=3D) at alloc.c:64= 88 #1 0x000000000054a8fe in mark_object (arg=3D) at alloc.c:64= 52 #2 0x000000000054a8fe in mark_object (arg=3D) at alloc.c:64= 52 #3 0x000000000054a9cb in mark_object (arg=3D) at alloc.c:65= 39 #4 0x000000000054a9cb in mark_object (arg=3D) at alloc.c:65= 39 #5 0x000000000054b20c in Fgarbage_collect (end=3D0x7fffffff9a28) at alloc.c:5745 #6 0x000000000054b20c in Fgarbage_collect () at alloc.c:5979 #7 0x000000000059979e in exec_byte_code () at lisp.h:4656 #8 0x000000000059979e in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3D, nargs=3Dnargs@entry=3D6, args=3D, args@entry=3D0x93791= 4 ) at bytecode.c:714 #9 0x0000000000562976 in funcall_lambda (fun=3D140737488330544, nargs=3Dnargs@entry=3D6, arg_vector=3D0x937914 , arg_vector@entry=3D0x7fffffff9ea0) at eval.c:2855 #10 0x0000000000562c3b in Ffuncall (nargs=3Dnargs@entry=3D7, args=3Dargs@entry=3D0x7fffffff9e98) at eval.c:2754 #11 0x00000000005641d4 in Fapply (nargs=3D7, args=3D0x7fffffff9e98) at eval.c:2278 #12 0x0000000000562d41 in Ffuncall (nargs=3D8, args=3Dargs@entry=3D0x7fffff= ff9e90) at eval.c:2673 #13 0x00000000005975d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3D, nargs=3Dnargs@entry=3D3, args=3D, args@entry=3D0x236a3= d4) at bytecode.c:880 #14 0x0000000000562976 in funcall_lambda (fun=3D140737488331264, nargs=3Dnargs@entry=3D3, arg_vector=3D0x236a3d4, arg_vector@entry=3D0x7fffffffa188) at eval.c:2855 #15 0x0000000000562c3b in Ffuncall (nargs=3Dnargs@entry=3D4, args=3Dargs@entry=3D0x7fffffffa180) at eval.c:2754 #16 0x00000000005641d4 in Fapply (nargs=3D4, args=3D0x7fffffffa180) at eval.c:2278 #17 0x0000000000562d41 in Ffuncall (nargs=3D5, args=3Dargs@entry=3D0x7fffff= ffa178) at eval.c:2673 #18 0x00000000005975d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3D, nargs=3Dnargs@entry=3D2, args=3D, args@entry=3D0x240e2= 44) at bytecode.c:880 #19 0x0000000000562976 in funcall_lambda (fun=3D140737488332048, nargs=3Dnargs@entry=3D2, arg_vector=3D0x240e244, arg_vector@entry=3D0x7fffffffa318) at eval.c:2855 #20 0x0000000000562c3b in Ffuncall (nargs=3Dnargs@entry=3D3, args=3D0x7fffffffa310) at eval.c:2754 #21 0x0000000000564020 in Fapply (nargs=3D, args=3D0x7fffffffa488) at eval.c:2321 #22 0x0000000000562d41 in Ffuncall (nargs=3D3, args=3Dargs@entry=3D0x7fffff= ffa480) at eval.c:2673 #23 0x00000000005975d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3D, nargs=3Dnargs@entry=3D3, args=3D, args@entry=3D0x22fa6= f4) at bytecode.c:880 #24 0x0000000000562976 in funcall_lambda (fun=3D140737488332496, nargs=3Dnargs@entry=3D3, arg_vector=3D0x22fa6f4, arg_vector@entry=3D0x7fffffffa638) at eval.c:2855 #25 0x0000000000562c3b in Ffuncall (nargs=3D4, args=3Dargs@entry=3D0x7fffff= ffa630) at eval.c:2754 #26 0x00000000005975d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3D, nargs=3Dnargs@entry=3D1, args=3D, args@entry=3D0x2b7d3= 84) at bytecode.c:880 #27 0x0000000000562976 in funcall_lambda (fun=3D140737488332992, nargs=3Dnargs@entry=3D1, arg_vector=3D0x2b7d384, arg_vector@entry=3D0x7fffffffa800) at eval.c:2855 #28 0x0000000000562c3b in Ffuncall (nargs=3D2, args=3Dargs@entry=3D0x7fffff= ffa7f8) at eval.c:2754 #29 0x00000000005975d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3D, nargs=3Dnargs@entry=3D1, args=3D, args@entry=3D0x2b7d5= 64) at bytecode.c:880 #30 0x0000000000562976 in funcall_lambda (fun=3D140737488333712, nargs=3Dnargs@entry=3D1, arg_vector=3D0x2b7d564, arg_vector@entry=3D0x7fffffffab08) at eval.c:2855 #31 0x0000000000562c3b in Ffuncall (nargs=3Dnargs@entry=3D2, args=3Dargs@entry=3D0x7fffffffab00) at eval.c:2754 #32 0x00000000005641d4 in Fapply (nargs=3D2, args=3D0x7fffffffab00) at eval.c:2278 #33 0x0000000000562d41 in Ffuncall (nargs=3D3, args=3Dargs@entry=3D0x7fffff= ffaaf8) at eval.c:2673 #34 0x00000000005975d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3Dargs_template@entry=3D0, nargs=3Dnargs@entry=3D0, args=3D, args@entry=3D0x0) at bytecode.c:880 #35 0x000000000056283f in funcall_lambda (fun=3D10562237, nargs=3Dnargs@ent= ry=3D3, arg_vector=3Darg_vector@entry=3D0x7fffffffad20) at eval.c:2921 #36 0x0000000000562c3b in Ffuncall (nargs=3D4, args=3Dargs@entry=3D0x7fffff= ffad18) at eval.c:2754 #37 0x00000000005975d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3Dargs_template@entry=3D0, nargs=3Dnargs@entry=3D0, args=3D, args@entry=3D0x0) at bytecode.c:880 #38 0x000000000056283f in funcall_lambda (fun=3D10569021, nargs=3Dnargs@ent= ry=3D2, arg_vector=3Darg_vector@entry=3D0x7fffffffaf60) at eval.c:2921 #39 0x0000000000562c3b in Ffuncall (nargs=3D3, args=3Dargs@entry=3D0x7fffff= ffaf58) at eval.c:2754 #40 0x00000000005975d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3Dargs_template@entry=3D0, nargs=3Dnargs@entry=3D0, args=3D, args@entry=3D0x0) at bytecode.c:880 #41 0x000000000056283f in funcall_lambda (fun=3D10570821, nargs=3Dnargs@ent= ry=3D0, arg_vector=3Darg_vector@entry=3D0x7fffffffb1a8) at eval.c:2921 #42 0x0000000000562c3b in Ffuncall (nargs=3D1, args=3Dargs@entry=3D0x7fffff= ffb1a0) at eval.c:2754 #43 0x00000000005975d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3D, nargs=3Dnargs@entry=3D0, args=3D, args@entry=3D0x2e5f6= 74) at bytecode.c:880 #44 0x0000000000562976 in funcall_lambda (fun=3D140737488335872, nargs=3Dnargs@entry=3D0, arg_vector=3D0x2e5f674, arg_vector@entry=3D0x7fffffffb388) at eval.c:2855 #45 0x0000000000562c3b in Ffuncall (nargs=3D1, args=3Dargs@entry=3D0x7fffff= ffb380) at eval.c:2754 #46 0x00000000005975d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3D, nargs=3Dnargs@entry=3D0, args=3D, args@entry=3D0x2e605= a4) at bytecode.c:880 #47 0x0000000000562976 in funcall_lambda (fun=3D140737488336320, nargs=3Dnargs@entry=3D0, arg_vector=3D0x2e605a4, arg_vector@entry=3D0x7fffffffb530) at eval.c:2855 #48 0x0000000000562c3b in Ffuncall (nargs=3D1, args=3Dargs@entry=3D0x7fffff= ffb528) at eval.c:2754 #49 0x00000000005975d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_temp---Type to continue, or q to quit--- late=3D, nargs=3Dnargs@entry=3D1, args=3D, args@entry=3D0x2e56384) at bytecode.c:880 #50 0x0000000000562976 in funcall_lambda (fun=3D140737488336944, nargs=3Dnargs@entry=3D1, arg_vector=3D0x2e56384, arg_vector@entry=3D0x7fffffffb7b0) at eval.c:2855 #51 0x0000000000562c3b in Ffuncall (nargs=3D2, args=3Dargs@entry=3D0x7fffff= ffb7a8) at eval.c:2754 #52 0x00000000005975d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3D, nargs=3Dnargs@entry=3D10, args=3D, args@entry=3D0x2ca3= 794) at bytecode.c:880 #53 0x0000000000562976 in funcall_lambda (fun=3D140737488337792, nargs=3Dnargs@entry=3D10, arg_vector=3D0x2ca3794, arg_vector@entry=3D0x7fffffffb948) at eval.c:2855 #54 0x0000000000562c3b in Ffuncall (nargs=3Dnargs@entry=3D11, args=3D0x7fffffffb940) at eval.c:2754 #55 0x0000000000564020 in Fapply (nargs=3D, args=3D0x7fffffffbb00) at eval.c:2321 #56 0x0000000000562d41 in Ffuncall (nargs=3D3, args=3Dargs@entry=3D0x7fffff= ffbaf8) at eval.c:2673 #57 0x00000000005975d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3D, nargs=3Dnargs@entry=3D0, args=3D, args@entry=3D0x2ca8a= b4) at bytecode.c:880 #58 0x0000000000562976 in funcall_lambda (fun=3D140737488338240, nargs=3Dnargs@entry=3D0, arg_vector=3D0x2ca8ab4, arg_vector@entry=3D0x7fffffffbcb0) at eval.c:2855 #59 0x0000000000562c3b in Ffuncall (nargs=3D1, args=3Dargs@entry=3D0x7fffff= ffbca8) at eval.c:2754 #60 0x00000000005975d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3D, nargs=3Dnargs@entry=3D0, args=3D, args@entry=3D0x2caae= d4) at bytecode.c:880 #61 0x0000000000562976 in funcall_lambda (fun=3D140737488338960, nargs=3Dnargs@entry=3D0, arg_vector=3D0x2caaed4, arg_vector@entry=3D0x7fffffffbf88) at eval.c:2855 #62 0x0000000000562c3b in Ffuncall (nargs=3Dnargs@entry=3D1, args=3Dargs@entry=3D0x7fffffffbf80) at eval.c:2754 #63 0x00000000005641bc in Fapply (nargs=3D2, args=3D0x7fffffffbf80) at eval.c:2274 #64 0x0000000000562d41 in Ffuncall (nargs=3D3, args=3Dargs@entry=3D0x7fffff= ffbf78) at eval.c:2673 #65 0x00000000005975d3 in exec_byte_code (bytestr=3D, vector=3D, maxdepth=3D, args_template=3Dargs_template@entry=3D0, nargs=3Dnargs@entry=3D0, args=3D, args@entry=3D0x0) at bytecode.c:880 #66 0x000000000056283f in funcall_lambda (fun=3D10146693, nargs=3Dnargs@ent= ry=3D1, arg_vector=3Darg_vector@entry=3D0x7fffffffc198) at eval.c:2921 #67 0x0000000000562c3b in Ffuncall (nargs=3Dnargs@entry=3D2, args=3Dargs@entry=3D0x7fffffffc190) at eval.c:2754 #68 0x0000000000562f3a in call1 (fn=3Dfn@entry=3D45264, arg1=3Darg1@entry= =3D46400381) at eval.c:2552 #69 0x00000000004f49c8 in timer_check (idle_timers=3D, timers=3D) at keyboard.c:4427 #70 0x00000000004f49c8 in timer_check () at keyboard.c:4489 #71 0x00000000004f4d89 in readable_events (flags=3Dflags@entry=3D1) at keyboard.c:3328 #72 0x00000000004f6608 in get_input_pending (flags=3Dflags@entry=3D1) at keyboard.c:6725 #73 0x00000000004f8d78 in detect_input_pending_run_timers (do_display=3Ddo_display@entry=3Dtrue) at keyboard.c:9862 #74 0x00000000005a2abb in wait_reading_process_output (time_limit=3Dtime_limit@entry=3D30, nsecs=3Dnsecs@entry=3D0, read_kbd=3Dread_kbd@entry=3D-1, do_display=3Ddo_display@entry=3Dtrue, wait_for_cell=3Dwait_for_cell@entry=3D0, wait_proc=3Dwait_proc@entry=3D0x0, just_wait_proc=3D0) at process.c:4958 #75 0x0000000000422e12 in sit_for (timeout=3D, reading=3Dreading@entry=3Dtrue, display_option=3Ddisplay_option@entry=3D1) = at dispnew.c:5762 #76 0x00000000004fb273 in read_char (commandflag=3Dcommandflag@entry=3D1, map=3Dmap@entry=3D76268163, prev_event=3D0, used_mouse_menu=3Dused_mouse_menu@entry=3D0x7fffffffce3b, end_time=3Dend_time@entry=3D0x0) at keyboard.c:2714 #77 0x00000000004fbeda in read_key_sequence (keybuf=3Dkeybuf@entry=3D0x7fffffffcf10, 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=3Dprevent_redisplay@entry=3Dfalse, bufsize=3D30) at keyboard.c:9063 #78 0x00000000004fdb26 in command_loop_1 () at keyboard.c:1365 #79 0x00000000005615b2 in internal_condition_case (bfun=3Dbfun@entry=3D0x4f= d920 , handlers=3Dhandlers@entry=3D19056, hfun=3Dhfun@entry=3D0x= 4f4080 ) at eval.c:1309 #80 0x00000000004ef54c in command_loop_2 (ignore=3Dignore@entry=3D0) at keyboard.c:1107 #81 0x0000000000561553 in internal_catch (tag=3Dtag@entry=3D45840, func=3Dfunc@entry=3D0x4ef530 , arg=3Darg@entry=3D0) at eval.c:1074 #82 0x00000000004ef509 in command_loop () at keyboard.c:1086 #83 0x00000000004f3c77 in recursive_edit_1 () at keyboard.c:692 #84 0x00000000004f3fb8 in Frecursive_edit () at keyboard.c:763 #85 0x0000000000418dfe in main (argc=3D1, argv=3D0x7fffffffd298) at emacs.c= :1626 =E2=80=8BSorry I didn't post that before, the "bt" command only gives the L= isp backtrace, and I didn't think to try "where".=E2=80=8B =E2=80=8B =E2=80=8BIn frame #0, the code reads: if (XMISCANY (obj)->gcmarkbit) break; at this point obj is 33, XMISCANY(obj) is 20, and gdb tells me "Cannot access memory at address 0x20". =E2=80=8BIf it helps, I'm happy to arrange some sort of live chat to get th= rough the debugging process quicker. --=20 http://rrt.sc3d.org --001a113fc314a7546b053e61c5ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 8 October 2016 at 16:34, Eli= Zaretskii <eliz@gnu.org> wrote:
> From: Reuben Thomas &l= t;rrt@sc3d.org>
> Date: Sat, 8 Oct 2016 16:26:30 +0100
> Cc: 24640@debbugs.gnu.org=
>
>=C2=A0 Well, can you tell why it crashed this time? IOW, what was the >=C2=A0 immediate cause of SIGSEGV?
>
> =E2=80=8BExactly the same as before: crashed while lazy-reloading in d= esktop.el. At the same point as before, as far as
> I can tell.

No, I meant the immediate cause of SIGSEGV, one frame below the one<= br> which invokes the signal handler.=C2=A0 There must be some bad data there,<= br> what it is?

=E2=80=8BHere's the current C backtrace:

#0=C2=A0 0x000= 000000054aa44 in mark_object (arg=3D<optimised out>) at alloc.c:6488<= br>#1=C2=A0 0x000000000054a8fe in mark_object (arg=3D<optimised out>)= at alloc.c:6452
#2=C2=A0 0x000000000054a8fe in mark_object (arg=3D<o= ptimised out>) at alloc.c:6452
#3=C2=A0 0x000000000054a9cb in mark_ob= ject (arg=3D<optimised out>) at alloc.c:6539
#4=C2=A0 0x0000000000= 54a9cb in mark_object (arg=3D<optimised out>) at alloc.c:6539
#5= =C2=A0 0x000000000054b20c in Fgarbage_collect (end=3D0x7fffffff9a28) at all= oc.c:5745
#6=C2=A0 0x000000000054b20c in Fgarbage_collect () at alloc.c:= 5979
#7=C2=A0 0x000000000059979e in exec_byte_code () at lisp.h:4656
= #8=C2=A0 0x000000000059979e in exec_byte_code (bytestr=3D<optimised out&= gt;, vector=3D<optimised out>, maxdepth=3D<optimised out>, args= _template=3D<optimised out>, nargs=3Dnargs@entry=3D6, args=3D<opti= mised out>, args@entry=3D0x937914 <pure+912340>) at bytecode.c:714=
#9=C2=A0 0x0000000000562976 in funcall_lambda (fun=3D140737488330544, n= args=3Dnargs@entry=3D6, arg_vector=3D0x937914 <pure+912340>,
=C2= =A0=C2=A0=C2=A0 arg_vector@entry=3D0x7fffffff9ea0) at eval.c:2855
#10 0x= 0000000000562c3b in Ffuncall (nargs=3Dnargs@entry=3D7, args=3Dargs@entry=3D= 0x7fffffff9e98) at eval.c:2754
#11 0x00000000005641d4 in Fapply (nargs= =3D7, args=3D0x7fffffff9e98) at eval.c:2278
#12 0x0000000000562d41 in Ff= uncall (nargs=3D8, args=3Dargs@entry=3D0x7fffffff9e90) at eval.c:2673
#1= 3 0x00000000005975d3 in exec_byte_code (bytestr=3D<optimised out>, ve= ctor=3D<optimised out>, maxdepth=3D<optimised out>, args_templa= te=3D<optimised out>, nargs=3Dnargs@entry=3D3, args=3D<optimised o= ut>, args@entry=3D0x236a3d4) at bytecode.c:880
#14 0x0000000000562976= in funcall_lambda (fun=3D140737488331264, nargs=3Dnargs@entry=3D3, arg_vec= tor=3D0x236a3d4,
=C2=A0=C2=A0=C2=A0 arg_vector@entry=3D0x7fffffffa188) = at eval.c:2855
#15 0x0000000000562c3b in Ffuncall (nargs=3Dnargs@entry= =3D4, args=3Dargs@entry=3D0x7fffffffa180) at eval.c:2754
#16 0x000000000= 05641d4 in Fapply (nargs=3D4, args=3D0x7fffffffa180) at eval.c:2278
#17 = 0x0000000000562d41 in Ffuncall (nargs=3D5, args=3Dargs@entry=3D0x7fffffffa1= 78) at eval.c:2673
#18 0x00000000005975d3 in exec_byte_code (bytestr=3D&= lt;optimised out>, vector=3D<optimised out>, maxdepth=3D<optimi= sed out>, args_template=3D<optimised out>, nargs=3Dnargs@entry=3D2= , args=3D<optimised out>, args@entry=3D0x240e244) at bytecode.c:880#19 0x0000000000562976 in funcall_lambda (fun=3D140737488332048, nargs=3D= nargs@entry=3D2, arg_vector=3D0x240e244,
=C2=A0=C2=A0=C2=A0 arg_vector@= entry=3D0x7fffffffa318) at eval.c:2855
#20 0x0000000000562c3b in Ffuncal= l (nargs=3Dnargs@entry=3D3, args=3D0x7fffffffa310) at eval.c:2754
#21 0x= 0000000000564020 in Fapply (nargs=3D<optimised out>, args=3D0x7ffffff= fa488) at eval.c:2321
#22 0x0000000000562d41 in Ffuncall (nargs=3D3, arg= s=3Dargs@entry=3D0x7fffffffa480) at eval.c:2673
#23 0x00000000005975d3 i= n exec_byte_code (bytestr=3D<optimised out>, vector=3D<optimised o= ut>, maxdepth=3D<optimised out>, args_template=3D<optimised out= >, nargs=3Dnargs@entry=3D3, args=3D<optimised out>, args@entry=3D0= x22fa6f4) at bytecode.c:880
#24 0x0000000000562976 in funcall_lambda (fu= n=3D140737488332496, nargs=3Dnargs@entry=3D3, arg_vector=3D0x22fa6f4,
= =C2=A0=C2=A0=C2=A0 arg_vector@entry=3D0x7fffffffa638) at eval.c:2855
#25= 0x0000000000562c3b in Ffuncall (nargs=3D4, args=3Dargs@entry=3D0x7fffffffa= 630) at eval.c:2754
#26 0x00000000005975d3 in exec_byte_code (bytestr=3D= <optimised out>, vector=3D<optimised out>, maxdepth=3D<optim= ised out>, args_template=3D<optimised out>, nargs=3Dnargs@entry=3D= 1, args=3D<optimised out>, args@entry=3D0x2b7d384) at bytecode.c:880<= br>#27 0x0000000000562976 in funcall_lambda (fun=3D140737488332992, nargs= =3Dnargs@entry=3D1, arg_vector=3D0x2b7d384,
=C2=A0=C2=A0=C2=A0 arg_vect= or@entry=3D0x7fffffffa800) at eval.c:2855
#28 0x0000000000562c3b in Ffun= call (nargs=3D2, args=3Dargs@entry=3D0x7fffffffa7f8) at eval.c:2754
#29 = 0x00000000005975d3 in exec_byte_code (bytestr=3D<optimised out>, vect= or=3D<optimised out>, maxdepth=3D<optimised out>, args_template= =3D<optimised out>, nargs=3Dnargs@entry=3D1, args=3D<optimised out= >, args@entry=3D0x2b7d564) at bytecode.c:880
#30 0x0000000000562976 i= n funcall_lambda (fun=3D140737488333712, nargs=3Dnargs@entry=3D1, arg_vecto= r=3D0x2b7d564,
=C2=A0=C2=A0=C2=A0 arg_vector@entry=3D0x7fffffffab08) at= eval.c:2855
#31 0x0000000000562c3b in Ffuncall (nargs=3Dnargs@entry=3D2= , args=3Dargs@entry=3D0x7fffffffab00) at eval.c:2754
#32 0x0000000000564= 1d4 in Fapply (nargs=3D2, args=3D0x7fffffffab00) at eval.c:2278
#33 0x00= 00000000562d41 in Ffuncall (nargs=3D3, args=3Dargs@entry=3D0x7fffffffaaf8) = at eval.c:2673
#34 0x00000000005975d3 in exec_byte_code (bytestr=3D<o= ptimised out>, vector=3D<optimised out>, maxdepth=3D<optimised = out>, args_template=3Dargs_template@entry=3D0, nargs=3Dnargs@entry=3D0, = args=3D<optimised out>, args@entry=3D0x0) at bytecode.c:880
#35 0x= 000000000056283f in funcall_lambda (fun=3D10562237, nargs=3Dnargs@entry=3D3= , arg_vector=3Darg_vector@entry=3D0x7fffffffad20)
=C2=A0=C2=A0=C2=A0 at = eval.c:2921
#36 0x0000000000562c3b in Ffuncall (nargs=3D4, args=3Dargs@e= ntry=3D0x7fffffffad18) at eval.c:2754
#37 0x00000000005975d3 in exec_byt= e_code (bytestr=3D<optimised out>, vector=3D<optimised out>, ma= xdepth=3D<optimised out>, args_template=3Dargs_template@entry=3D0, na= rgs=3Dnargs@entry=3D0, args=3D<optimised out>, args@entry=3D0x0) at b= ytecode.c:880
#38 0x000000000056283f in funcall_lambda (fun=3D10569021, = nargs=3Dnargs@entry=3D2, arg_vector=3Darg_vector@entry=3D0x7fffffffaf60)=C2=A0=C2=A0=C2=A0 at eval.c:2921
#39 0x0000000000562c3b in Ffuncall (n= args=3D3, args=3Dargs@entry=3D0x7fffffffaf58) at eval.c:2754
#40 0x00000= 000005975d3 in exec_byte_code (bytestr=3D<optimised out>, vector=3D&l= t;optimised out>, maxdepth=3D<optimised out>, args_template=3Dargs= _template@entry=3D0, nargs=3Dnargs@entry=3D0, args=3D<optimised out>,= args@entry=3D0x0) at bytecode.c:880
#41 0x000000000056283f in funcall_l= ambda (fun=3D10570821, nargs=3Dnargs@entry=3D0, arg_vector=3Darg_vector@ent= ry=3D0x7fffffffb1a8)
=C2=A0=C2=A0=C2=A0 at eval.c:2921
#42 0x00000000= 00562c3b in Ffuncall (nargs=3D1, args=3Dargs@entry=3D0x7fffffffb1a0) at eva= l.c:2754
#43 0x00000000005975d3 in exec_byte_code (bytestr=3D<optimis= ed out>, vector=3D<optimised out>, maxdepth=3D<optimised out>= ;, args_template=3D<optimised out>, nargs=3Dnargs@entry=3D0, args=3D&= lt;optimised out>, args@entry=3D0x2e5f674) at bytecode.c:880
#44 0x00= 00000000562976 in funcall_lambda (fun=3D140737488335872, nargs=3Dnargs@entr= y=3D0, arg_vector=3D0x2e5f674,
=C2=A0=C2=A0=C2=A0 arg_vector@entry=3D0x= 7fffffffb388) at eval.c:2855
#45 0x0000000000562c3b in Ffuncall (nargs= =3D1, args=3Dargs@entry=3D0x7fffffffb380) at eval.c:2754
#46 0x000000000= 05975d3 in exec_byte_code (bytestr=3D<optimised out>, vector=3D<op= timised out>, maxdepth=3D<optimised out>, args_template=3D<opti= mised out>, nargs=3Dnargs@entry=3D0, args=3D<optimised out>, args@= entry=3D0x2e605a4) at bytecode.c:880
#47 0x0000000000562976 in funcall_l= ambda (fun=3D140737488336320, nargs=3Dnargs@entry=3D0, arg_vector=3D0x2e605= a4,
=C2=A0=C2=A0=C2=A0 arg_vector@entry=3D0x7fffffffb530) at eval.c:285= 5
#48 0x0000000000562c3b in Ffuncall (nargs=3D1, args=3Dargs@entry=3D0x7= fffffffb528) at eval.c:2754
#49 0x00000000005975d3 in exec_byte_code (by= testr=3D<optimised out>, vector=3D<optimised out>, maxdepth=3D&= lt;optimised out>, args_temp---Type <return> to continue, or q <= ;return> to quit---
late=3D<optimised out>, nargs=3Dnargs@entry= =3D1, args=3D<optimised out>, args@entry=3D0x2e56384) at bytecode.c:8= 80
#50 0x0000000000562976 in funcall_lambda (fun=3D140737488336944, narg= s=3Dnargs@entry=3D1, arg_vector=3D0x2e56384,
=C2=A0=C2=A0=C2=A0 arg_vec= tor@entry=3D0x7fffffffb7b0) at eval.c:2855
#51 0x0000000000562c3b in Ffu= ncall (nargs=3D2, args=3Dargs@entry=3D0x7fffffffb7a8) at eval.c:2754
#52= 0x00000000005975d3 in exec_byte_code (bytestr=3D<optimised out>, vec= tor=3D<optimised out>, maxdepth=3D<optimised out>, args_templat= e=3D<optimised out>, nargs=3Dnargs@entry=3D10, args=3D<optimised o= ut>, args@entry=3D0x2ca3794) at bytecode.c:880
#53 0x0000000000562976= in funcall_lambda (fun=3D140737488337792, nargs=3Dnargs@entry=3D10, arg_ve= ctor=3D0x2ca3794,
=C2=A0=C2=A0=C2=A0 arg_vector@entry=3D0x7fffffffb948)= at eval.c:2855
#54 0x0000000000562c3b in Ffuncall (nargs=3Dnargs@entry= =3D11, args=3D0x7fffffffb940) at eval.c:2754
#55 0x0000000000564020 in F= apply (nargs=3D<optimised out>, args=3D0x7fffffffbb00) at eval.c:2321=
#56 0x0000000000562d41 in Ffuncall (nargs=3D3, args=3Dargs@entry=3D0x7f= ffffffbaf8) at eval.c:2673
#57 0x00000000005975d3 in exec_byte_code (byt= estr=3D<optimised out>, vector=3D<optimised out>, maxdepth=3D&l= t;optimised out>, args_template=3D<optimised out>, nargs=3Dnargs@e= ntry=3D0, args=3D<optimised out>, args@entry=3D0x2ca8ab4) at bytecode= .c:880
#58 0x0000000000562976 in funcall_lambda (fun=3D140737488338240, = nargs=3Dnargs@entry=3D0, arg_vector=3D0x2ca8ab4,
=C2=A0=C2=A0=C2=A0 arg= _vector@entry=3D0x7fffffffbcb0) at eval.c:2855
#59 0x0000000000562c3b in= Ffuncall (nargs=3D1, args=3Dargs@entry=3D0x7fffffffbca8) at eval.c:2754#60 0x00000000005975d3 in exec_byte_code (bytestr=3D<optimised out>,= vector=3D<optimised out>, maxdepth=3D<optimised out>, args_tem= plate=3D<optimised out>, nargs=3Dnargs@entry=3D0, args=3D<optimise= d out>, args@entry=3D0x2caaed4) at bytecode.c:880
#61 0x0000000000562= 976 in funcall_lambda (fun=3D140737488338960, nargs=3Dnargs@entry=3D0, arg_= vector=3D0x2caaed4,
=C2=A0=C2=A0=C2=A0 arg_vector@entry=3D0x7fffffffbf8= 8) at eval.c:2855
#62 0x0000000000562c3b in Ffuncall (nargs=3Dnargs@entr= y=3D1, args=3Dargs@entry=3D0x7fffffffbf80) at eval.c:2754
#63 0x00000000= 005641bc in Fapply (nargs=3D2, args=3D0x7fffffffbf80) at eval.c:2274
#64= 0x0000000000562d41 in Ffuncall (nargs=3D3, args=3Dargs@entry=3D0x7fffffffb= f78) at eval.c:2673
#65 0x00000000005975d3 in exec_byte_code (bytestr=3D= <optimised out>, vector=3D<optimised out>, maxdepth=3D<optim= ised out>, args_template=3Dargs_template@entry=3D0, nargs=3Dnargs@entry= =3D0, args=3D<optimised out>, args@entry=3D0x0) at bytecode.c:880
= #66 0x000000000056283f in funcall_lambda (fun=3D10146693, nargs=3Dnargs@ent= ry=3D1, arg_vector=3Darg_vector@entry=3D0x7fffffffc198)
=C2=A0=C2=A0=C2= =A0 at eval.c:2921
#67 0x0000000000562c3b in Ffuncall (nargs=3Dnargs@ent= ry=3D2, args=3Dargs@entry=3D0x7fffffffc190) at eval.c:2754
#68 0x0000000= 000562f3a in call1 (fn=3Dfn@entry=3D45264, arg1=3Darg1@entry=3D46400381) at= eval.c:2552
#69 0x00000000004f49c8 in timer_check (idle_timers=3D<op= timised out>, timers=3D<optimised out>) at keyboard.c:4427
#70 = 0x00000000004f49c8 in timer_check () at keyboard.c:4489
#71 0x0000000000= 4f4d89 in readable_events (flags=3Dflags@entry=3D1) at keyboard.c:3328
#= 72 0x00000000004f6608 in get_input_pending (flags=3Dflags@entry=3D1) at key= board.c:6725
#73 0x00000000004f8d78 in detect_input_pending_run_timers (= do_display=3Ddo_display@entry=3Dtrue) at keyboard.c:9862
#74 0x000000000= 05a2abb in wait_reading_process_output (time_limit=3Dtime_limit@entry=3D30,= nsecs=3Dnsecs@entry=3D0, read_kbd=3Dread_kbd@entry=3D-1, do_display=3Ddo_d= isplay@entry=3Dtrue, wait_for_cell=3Dwait_for_cell@entry=3D0, wait_proc=3Dw= ait_proc@entry=3D0x0, just_wait_proc=3D0) at process.c:4958
#75 0x000000= 0000422e12 in sit_for (timeout=3D<optimised out>, reading=3Dreading@e= ntry=3Dtrue, display_option=3Ddisplay_option@entry=3D1) at dispnew.c:5762#76 0x00000000004fb273 in read_char (commandflag=3Dcommandflag@entry=3D1,= map=3Dmap@entry=3D76268163, prev_event=3D0, used_mouse_menu=3Dused_mouse_m= enu@entry=3D0x7fffffffce3b, end_time=3Dend_time@entry=3D0x0) at keyboard.c:= 2714
#77 0x00000000004fbeda in read_key_sequence (keybuf=3Dkeybuf@entry= =3D0x7fffffffcf10, prompt=3Dprompt@entry=3D0, dont_downcase_last=3Ddont_dow= ncase_last@entry=3Dfalse, can_return_switch_frame=3Dcan_return_switch_frame= @entry=3Dtrue, fix_current_buffer=3Dfix_current_buffer@entry=3Dtrue, preven= t_redisplay=3Dprevent_redisplay@entry=3Dfalse, bufsize=3D30) at keyboard.c:= 9063
#78 0x00000000004fdb26 in command_loop_1 () at keyboard.c:1365
#= 79 0x00000000005615b2 in internal_condition_case (bfun=3Dbfun@entry=3D0x4fd= 920 <command_loop_1>, handlers=3Dhandlers@entry=3D19056, hfun=3Dhfun@= entry=3D0x4f4080 <cmd_error>) at eval.c:1309
#80 0x00000000004ef54= c in command_loop_2 (ignore=3Dignore@entry=3D0) at keyboard.c:1107
#81 0= x0000000000561553 in internal_catch (tag=3Dtag@entry=3D45840, func=3Dfunc@e= ntry=3D0x4ef530 <command_loop_2>, arg=3Darg@entry=3D0)
=C2=A0=C2= =A0=C2=A0 at eval.c:1074
#82 0x00000000004ef509 in command_loop () at ke= yboard.c:1086
#83 0x00000000004f3c77 in recursive_edit_1 () at keyboard.= c:692
#84 0x00000000004f3fb8 in Frecursive_edit () at keyboard.c:763
= #85 0x0000000000418dfe in main (argc=3D1, argv=3D0x7fffffffd298) at emacs.c= :1626

=E2=80=8BSorry I didn't post that before, the "bt" co= mmand only gives the Lisp backtrace, and I didn't think to try "wh= ere".=E2=80=8B
=E2=80=8B

=E2=80=8BIn frame #0, the code reads:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (XMISCANY (obj)->gcmarkbit)
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;

at this point obj is 33, XMISC= ANY(obj) is 20, and gdb tells me "Cannot access memory at address 0x20= ".

=E2=80=8BIf it helps, I'm happy to arrange some sort of live chat to g= et through the debugging process quicker.

--
http://= rrt.sc3d.org
--001a113fc314a7546b053e61c5ae-- From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 09 03:05:25 2016 Received: (at 24640) by debbugs.gnu.org; 9 Oct 2016 07:05:25 +0000 Received: from localhost ([127.0.0.1]:49233 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bt8An-0006Gd-68 for submit@debbugs.gnu.org; Sun, 09 Oct 2016 03:05:25 -0400 Received: from eggs.gnu.org ([208.118.235.92]:54559) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bt8Al-0006GR-1p for 24640@debbugs.gnu.org; Sun, 09 Oct 2016 03:05:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bt8Ab-00034e-9X for 24640@debbugs.gnu.org; Sun, 09 Oct 2016 03:05:17 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59167) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bt8Ab-00034M-68; Sun, 09 Oct 2016 03:05:13 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3570 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bt8AZ-0005GP-FG; Sun, 09 Oct 2016 03:05:11 -0400 Date: Sun, 09 Oct 2016 10:05:22 +0300 Message-Id: <83vax2f1e5.fsf@gnu.org> From: Eli Zaretskii To: Reuben Thomas In-reply-to: (message from Reuben Thomas on Sat, 8 Oct 2016 23:08:51 +0100) Subject: Re: bug#24640: Crashes in 25.1 References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.7 (-------) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.7 (-------) > From: Reuben Thomas > Date: Sat, 8 Oct 2016 23:08:51 +0100 > Cc: 24640@debbugs.gnu.org > > ​In frame #0, the code reads: > > if (XMISCANY (obj)->gcmarkbit) > break; > > at this point obj is 33, XMISCANY(obj) is 20, and gdb tells me "Cannot access memory at address 0x20". What do the following commands say in that frame #0: (gdb) p obj (gdb) xtype > ​If it helps, I'm happy to arrange some sort of live chat to get through the debugging process quicker. The only efficient way to speed up debugging (or rather to make sure it succeeds at all) is for you to come up with a reproducible recipe and post here all the files needed for reproducing the crashes. >From what I see in the backtraces, your setup fires a timer that runs some complicated Lisp, and that Lisp somehow corrupts some Lisp objects, which then cause crashes during GC. I don't see how this can be debugged at all, except by someone who actually has this on his/her machine and knows how to debug these problems. And the first step is to stop using an optimized build, because it makes debugging much harder if not impossible. If you are willing to try the debugging yourself, there's some advice in etc/DEBUG (search for "Debugging problems which happen in GC"). Do I understand correctly that this worked for you with Emacs 24.5? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 09 03:45:18 2016 Received: (at 24640) by debbugs.gnu.org; 9 Oct 2016 07:45:18 +0000 Received: from localhost ([127.0.0.1]:49256 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bt8nO-0007Eo-2J for submit@debbugs.gnu.org; Sun, 09 Oct 2016 03:45:18 -0400 Received: from mail-lf0-f54.google.com ([209.85.215.54]:34051) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bt8nL-0007EZ-3Z for 24640@debbugs.gnu.org; Sun, 09 Oct 2016 03:45:16 -0400 Received: by mail-lf0-f54.google.com with SMTP id b81so67690712lfe.1 for <24640@debbugs.gnu.org>; Sun, 09 Oct 2016 00:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WqlyHFZttq3jVxaxHZiFhF8tMAuoXq5233fnZO8vAHg=; b=Ab2tBmsiwWF9YSQfIvC5GpcAyxTB+4O6+vnm1hBqTcapZ3pzABgTifn+QYLfZUEm8G 9KcGzRcIVK/nuX+llm32+avhp6t4d+WvH3Xnh9ARBYnd9IGax/x0gDs+151DeZYVyukH xpeJTm8Z9jcrhlXcOVFywhYshtYMXAKme5lUA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WqlyHFZttq3jVxaxHZiFhF8tMAuoXq5233fnZO8vAHg=; b=NZnw13aMPEC0+InEQLjCOsUuVG12nxvFsh/NDTv+tK14T+j1k0I4mv9JgCIEoZx52X gDtjkB+6vUmUEiizzaOawm6ZBKL3wEiSyCv7PoY87pONXkPn58S8vsOfoHr0Qao/yVkq utzNIhdUXB4cJLdnIkiCn10yaHIbUv+zQzeNh4TYGw+JIFF7xE15mV6CZ8SKnju1a9DU HLASVMHB4U7EStuAvdImRJT2qroBkT+x7JHm/to8lwYIJA6Y5STE+NDzdc4E5SxRqYjr KSOYByI3KVIknWVB6z2P5/VQ7TaMlB8V7BxSbbEJ3rmaMn3ahn9y+XlF7lreAznelCt8 waJQ== X-Gm-Message-State: AA6/9RnPjiJceMn+5evpGNXLxH9AZFCGJ4c6hwthseaDyJ14PS/0QwkIBaNTqaQXQs3PCZRcHoJYf4hicFFrWPvC X-Received: by 10.25.129.147 with SMTP id c141mr588507lfd.171.1475999108787; Sun, 09 Oct 2016 00:45:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.66.211 with HTTP; Sun, 9 Oct 2016 00:45:08 -0700 (PDT) In-Reply-To: <83vax2f1e5.fsf@gnu.org> References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> <83vax2f1e5.fsf@gnu.org> From: Reuben Thomas Date: Sun, 9 Oct 2016 08:45:08 +0100 Message-ID: Subject: Re: bug#24640: Crashes in 25.1 To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a113eae7691894f053e69d253 X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) --001a113eae7691894f053e69d253 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 9 October 2016 at 08:05, Eli Zaretskii wrote: > > From: Reuben Thomas > > Date: Sat, 8 Oct 2016 23:08:51 +0100 > > Cc: 24640@debbugs.gnu.org > > > > =E2=80=8BIn frame #0, the code reads: > > > > if (XMISCANY (obj)->gcmarkbit) > > break; > > > > at this point obj is 33, XMISCANY(obj) is 20, and gdb tells me "Cannot > access memory at address 0x20". > > What do the following commands say in that frame #0: > > (gdb) p obj > (gdb) xtype > (gdb) p obj $3 =3D 33 (gdb) xtype Lisp_Misc Cannot access memory at address 0x20=E2=80=8B The only efficient way to speed up debugging (or rather to make sure > it succeeds at all) is for you to come up with a reproducible recipe > and post here all the files needed for reproducing the crashes. > =E2=80=8BThat would seem to require me to bisect my .desktop and potentiall= y post dozens of personal files, so doesn't seem feasible.=E2=80=8B I thought it m= ight be faster for you to drive a debugging session live than to engage in back-and-forth by email. >From what I see in the backtraces, your setup fires a timer that runs > some complicated Lisp, and that Lisp somehow corrupts some Lisp > objects, which then cause crashes during GC. =E2=80=8BYou make it sound as though this is some arcane personal setup, wh= en in fact I am simply using desktop.el! And the first step is > to stop using an optimized build, because it makes debugging much > harder if not impossible. > I'll see if, having rebuilt from source without optimisation, the bug still fires.=E2=80=8B If you are willing to try the debugging yourself, there's some advice > in etc/DEBUG (search for "Debugging problems which happen in GC"). > =E2=80=8BI'll have a look.=E2=80=8B > Do I understand correctly that this worked for you with Emacs 24.5? > =E2=80=8BYes, the identical setup loads fine in 24.5. I've never seen this = sort of crash before.=E2=80=8B --=20 http://rrt.sc3d.org --001a113eae7691894f053e69d253 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 9= October 2016 at 08:05, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Reuben Thomas &l= t;rrt@sc3d.org>
> Date: Sat, 8 Oct 2016 23:08:51 +0100
> Cc: 24640@debbugs.gnu.org=
>
> =E2=80=8BIn frame #0, the code reads:
>
> if (XMISCANY (obj)->gcmarkbit)
> break;
>
> at this point obj is 33, XMISCANY(obj) is 20, and gdb tells me "C= annot access memory at address 0x20".

What do the following commands say in that frame #0:

=C2=A0(gdb) p obj
=C2=A0(gdb) xtype

(gdb) p obj
$3 =3D 33
(gdb= ) xtype
Lisp_Misc
Cannot access memory at address 0x20=E2=80=8B
The only efficient way to speed up debugging (or rather to make sure=
it succeeds at all) is for you to come up with a reproducible recipe
and post here all the files needed for reproducing the crashes.

=E2=80= =8BThat would seem to require me to bisect my .desktop and potentially post= dozens of personal files, so doesn't seem feasible.=E2=80=8B I thought= it might be faster for you to drive a debugging session live than to engag= e in back-and-forth by email.

>From what I see in the backtraces, your setup fires a timer that runs
some complicated Lisp, and that Lisp somehow corrupts some Lisp
objects, which then cause crashes during GC.

=E2=80=8BYou make it sound as= though this is some arcane personal setup, when in fact I am simply using = desktop.el!

I'll see if, having rebuilt from source = without optimisation, the bug still fires.=E2=80=8B

If you are willing to try the debugging yourself, there's some advice in etc/DEBUG (search for "Debugging problems which happen in GC")= .

=E2=80=8BI'll have a look.=E2=80=8B
=C2=A0
Do I understand correctly that this worked for you with Emacs 24.5?

= =E2=80=8BYes, the identical setup loads fine in 24.5. I've never seen t= his sort of crash before.=E2=80=8B

--
http= ://rrt.sc3d.org
--001a113eae7691894f053e69d253-- From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 09 05:57:35 2016 Received: (at 24640) by debbugs.gnu.org; 9 Oct 2016 09:57:35 +0000 Received: from localhost ([127.0.0.1]:49335 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btArO-0001uI-SM for submit@debbugs.gnu.org; Sun, 09 Oct 2016 05:57:35 -0400 Received: from eggs.gnu.org ([208.118.235.92]:56734) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btArO-0001u1-20 for 24640@debbugs.gnu.org; Sun, 09 Oct 2016 05:57:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btArE-0006Rg-Er for 24640@debbugs.gnu.org; Sun, 09 Oct 2016 05:57:29 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60969) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btArE-0006RZ-Bi; Sun, 09 Oct 2016 05:57:24 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4284 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1btArD-0008Qo-F9; Sun, 09 Oct 2016 05:57:23 -0400 Date: Sun, 09 Oct 2016 12:57:34 +0300 Message-Id: <83r37pg7zl.fsf@gnu.org> From: Eli Zaretskii To: Reuben Thomas In-reply-to: (message from Reuben Thomas on Sun, 9 Oct 2016 08:45:08 +0100) Subject: Re: bug#24640: Crashes in 25.1 References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> <83vax2f1e5.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.7 (-------) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.7 (-------) > From: Reuben Thomas > Date: Sun, 9 Oct 2016 08:45:08 +0100 > Cc: 24640@debbugs.gnu.org > > The only efficient way to speed up debugging (or rather to make sure > it succeeds at all) is for you to come up with a reproducible recipe > and post here all the files needed for reproducing the crashes. > > ​That would seem to require me to bisect my .desktop and potentially post dozens of personal files, so doesn't > seem feasible.​ If you just start a fresh session, save its desktop, then restart it, while using the lazy-load feature, does it start normally? Maybe all that's needed is to do this, with no personal files involved. > I thought it might be faster for you to drive a debugging session live than to engage in > back-and-forth by email. It would require me to explain too many things, so it won't be efficient enough. > >From what I see in the backtraces, your setup fires a timer that runs > some complicated Lisp, and that Lisp somehow corrupts some Lisp > objects, which then cause crashes during GC. > > ​You make it sound as though this is some arcane personal setup, when in fact I am simply using desktop.el! So do I, but it never crashes for me. Nor did we have such crash reports until now. So there's something you do that I and others don't, although I didn't mean (and didn't say AFAIK) that it's something arcane. > And the first step is > to stop using an optimized build, because it makes debugging much > harder if not impossible. > > I'll see if, having rebuilt from source without optimisation, the bug still fires.​ > > If you are willing to try the debugging yourself, there's some advice > in etc/DEBUG (search for "Debugging problems which happen in GC"). > > ​I'll have a look.​ Thanks. > Do I understand correctly that this worked for you with Emacs 24.5? > > ​Yes, the identical setup loads fine in 24.5. I've never seen this sort of crash before.​ Does Emacs crash when restoring a desktop file written by Emacs 24.5, or only when it restores files written by Emacs 25? From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 09 16:21:10 2016 Received: (at 24640) by debbugs.gnu.org; 9 Oct 2016 20:21:10 +0000 Received: from localhost ([127.0.0.1]:50254 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btKas-0005UQ-8v for submit@debbugs.gnu.org; Sun, 09 Oct 2016 16:21:10 -0400 Received: from mail-lf0-f42.google.com ([209.85.215.42]:33711) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btKap-0005U4-VT for 24640@debbugs.gnu.org; Sun, 09 Oct 2016 16:21:08 -0400 Received: by mail-lf0-f42.google.com with SMTP id x79so90344370lff.0 for <24640@debbugs.gnu.org>; Sun, 09 Oct 2016 13:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2fv+sdwV0EwxCpz0sjdOMemLaN7GtzKG4z9j8Sg4A+A=; b=QZL/I58UUgv/GRqQ5ixT8Gcai6rvATN3YWzJwKkLlHlaWdvKD4JJjstb4oh/41di7t hO3tbzca+SfpDg7O0zuYbamDssbOZ7SuEd3l58qDUdggZgFh4bTQyq/2zBQR9rI52deH whKnh06hwxWHTl2Ub3fRlPKN5hf8dVOEyN5Dg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2fv+sdwV0EwxCpz0sjdOMemLaN7GtzKG4z9j8Sg4A+A=; b=PlWkxIgsGhD8d+bbb3MqBUt4/ssNo77ur2G72+pWgHg150MUAymJTkxwpWkCSiGfIu hruy/Xp71+f956iIc2HYeWFzpbWCVpgKOPSReN88KrrDR+WIp0S3jlB04mHYkFZ9Dl6v B3b2PMBgzk79gWf7EDL7czrChNgq7JlByUadakfC8ZTSgAa084jd66LcfAUPH8ZMDFYF wU8jDIJuSHgrya2RgQOM35tjQzUhpSByyadu1OtOeJr0ZAQmw4DIymCpCmWKQTTgOij1 BK/ETht1xMtm3N/3fH4ZZXKAN8reAiWGngLnYh4pqUwLDe0cBaxdl8NxvbrtcUDTogTx /uSA== X-Gm-Message-State: AA6/9RnxSB18OT9I/ENBcUudHfZxJwXBXtGzTILUinJ9G/qbWRB1IoPY8LMueEhKnULIj7EVrr15KcaSbEq6VXqe X-Received: by 10.25.234.141 with SMTP id y13mr9539888lfi.25.1476044461663; Sun, 09 Oct 2016 13:21:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.66.211 with HTTP; Sun, 9 Oct 2016 13:21:01 -0700 (PDT) In-Reply-To: <83r37pg7zl.fsf@gnu.org> References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> <83vax2f1e5.fsf@gnu.org> <83r37pg7zl.fsf@gnu.org> From: Reuben Thomas Date: Sun, 9 Oct 2016 21:21:01 +0100 Message-ID: Subject: Re: bug#24640: Crashes in 25.1 To: Eli Zaretskii Content-Type: multipart/alternative; boundary=94eb2c0c894ccf7d96053e7461e1 X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) --94eb2c0c894ccf7d96053e7461e1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 9 October 2016 at 10:57, Eli Zaretskii wrote: > > From: Reuben Thomas > > Date: Sun, 9 Oct 2016 08:45:08 +0100 > > Cc: 24640@debbugs.gnu.org > > > > The only efficient way to speed up debugging (or rather to make sure > > it succeeds at all) is for you to come up with a reproducible recipe > > and post here all the files needed for reproducing the crashes. > > > > =E2=80=8BThat would seem to require me to bisect my .desktop and potent= ially > post dozens of personal files, so doesn't > > seem feasible.=E2=80=8B > > If you just start a fresh session, save its desktop, then restart it, > while using the lazy-load feature, does it start normally? Maybe all > that's needed is to do this, with no personal files involved. > =E2=80=8BIt starts normally, unfortunately. =E2=80=8B=E2=80=8B > > And the first step is > > to stop using an optimized build, because it makes debugging much > > harder if not impossible. > > > > I'll see if, having rebuilt from source without optimisation, the bug > still fires.=E2=80=8B > =E2=80=8BI rebuilt with the options suggested in etc/DEBUG, and couldn't ge= t it to crash. =E2=80=8B I then tried building with -Og instead of -O0, as suggested in et= c/DEBUG. Still no crash. (I ran each binary under gdb 3 times, as when it crashes it crashes more than once every 3 times I run it.) I tried building with -O2: it crashes again. Now that it is built with the same options as etc/DEBUG, except for -O2, is that more useful? =E2=80=8BI tried running Emacs with valgrind, but that just quickly bails o= ut with "memory exhausted". > If you are willing to try the debugging yourself, there's some advice > > in etc/DEBUG (search for "Debugging problems which happen in GC"). > > > > =E2=80=8BI'll have a look.=E2=80=8B > > Thanks. > =E2=80=8BSorry: having had a look, the reconstruction of Lisp data structur= es looks like more than I have time for at present. > > Do I understand correctly that this worked for you with Emacs 24.5? > > > > =E2=80=8BYes, the identical setup loads fine in 24.5. I've never seen t= his sort > of crash before.=E2=80=8B > > Does Emacs crash when restoring a desktop file written by Emacs 24.5, > or only when it restores files written by Emacs 25? > =E2=80=8BBoth. --=20 http://rrt.sc3d.org --94eb2c0c894ccf7d96053e7461e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = 9 October 2016 at 10:57, Eli Zaretskii <eliz@gnu.org> wrote:
<= /div>
> From: Reuben Thomas <rrt@sc3d.org>
> Date: Sun, 9 Oct 2016 08:45:08 +0100
> Cc: 24640@d= ebbugs.gnu.org
>
>=C2=A0 The only efficient way to speed up debugging (or rather to make = sure
>=C2=A0 it succeeds at all) is for you to come up with a reproducible re= cipe
>=C2=A0 and post here all the files needed for reproducing the crashes.<= br> >
> =E2=80=8BThat would seem to require me to bisect my .desktop and poten= tially post dozens of personal files, so doesn't
> seem feasible.=E2=80=8B

If you just start a fresh session, save its desktop, then restart it= ,
while using the lazy-load feature, does it start normally?=C2=A0 Maybe all<= br> that's needed is to do this, with no personal files involved.

=E2=80=8BIt starts normally, unfortunately.
=E2=80=8B=E2=80=8B
>=C2=A0 And the first step is
>=C2=A0 to stop using an optimized build, because it makes debugging muc= h
>=C2=A0 harder if not impossible.
>
> I'll see if, having rebuilt from source without optimisation, the = bug still fires.=E2=80=8B

=E2=80=8BI = rebuilt with the options suggested in etc/DEBUG, and couldn't get it to= crash.
=E2=80= =8B I then tried building with -Og instead of -O0, as suggested in etc/DEBU= G. Still no crash. (I ran each binary under gdb 3 times, as when it crashes= it crashes more than once every 3 times I run it.) I tried building with -= O2: it crashes again. Now that it is built with the same options as etc/DEB= UG, except for -O2, is that more useful?

=E2=80=8BI tried runnin= g Emacs with valgrind, but that just quickly bails out with "memory ex= hausted".

>=C2=A0 If you are willing to try the debugging yourself, there's so= me advice
>=C2=A0 in etc/DEBUG (search for "Debugging problems which happen i= n GC").
>
> =E2=80=8BI'll have a look.=E2=80=8B

Thanks.

=E2=80=8BSorry: having had a look, the recon= struction of Lisp data structures looks like more than I have time for at p= resent.
=C2=A0
&g= t;=C2=A0 Do I understand correctly that this worked for you with Emacs 24.5= ?
>
> =E2=80=8BYes, the identical setup loads fine in 24.5. I've never s= een this sort of crash before.=E2=80=8B

Does Emacs crash when restoring a desktop file written by Emacs 24.5= ,
or only when it restores files written by Emacs 25?

=E2=80=8BBoth.

--
http://rrt.sc3d.org
--94eb2c0c894ccf7d96053e7461e1-- From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 10 02:15:42 2016 Received: (at 24640) by debbugs.gnu.org; 10 Oct 2016 06:15:42 +0000 Received: from localhost ([127.0.0.1]:50431 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btTsD-0002qu-RS for submit@debbugs.gnu.org; Mon, 10 Oct 2016 02:15:42 -0400 Received: from eggs.gnu.org ([208.118.235.92]:51854) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btTsB-0002qh-Qe for 24640@debbugs.gnu.org; Mon, 10 Oct 2016 02:15:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btTs3-0004fk-H8 for 24640@debbugs.gnu.org; Mon, 10 Oct 2016 02:15:34 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43267) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btTs3-0004et-EF; Mon, 10 Oct 2016 02:15:31 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1893 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1btTs1-0007yz-Gz; Mon, 10 Oct 2016 02:15:29 -0400 Date: Mon, 10 Oct 2016 09:15:42 +0300 Message-Id: <83y41wenld.fsf@gnu.org> From: Eli Zaretskii To: Reuben Thomas In-reply-to: (message from Reuben Thomas on Sun, 9 Oct 2016 21:21:01 +0100) Subject: Re: bug#24640: Crashes in 25.1 References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> <83vax2f1e5.fsf@gnu.org> <83r37pg7zl.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.7 (-------) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.7 (-------) > From: Reuben Thomas > Date: Sun, 9 Oct 2016 21:21:01 +0100 > Cc: 24640@debbugs.gnu.org > > ​I rebuilt with the options suggested in etc/DEBUG, and couldn't get it to crash. > ​ I then tried building with -Og instead of -O0, as suggested in etc/DEBUG. Still no crash. (I ran each binary > under gdb 3 times, as when it crashes it crashes more than once every 3 times I run it.) I tried building with > -O2: it crashes again. Now that it is built with the same options as etc/DEBUG, except for -O2, is that more > useful? I'm not sure. What compiler switches yo used, and what is your GCC version? > > If you are willing to try the debugging yourself, there's some advice > > in etc/DEBUG (search for "Debugging problems which happen in GC"). > > > > ​I'll have a look.​ > > Thanks. > > ​Sorry: having had a look, the reconstruction of Lisp data structures looks like more than I have time for at > present. Can you give me a shell login to your machine, and set it up so that after a login I could connect to the GDB session with a crashed Emacs? SSH is fine. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 10 12:12:45 2016 Received: (at 24640) by debbugs.gnu.org; 10 Oct 2016 16:12:45 +0000 Received: from localhost ([127.0.0.1]:51382 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btdC1-0003dR-Df for submit@debbugs.gnu.org; Mon, 10 Oct 2016 12:12:45 -0400 Received: from mail-lf0-f50.google.com ([209.85.215.50]:33884) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btdBz-0003dC-Hc for 24640@debbugs.gnu.org; Mon, 10 Oct 2016 12:12:44 -0400 Received: by mail-lf0-f50.google.com with SMTP id b81so133188206lfe.1 for <24640@debbugs.gnu.org>; Mon, 10 Oct 2016 09:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t3FxkObE6NtHb9/WsBgawE/Fuu2OeBu+GxhjsQCQ2RY=; b=WjzWfZ2BP3Ks2MqWFOoF9aRJUDSsFWraQWPRgfN/Zf3gCFie291He/ZrzmqdGILLYU YHcuoiwvCm4AtgMPmUGBVXSJKPp831iiQU1QFhsggLFskinxnknHnqbFIWV2dBZ3I2Zy NWc8SMEGlSGx+U4wmhScNifUQAc0myAILIrE0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t3FxkObE6NtHb9/WsBgawE/Fuu2OeBu+GxhjsQCQ2RY=; b=WkgCoQR1TkwxuIfkLZnuF57Jrh3FfIMRSGRsmW+jJwhHNic1aE/rzegdx9WnOlPja0 TUK8jntzuu0PCId0vaw3pUgiPuJ1gdsVxNR/opaDt0CgEZuKM1tdKR8WYMmLSGgBaLMO Lw94PVF0UhJZX5OCouclW9odjoV+3mCmLd9yXvmmHFbwHB6iDw4hM+f61YtLAKRjdIH5 dHNIZoy0pEn+A++UERknQb2ggJ7XM+gClw35vKlM4imuWjZjsrI0RJ2sXp/N4RGcdynd sbd4Ar4+3RoXUC9hcAveudUSlcsNieVfCnonnG2/uJn7NsSYGDa3TOBwQFwMNFXZRKLb cfxQ== X-Gm-Message-State: AA6/9RncHc+Dk4y1JEHmv/4QCKnxFBwT7i4E8k9wfm+FrdhdpEzvq2k12vg5X0uTz893eLb0FabxoWUOxSYHWm0I X-Received: by 10.25.234.141 with SMTP id y13mr12697547lfi.25.1476115957288; Mon, 10 Oct 2016 09:12:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.66.211 with HTTP; Mon, 10 Oct 2016 09:12:36 -0700 (PDT) In-Reply-To: <83y41wenld.fsf@gnu.org> References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> <83vax2f1e5.fsf@gnu.org> <83r37pg7zl.fsf@gnu.org> <83y41wenld.fsf@gnu.org> From: Reuben Thomas Date: Mon, 10 Oct 2016 17:12:36 +0100 Message-ID: Subject: Re: bug#24640: Crashes in 25.1 To: Eli Zaretskii Content-Type: multipart/alternative; boundary=94eb2c0c894c482825053e85079b X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) --94eb2c0c894c482825053e85079b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10 October 2016 at 07:15, Eli Zaretskii wrote: > > I'm not sure. What compiler switches yo used, and what is your GCC > version? > =E2=80=8B$ ./config.status --config '--enable-checking=3Dyes,glyphs' '--enable-check-lisp-object-type' 'CFLAGS=3D-O2 -g3' 'PKG_CONFIG_PATH=3D/home/rrt/.local/lib/x86_64-linux-gnu/pkgconfig:/home/rr= t/.local/share/pkgconfig' =E2=80=8B$=E2=80=8B gcc --version gcc-5.real (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609 =E2=80=8B > Can you give me a shell login to your machine, and set it up so that > after a login I could connect to the GDB session with a crashed Emacs? > SSH is fine. > =E2=80=8BYes, no problem. I'll contact you privately about this. --=20 http://rrt.sc3d.org --94eb2c0c894c482825053e85079b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = 10 October 2016 at 07:15, Eli Zaretskii <eliz@gnu.org> wrote:
=

I'm not sure.=C2=A0 What compiler switches yo used, and what is = your GCC
version?

= =E2=80=8B$ ./config.status --config
'= --enable-checking=3Dyes,glyphs' '--enable-check-lisp-object-type= 9; 'CFLAGS=3D-O2 -g3' 'PKG_CONFIG_PATH=3D/home/rrt/.local/lib/x= 86_64-linux-gnu/pkgconfig:/home/rrt/.local/share/pkgconfig'
<= div class=3D"gmail_default" style=3D"font-size:small;display:inline">=E2=80= =8B$=E2=80=8B
=C2=A0gcc --version
gcc-5.real (Ubuntu 5.4.0-6= ubuntu1~16.04.2) 5.4.0 20160609
=E2=80=8B
Can you give me a shell login to your machine, = and set it up so that
after a login I could connect to the GDB session with a crashed Emacs?
SSH is fine.

=E2=80=8BYes, no problem. I'll contact you= privately about this.

--
http://= rrt.sc3d.org
--94eb2c0c894c482825053e85079b-- From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 10 12:33:51 2016 Received: (at 24640) by debbugs.gnu.org; 10 Oct 2016 16:33:51 +0000 Received: from localhost ([127.0.0.1]:51388 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btdWR-00048T-9C for submit@debbugs.gnu.org; Mon, 10 Oct 2016 12:33:51 -0400 Received: from eggs.gnu.org ([208.118.235.92]:33353) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btdWQ-00048H-AE for 24640@debbugs.gnu.org; Mon, 10 Oct 2016 12:33:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btdWH-0004rA-T4 for 24640@debbugs.gnu.org; Mon, 10 Oct 2016 12:33:45 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51614) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btdWH-0004qs-Pa; Mon, 10 Oct 2016 12:33:41 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4042 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1btdWF-0007Tm-4r; Mon, 10 Oct 2016 12:33:40 -0400 Date: Mon, 10 Oct 2016 19:33:34 +0300 Message-Id: <834m4kduzl.fsf@gnu.org> From: Eli Zaretskii To: Reuben Thomas In-reply-to: (message from Reuben Thomas on Mon, 10 Oct 2016 17:12:36 +0100) Subject: Re: bug#24640: Crashes in 25.1 References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> <83vax2f1e5.fsf@gnu.org> <83r37pg7zl.fsf@gnu.org> <83y41wenld.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.3 (-----) > From: Reuben Thomas > Date: Mon, 10 Oct 2016 17:12:36 +0100 > Cc: 24640@debbugs.gnu.org > > I'm not sure. What compiler switches yo used, and what is your GCC > version? > > ​$ ./config.status --config > '--enable-checking=yes,glyphs' '--enable-check-lisp-object-type' 'CFLAGS=-O2 -g3' > 'PKG_CONFIG_PATH=/home/rrt/.local/lib/x86_64-linux-gnu/pkgconfig:/home/rrt/.local/share/pkgconfig' > ​$​ > gcc --version > gcc-5.real (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609 It would be better to use CFLAGS='-O2 -gdwarf-4 -g3'. > Can you give me a shell login to your machine, and set it up so that > after a login I could connect to the GDB session with a crashed Emacs? > SSH is fine. > > ​Yes, no problem. I'll contact you privately about this. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 10 13:01:43 2016 Received: (at 24640) by debbugs.gnu.org; 10 Oct 2016 17:01:43 +0000 Received: from localhost ([127.0.0.1]:51411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btdxO-0004od-SO for submit@debbugs.gnu.org; Mon, 10 Oct 2016 13:01:43 -0400 Received: from mail-lf0-f54.google.com ([209.85.215.54]:34683) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btdxN-0004oQ-9F for 24640@debbugs.gnu.org; Mon, 10 Oct 2016 13:01:42 -0400 Received: by mail-lf0-f54.google.com with SMTP id b81so135048346lfe.1 for <24640@debbugs.gnu.org>; Mon, 10 Oct 2016 10:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qsyXLZAwGyBQHwn5ompxz+azQYovHbfKbYtNsoEssEE=; b=BTemJzKLaHb0jkukwjpdTykGJj/iFZIDRvelRsj59va8Bg7rKXOfXQDCfNKxBmlqPM 42CLcEV13a98lSSL+P0+PHE7Ts0DZV645af6abYzlgBCb+Kf3mMrlamajW/ptdyiDkuN 3jCgA2fzKfACG7m1NWwNQqY6ddr8Y/WIURyJY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qsyXLZAwGyBQHwn5ompxz+azQYovHbfKbYtNsoEssEE=; b=i4dRJitjDPcI0gLnACbcC4dbTxnicnzI7ko0lLxOFqYSW+akCbkRweQ9qEBl7AtrY7 cQYiI7ILDHdNkvQ1798AyGJhl765Aig/I8dh/dZr9HbWydwpY+5FqV+0gJD/sZamA5ET 5lP7J7Sw/Ti0H2csetMdVFzmYK/yKnv1CcbwaW7TWDTDCO2xY/GpEGafgCUeBLrTVxoA Q8XUQdg39dlqAGevVvLPkgZ0Tn/dOH5D+VuLBjFL+Rnkx1C5nVo8CGofk0OnvTNb9Odj K15tXo81sYeSthWIJwuyGJ4v3AaKVU3zsT/TTdvuvNAYH7hew25h3gsUIkvHd3PnqGL1 ko6g== X-Gm-Message-State: AA6/9RlhXSQAbe3mtMS1zbd/Iz43+r+FFNAi8SCjcSwA4j9pWU1N6G9cKwUM4/TYR4FKMqFFMTXGDXQmCZL6zbc6 X-Received: by 10.25.129.147 with SMTP id c141mr4766373lfd.171.1476118895210; Mon, 10 Oct 2016 10:01:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.66.211 with HTTP; Mon, 10 Oct 2016 10:01:34 -0700 (PDT) In-Reply-To: <834m4kduzl.fsf@gnu.org> References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> <83vax2f1e5.fsf@gnu.org> <83r37pg7zl.fsf@gnu.org> <83y41wenld.fsf@gnu.org> <834m4kduzl.fsf@gnu.org> From: Reuben Thomas Date: Mon, 10 Oct 2016 18:01:34 +0100 Message-ID: Subject: Re: bug#24640: Crashes in 25.1 To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a113eae76654ac9053e85b6ae X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a113eae76654ac9053e85b6ae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10 October 2016 at 17:33, Eli Zaretskii wrote: > > From: Reuben Thomas > > Date: Mon, 10 Oct 2016 17:12:36 +0100 > > Cc: 24640@debbugs.gnu.org > > > > I'm not sure. What compiler switches yo used, and what is your GCC > > version? > > > > =E2=80=8B$ ./config.status --config > > '--enable-checking=3Dyes,glyphs' '--enable-check-lisp-object-type' > 'CFLAGS=3D-O2 -g3' > > 'PKG_CONFIG_PATH=3D/home/rrt/.local/lib/x86_64-linux-gnu/ > pkgconfig:/home/rrt/.local/share/pkgconfig' > > =E2=80=8B$=E2=80=8B > > gcc --version > > gcc-5.real (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609 > > It would be better to use CFLAGS=3D'-O2 -gdwarf-4 -g3'. > =E2=80=8BIs that something that should be mentioned in etc/DEBUG, or is it = specific to the problems of debugging optimized code? (Or perhaps both!) --=20 http://rrt.sc3d.org --001a113eae76654ac9053e85b6ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = 10 October 2016 at 17:33, Eli Zaretskii <eliz@gnu.org> wrote:
=
> From: Reuben Thomas <rrt@sc3d.org>
> Date: Mon, 10 Oct 2016 17:12:36 +0100
> Cc: 24640@debbugs.gnu.org=
>
>=C2=A0 I'm not sure. What compiler switches yo used, and what is yo= ur GCC
>=C2=A0 version?
>
> =E2=80=8B$ ./config.status --config
> '--enable-checking=3Dyes,glyphs' '--enable-check-lisp-obje= ct-type' 'CFLAGS=3D-O2 -g3'
> 'PKG_CONFIG_PATH=3D/home/rrt/.local/lib/x86_64-linux-gnu/pkgconfig:/home/rrt/.local/share/pkgconfig'
> =E2=80=8B$=E2=80=8B
> gcc --version
> gcc-5.real (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609

It would be better to use CFLAGS=3D'-O2 -gdwarf-4 -g3'.
<= /blockquote>

=E2=80=8BIs that something that should b= e mentioned in etc/DEBUG, or is it specific to the problems of debugging op= timized code? (Or perhaps both!)

--
http://rrt.sc3d.org
--001a113eae76654ac9053e85b6ae-- From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 10 13:05:38 2016 Received: (at 24640) by debbugs.gnu.org; 10 Oct 2016 17:05:38 +0000 Received: from localhost ([127.0.0.1]:51416 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bte1C-0004uS-Dm for submit@debbugs.gnu.org; Mon, 10 Oct 2016 13:05:38 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41235) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bte1A-0004uD-Pu for 24640@debbugs.gnu.org; Mon, 10 Oct 2016 13:05:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bte10-0001yu-Ue for 24640@debbugs.gnu.org; Mon, 10 Oct 2016 13:05:31 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51918) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bte10-0001yq-RJ; Mon, 10 Oct 2016 13:05:26 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4109 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bte0z-0001gJ-B2; Mon, 10 Oct 2016 13:05:26 -0400 Date: Mon, 10 Oct 2016 20:05:20 +0300 Message-Id: <8337k4dtin.fsf@gnu.org> From: Eli Zaretskii To: Reuben Thomas In-reply-to: (message from Reuben Thomas on Mon, 10 Oct 2016 18:01:34 +0100) Subject: Re: bug#24640: Crashes in 25.1 References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> <83vax2f1e5.fsf@gnu.org> <83r37pg7zl.fsf@gnu.org> <83y41wenld.fsf@gnu.org> <834m4kduzl.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.3 (-----) > From: Reuben Thomas > Date: Mon, 10 Oct 2016 18:01:34 +0100 > Cc: 24640@debbugs.gnu.org > > It would be better to use CFLAGS='-O2 -gdwarf-4 -g3'. > > ​Is that something that should be mentioned in etc/DEBUG It is there already. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 10 13:07:05 2016 Received: (at 24640) by debbugs.gnu.org; 10 Oct 2016 17:07:05 +0000 Received: from localhost ([127.0.0.1]:51420 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bte2a-0004wv-PM for submit@debbugs.gnu.org; Mon, 10 Oct 2016 13:07:05 -0400 Received: from mail-lf0-f44.google.com ([209.85.215.44]:35338) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bte2Y-0004wO-F3 for 24640@debbugs.gnu.org; Mon, 10 Oct 2016 13:07:02 -0400 Received: by mail-lf0-f44.google.com with SMTP id l131so130920549lfl.2 for <24640@debbugs.gnu.org>; Mon, 10 Oct 2016 10:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N7CKfywN11rid8oCbQsORc3RP25ncgA+7Z8b1BObT60=; b=dEfpWbAGuS5PSEvnA2icftaKFkTlSdJrWsG5VqwbtvQNEQHNb3KhSxlm8tsT5IyOJC iU5o5Lidj2oXa8govz3hJkZf1FjeXQls+4Q7mPmuay2rrN0tKuEVmi5hOwCh7z6h7DZu PML0mOouXFX7SN265yCP8AeAD9EGcLKze1nI4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N7CKfywN11rid8oCbQsORc3RP25ncgA+7Z8b1BObT60=; b=LGsc+JztoYre3dOGdSS/eiWOCMe73+YOR/HzZEDSM2cEFBiKfP0SBwweMLGu+k/2/1 pwaXpMTPFcH9LaOdL6qvgk7bsYb2wpqKQ/ErEqezfQg02j8aPu6PXtkm2Yi+EOO/93Gl /jCXbBEXGceItr22/DPLLF76YBABOjS9ysvzRqEtclIBeovWJY3vnuYkPNPCZ7X/OiOX hCOHC+DR0U4CtbX8w7DBTtwi50dCJENTt5FS27YPsUjhZ+e96N8t3QNemRNmT5NmQFkZ 0+Hsx4zZFalIQ1S5R9yF6rb+z0rY4UC0kCeSa6L9ywRcGS78/sv/QfXewwuYPUxnyjGp RVUA== X-Gm-Message-State: AA6/9RkoSULAKJ29b/V08p9wKlMbGy1wvKL+dUvbHC7TCNnOsrsIF8m6V/bEjjejKu8rDS2VcU7Yg6DDlWBMbZ2H X-Received: by 10.25.34.11 with SMTP id i11mr14996176lfi.119.1476119215624; Mon, 10 Oct 2016 10:06:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.66.211 with HTTP; Mon, 10 Oct 2016 10:06:54 -0700 (PDT) In-Reply-To: <8337k4dtin.fsf@gnu.org> References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> <83vax2f1e5.fsf@gnu.org> <83r37pg7zl.fsf@gnu.org> <83y41wenld.fsf@gnu.org> <834m4kduzl.fsf@gnu.org> <8337k4dtin.fsf@gnu.org> From: Reuben Thomas Date: Mon, 10 Oct 2016 18:06:54 +0100 Message-ID: Subject: Re: bug#24640: Crashes in 25.1 To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a113aa9107e76a4053e85c9fc X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) --001a113aa9107e76a4053e85c9fc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10 October 2016 at 18:05, Eli Zaretskii wrote: > > From: Reuben Thomas > > Date: Mon, 10 Oct 2016 18:01:34 +0100 > > Cc: 24640@debbugs.gnu.org > > > > It would be better to use CFLAGS=3D'-O2 -gdwarf-4 -g3'. > > > > =E2=80=8BIs that something that should be mentioned in etc/DEBUG > > It is there already. > =E2=80=8BIndeed, I hadn't read far enough. --=20 http://rrt.sc3d.org --001a113aa9107e76a4053e85c9fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = 10 October 2016 at 18:05, Eli Zaretskii <eliz@gnu.org> wrote:
=
> From: Reuben Thomas <rrt@sc3d.org>
> Date: Mon, 10 Oct 2016 18:01:34 +0100
> Cc: 24640@debbugs.gnu.org=
>
>=C2=A0 It would be better to use CFLAGS=3D'-O2 -gdwarf-4 -g3'.<= br> >
> =E2=80=8BIs that something that should be mentioned in etc/DEBUG

It is there already.

=E2=80=8BIndeed, I hadn't read far enough.

--
http://rrt.sc3d.org
--001a113aa9107e76a4053e85c9fc-- From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 11 07:59:38 2016 Received: (at 24640) by debbugs.gnu.org; 11 Oct 2016 11:59:38 +0000 Received: from localhost ([127.0.0.1]:51788 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btvic-00086p-Ml for submit@debbugs.gnu.org; Tue, 11 Oct 2016 07:59:38 -0400 Received: from eggs.gnu.org ([208.118.235.92]:52349) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btvib-00086c-2R for 24640@debbugs.gnu.org; Tue, 11 Oct 2016 07:59:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btviR-00022C-Rb for 24640@debbugs.gnu.org; Tue, 11 Oct 2016 07:59:31 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36326) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btviR-00021Z-Nk; Tue, 11 Oct 2016 07:59:27 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1344 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1btviP-0007nI-3i; Tue, 11 Oct 2016 07:59:26 -0400 Date: Tue, 11 Oct 2016 14:59:07 +0300 Message-Id: <83lgxvcd10.fsf@gnu.org> From: Eli Zaretskii To: Reuben Thomas In-reply-to: (message from Reuben Thomas on Mon, 10 Oct 2016 22:35:55 +0100) Subject: Re: bug#24640: Crashes in 25.1 References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> <83vax2f1e5.fsf@gnu.org> <83r37pg7zl.fsf@gnu.org> <83y41wenld.fsf@gnu.org> <834m4kduzl.fsf@gnu.org> <831szodsus.fsf@gnu.org> <83zimccbzr.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.3 (-----) Thanks, I've done some initial debugging. The crash seems to be related to the variable read_objects, defined and used by lread.c. It is an alist of objects read with the #n=object form. One of its members is a corrupted Lisp object, which causes the GC crash when this object is examined. read_objects is a global variable, so it could be that some code invoked in the middle of reading one #n=object form clobbers it by reading another. However, I don't immediately see such forms in the few of your many init files I looked in. Do you have any idea where this could come from? One place they are abundant is in *.elc files, so maybe some recursive load together with the timer-based lazy desktop operation does that? I don't really have a working hypothesis for now. I'm not an expert on X tricks -- is there any way you can trick Emacs to start a GUI session when I invoke it via SSH? Some trick with the value of DISPLAY in the environment, perhaps? I don't need to see what Emacs displays, just run it live under GDB. The problem that causes the crash happens before the code I see in the backtrace -- that code just triggers GC. So it would be beneficial to run Emacs under GDB and try to see, for example, what code changes read_objects and how (assuming it is not changed to a non-nil value too many times). Can this be arranged? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 11 10:09:00 2016 Received: (at 24640) by debbugs.gnu.org; 11 Oct 2016 14:09:00 +0000 Received: from localhost ([127.0.0.1]:52264 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btxjm-0002qY-Fi for submit@debbugs.gnu.org; Tue, 11 Oct 2016 10:09:00 -0400 Received: from mail-lf0-f53.google.com ([209.85.215.53]:34153) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btxjg-0002qF-7G for 24640@debbugs.gnu.org; Tue, 11 Oct 2016 10:08:56 -0400 Received: by mail-lf0-f53.google.com with SMTP id b81so42572800lfe.1 for <24640@debbugs.gnu.org>; Tue, 11 Oct 2016 07:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Lm6YSj/eRbRc2VOWFP8ecctp3J+lCoOSrGANKTv4Rr0=; b=hhhSMzlIOLkNUZuIhVpky1hoUjvv1Y0ItdpV7CmHnqZfRKOGPg/mZgxZdlUUZ1mcBc 1sNqzCRm+bTAmEaMrHwBbw0Es5rnLp8ymatdV7yRS5tyVKGMcReI4meFrlYQI0W+XVqH K4iCWa/OGSPx3PF/aQKZdnvT8c7KKCOLWeYrY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Lm6YSj/eRbRc2VOWFP8ecctp3J+lCoOSrGANKTv4Rr0=; b=XmnpLAHdpgrP7R3fIfGSnR9a0UWjbIPrUOqGPHlfjdEClvPNo/0HwFb7KeCk+O/FOb d4vwTg1KjKx+4GqbTMMD1fxUqwtqAYKerzjQm6VN5nLP3Ck29yB5Bdh5bTr4UEuvvRe6 WlsZZxQd1clY71vda8GmgjtbPXThhZBiGTB48H5awSlvN2jUpLXI7eBIuwFj7Ngs4pgr fpEOnSpzVT+tWloa72knkZ7SbBCW+bRyRdE/q3SBNJo/1jDiR0KjBvvE/OhiX6ueiGVZ 0so8Qn61Cvmng21zi8w5wAzr/nlneRN5H2Cj/QxPTLkb9qom9RT2hX5w/d1kXgPs1nak h9ZA== X-Gm-Message-State: AA6/9RlOBGRhGoY/jpyyYlmYw2wNJnDikahPMwdri+JWZy1uYWsykrikcpLfW8dv+coO4MioP6njxNBYYMpX+JTG X-Received: by 10.25.154.132 with SMTP id c126mr3092029lfe.58.1476194926232; Tue, 11 Oct 2016 07:08:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.66.211 with HTTP; Tue, 11 Oct 2016 07:08:45 -0700 (PDT) In-Reply-To: <83lgxvcd10.fsf@gnu.org> References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> <83vax2f1e5.fsf@gnu.org> <83r37pg7zl.fsf@gnu.org> <83y41wenld.fsf@gnu.org> <834m4kduzl.fsf@gnu.org> <831szodsus.fsf@gnu.org> <83zimccbzr.fsf@gnu.org> <83lgxvcd10.fsf@gnu.org> From: Reuben Thomas Date: Tue, 11 Oct 2016 15:08:45 +0100 Message-ID: Subject: Re: bug#24640: Crashes in 25.1 To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a11401a2c32934a053e976ae1 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --001a11401a2c32934a053e976ae1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11 October 2016 at 12:59, Eli Zaretskii wrote: > Thanks, I've done some initial debugging. The crash seems to be > related to the variable read_objects, defined and used by lread.c. It > is an alist of objects read with the #n=3Dobject form. One of its > members is a corrupted Lisp object, which causes the GC crash when > this object is examined. > =E2=80=8BGood stuff! > read_objects is a global variable, so it could be that some code > invoked in the middle of reading one #n=3Dobject form clobbers it by > reading another. However, I don't immediately see such forms in the > few of your many init files I looked in. =E2=80=8B Indeed, I'm not aware of having used such a form myself, nor can I find one by grepping. > Do you have any idea where > =E2=80=8B =E2=80=8B > this could come from? =E2=80=8BNo, sorry.=E2=80=8B > One place they are abundant is in *.elc files, > so maybe some recursive load together with the timer-based lazy > desktop operation does that? I don't really have a working hypothesis > for now. > Could it be loading the undo-tree undo history? The crash always seems to happen when loading mit.tex. It tries to load the undo-tree history, fails (because the file has been changed since the history was last saved), then crashes. The undo-tree history is full of #n=3Dobject forms. I can let you have the undo-tree history file if that might help you identify the corrupted data. > I'm not an expert on X tricks -- is there any way you can trick Emacs > to start a GUI session when I invoke it via SSH? Some trick with the > value of DISPLAY in the environment, perhaps? I don't need to see > what Emacs displays, just run it live under GDB. The problem that > causes the crash happens before the code I see in the backtrace -- > that code just triggers GC. So it would be beneficial to run Emacs > under GDB and try to see, for example, what code changes read_objects > and how (assuming it is not changed to a non-nil value too many > times). Can this be arranged? > =E2=80=8BIf you use "ssh -X", you can get an X connection and Emacs will st= art a GUI session. That's the simplest thing I can think of; not really a trick at all.=E2=80=8B --=20 http://rrt.sc3d.org --001a11401a2c32934a053e976ae1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = 11 October 2016 at 12:59, Eli Zaretskii <eliz@gnu.org> wrote:
=
Thanks, I've done some initial debugging.=C2=A0 The cra= sh seems to be
related to the variable read_objects, defined and used by lread.c.=C2=A0 It=
is an alist of objects read with the #n=3Dobject form.=C2=A0 One of its
members is a corrupted Lisp object, which causes the GC crash when
this object is examined.

=E2=80=8BGood stuff!
=C2=A0
read_objects is a global vari= able, so it could be that some code
invoked in the middle of reading one #n=3Dobject form clobbers it by
reading another.=C2=A0 However, I don't immediately see such forms in t= he
few of your many init files I looked in.
=E2=80=8B
Indeed, I'm not aware of having used s= uch a form myself, nor can I find one by grepping.
=C2=A0
=C2=A0 Do you have any idea where
=E2=80=8B = =E2=80=8B
this could come from?

=E2=80=8BNo, sorry.=E2=80= =8B
=C2=A0
=C2=A0 One p= lace they are abundant is in *.elc files,
so maybe some recursive load together with the timer-based lazy
desktop operation does that?=C2=A0 I don't really have a working hypoth= esis
for now.

Could it be loading the undo-tree undo history? Th= e crash always seems to happen when loading mit.tex. It tries to load the u= ndo-tree history, fails (because the file has been changed since the histor= y was last saved), then crashes. The undo-tree history is full of #n=3Dobje= ct forms.

<= /div>
I can let you h= ave the undo-tree history file if that might help you identify the corrupte= d data.
=C2=A0
I'm = not an expert on X tricks -- is there any way you can trick Emacs
to start a GUI session when I invoke it via SSH?=C2=A0 Some trick with the<= br> value of DISPLAY in the environment, perhaps?=C2=A0 I don't need to see=
what Emacs displays, just run it live under GDB.=C2=A0 The problem that
causes the crash happens before the code I see in the backtrace --
that code just triggers GC.=C2=A0 So it would be beneficial to run Emacs under GDB and try to see, for example, what code changes read_objects
and how (assuming it is not changed to a non-nil value too many
times).=C2=A0 Can this be arranged?

=E2=80=8BIf you use &qu= ot;ssh -X", you can get an X connection and Emacs will start a GUI ses= sion. That's the simplest thing I can think of; not really a trick at a= ll.=E2=80=8B

--
http://rrt.sc3d.org
--001a11401a2c32934a053e976ae1-- From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 11 10:54:00 2016 Received: (at 24640) by debbugs.gnu.org; 11 Oct 2016 14:54:00 +0000 Received: from localhost ([127.0.0.1]:52291 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btyRM-0003te-BW for submit@debbugs.gnu.org; Tue, 11 Oct 2016 10:54:00 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37488) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btyRK-0003tP-Hu for 24640@debbugs.gnu.org; Tue, 11 Oct 2016 10:53:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btyRB-0002mH-8V for 24640@debbugs.gnu.org; Tue, 11 Oct 2016 10:53:53 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38530) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btyRB-0002ld-52; Tue, 11 Oct 2016 10:53:49 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1574 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1btyR9-0006p7-Cj; Tue, 11 Oct 2016 10:53:47 -0400 Date: Tue, 11 Oct 2016 17:53:33 +0300 Message-Id: <83k2dfc4ya.fsf@gnu.org> From: Eli Zaretskii To: Reuben Thomas In-reply-to: (message from Reuben Thomas on Tue, 11 Oct 2016 15:08:45 +0100) Subject: Re: bug#24640: Crashes in 25.1 References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> <83vax2f1e5.fsf@gnu.org> <83r37pg7zl.fsf@gnu.org> <83y41wenld.fsf@gnu.org> <834m4kduzl.fsf@gnu.org> <831szodsus.fsf@gnu.org> <83zimccbzr.fsf@gnu.org> <83lgxvcd10.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.3 (-----) > From: Reuben Thomas > Date: Tue, 11 Oct 2016 15:08:45 +0100 > Cc: 24640@debbugs.gnu.org > > read_objects is a global variable, so it could be that some code > invoked in the middle of reading one #n=object form clobbers it by > reading another. However, I don't immediately see such forms in the > few of your many init files I looked in. > > ​Indeed, I'm not aware of having used such a form myself, nor can I find one by grepping. > > Do you have any idea where > ​ ​ > this could come from? > > ​No, sorry.​ > > One place they are abundant is in *.elc files, > so maybe some recursive load together with the timer-based lazy > desktop operation does that? I don't really have a working hypothesis > for now. > > Could it be loading the undo-tree undo history? The crash always seems to happen when loading mit.tex. It > tries to load the undo-tree history, fails (because the file has been changed since the history was last saved), > then crashes. The undo-tree history is full of #n=object forms. Yes, that was also on my suspect list. > I can let you have the undo-tree history file if that might help you identify the corrupted data. Is it possible to disable this loading of undo-tree history? If so, can you disable it and see if Emacs no longer crashes? If the crashes stop when undo-tree history is not loaded, we will have to look closely at what that loading does, because the problem is probably there. The internals of undo changed in Emacs 25. > I'm not an expert on X tricks -- is there any way you can trick Emacs > to start a GUI session when I invoke it via SSH? Some trick with the > value of DISPLAY in the environment, perhaps? I don't need to see > what Emacs displays, just run it live under GDB. The problem that > causes the crash happens before the code I see in the backtrace -- > that code just triggers GC. So it would be beneficial to run Emacs > under GDB and try to see, for example, what code changes read_objects > and how (assuming it is not changed to a non-nil value too many > times). Can this be arranged? > > ​If you use "ssh -X", you can get an X connection and Emacs will start a GUI session. That's the simplest thing > I can think of; not really a trick at all.​ Yes, I know, but that requires me to have an X server here, which I don't have, and prefer not to set up. Is there some way of telling Emacs to open its display on your local terminal instead? From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 11 11:20:19 2016 Received: (at 24640) by debbugs.gnu.org; 11 Oct 2016 15:20:19 +0000 Received: from localhost ([127.0.0.1]:52303 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btyqo-0004Wb-To for submit@debbugs.gnu.org; Tue, 11 Oct 2016 11:20:19 -0400 Received: from eggs.gnu.org ([208.118.235.92]:44085) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btyqm-0004WO-RF for 24640@debbugs.gnu.org; Tue, 11 Oct 2016 11:20:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btyqb-0004MB-RE for 24640@debbugs.gnu.org; Tue, 11 Oct 2016 11:20:11 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38924) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btyqb-0004Li-Ne; Tue, 11 Oct 2016 11:20:05 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1613 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1btyqZ-00035y-VV; Tue, 11 Oct 2016 11:20:04 -0400 Date: Tue, 11 Oct 2016 18:19:51 +0300 Message-Id: <83h98idiaw.fsf@gnu.org> From: Eli Zaretskii To: rrt@sc3d.org In-reply-to: <83k2dfc4ya.fsf@gnu.org> (message from Eli Zaretskii on Tue, 11 Oct 2016 17:53:33 +0300) Subject: Re: bug#24640: Crashes in 25.1 References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> <83vax2f1e5.fsf@gnu.org> <83r37pg7zl.fsf@gnu.org> <83y41wenld.fsf@gnu.org> <834m4kduzl.fsf@gnu.org> <831szodsus.fsf@gnu.org> <83zimccbzr.fsf@gnu.org> <83lgxvcd10.fsf@gnu.org> <83k2dfc4ya.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.3 (-----) > Date: Tue, 11 Oct 2016 17:53:33 +0300 > From: Eli Zaretskii > Cc: 24640@debbugs.gnu.org > > > ​If you use "ssh -X", you can get an X connection and Emacs will start a GUI session. That's the simplest thing > > I can think of; not really a trick at all.​ > > Yes, I know, but that requires me to have an X server here, which I > don't have, and prefer not to set up. Is there some way of telling > Emacs to open its display on your local terminal instead? Alternatively, maybe you could start Emacs yourself, stop it at the beginning of 'main' (e.g. with the "start" command instead or "run"), then let me connect to the terminal where GDB runs via 'screen' or somesuch. (I don't know the details, as I almost never use 'screen', I just know that someone once provided such a possibility for me from a remore login.) TIA From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 11 11:41:26 2016 Received: (at 24640) by debbugs.gnu.org; 11 Oct 2016 15:41:26 +0000 Received: from localhost ([127.0.0.1]:52320 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btzBG-00051q-DV for submit@debbugs.gnu.org; Tue, 11 Oct 2016 11:41:26 -0400 Received: from mail-lf0-f54.google.com ([209.85.215.54]:36844) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btzBF-00051d-25 for 24640@debbugs.gnu.org; Tue, 11 Oct 2016 11:41:25 -0400 Received: by mail-lf0-f54.google.com with SMTP id b75so46627698lfg.3 for <24640@debbugs.gnu.org>; Tue, 11 Oct 2016 08:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pMCy1UEt/mxwg7h0VUxJAp6NNWozX4KKa1msJIUAF/A=; b=eQw+AxeP1skr1ysT1Ou4DjI4a1i5w1yNp7s85zgEcgPoA68U/WPnwSEsnLjb+Gp36J WTFCKb9H6Ynw3WJOzzu/CFsppxv5O/25scpIgyFahSR4x5AoFAZkbDeIV9SylLq53ZHd ozvbqnyC4vNtPhzg2mljet2IWv6pF4GAu2Gtk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pMCy1UEt/mxwg7h0VUxJAp6NNWozX4KKa1msJIUAF/A=; b=cb1wpqZET9gPtoo7v6QH59Y9Uf72FyP23FQdc1UxtqoYIAyaiL8ULSgJnB/nDInG0H GvwRPTxTaxRnG95lXKF+8UebdlNdSRLk4sLcwPE5Um2ac+Z6s9VjnpABAo/FpnDn9lbh /Efe+IgrGOS2wqJh5Eu0s52IGlCMhhqulpkF49KcJMknXzadlj/38WZyDDo29W7hawu+ qC9vBZy/p5CtRb0gzvuSHKdaMDtQWpLXs58MOywaB5ovrFC8Sn/kHj/irgA4E4a+a+dF jTy61RDejr4tI9pLEMD919VMSn8ht8T1jWJ7OtiCND4L0AARzttycn7HnBUNWPu4gOSo mV8Q== X-Gm-Message-State: AA6/9RmCJpUXDE+ofuWUu9YhSacsNlsrWDL7C2s7CgkbyNt0c8xOx3KveWYw4AbpgyJEmv50h9pdKmZhXBldo9W5 X-Received: by 10.25.234.141 with SMTP id y13mr3562801lfi.25.1476200478132; Tue, 11 Oct 2016 08:41:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.66.211 with HTTP; Tue, 11 Oct 2016 08:41:17 -0700 (PDT) In-Reply-To: <83k2dfc4ya.fsf@gnu.org> References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> <83vax2f1e5.fsf@gnu.org> <83r37pg7zl.fsf@gnu.org> <83y41wenld.fsf@gnu.org> <834m4kduzl.fsf@gnu.org> <831szodsus.fsf@gnu.org> <83zimccbzr.fsf@gnu.org> <83lgxvcd10.fsf@gnu.org> <83k2dfc4ya.fsf@gnu.org> From: Reuben Thomas Date: Tue, 11 Oct 2016 16:41:17 +0100 Message-ID: Subject: Re: bug#24640: Crashes in 25.1 To: Eli Zaretskii Content-Type: multipart/alternative; boundary=94eb2c0c894c1de4b7053e98b52e X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) --94eb2c0c894c1de4b7053e98b52e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11 October 2016 at 15:53, Eli Zaretskii wrote: > > Is it possible to disable this loading of undo-tree history? If so, > can you disable it and see if Emacs no longer crashes? If the crashes > stop when undo-tree history is not loaded, we will have to look > closely at what that loading does, because the problem is probably > there. The internals of undo changed in Emacs 25. > =E2=80=8BYes, the crashes appear to stop when I comment out (global-undo-tr= ee-mode) in vars.el. Yes, I know, but that requires me to have an X server here, which I > don't have, and prefer not to set up. Is there some way of telling > Emacs to open its display on your local terminal instead? > =E2=80=8B$ Xvfb :2 # or some other number that doesn't cause an error $ emacs -d :2=E2=80=8B --=20 http://rrt.sc3d.org --94eb2c0c894c1de4b7053e98b52e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = 11 October 2016 at 15:53, Eli Zaretskii <eliz@gnu.org> wrote:
=

Is it possible to disable this loading of undo-tree history?=C2=A0 I= f so,
can you disable it and see if Emacs no longer crashes?=C2=A0 If the crashes=
stop when undo-tree history is not loaded, we will have to look
closely at what that loading does, because the problem is probably
there.=C2=A0 The internals of undo changed in Emacs 25.

=E2= =80=8BYes, the crashes appear to stop when I comment out (global-undo-tree-= mode) in vars.el.

Yes, I know, but that req= uires me to have an X server here, which I
don't have, and prefer not to set up.=C2=A0 Is there some way of tellin= g
Emacs to open its display on your local terminal instead?

=E2=80=8B$ Xvfb :2 # or some other number that doesn't cause an erro= r
$ emacs -d :2= =E2=80=8B

--
http://rrt.sc3d.org
--94eb2c0c894c1de4b7053e98b52e-- From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 11 11:42:30 2016 Received: (at 24640) by debbugs.gnu.org; 11 Oct 2016 15:42:30 +0000 Received: from localhost ([127.0.0.1]:52325 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btzCH-00053W-QS for submit@debbugs.gnu.org; Tue, 11 Oct 2016 11:42:29 -0400 Received: from mail-lf0-f41.google.com ([209.85.215.41]:36681) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btzCG-00053K-92 for 24640@debbugs.gnu.org; Tue, 11 Oct 2016 11:42:28 -0400 Received: by mail-lf0-f41.google.com with SMTP id b75so46668948lfg.3 for <24640@debbugs.gnu.org>; Tue, 11 Oct 2016 08:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4S+m43G3QZeDFEtKdiK3P8yt6oCDy4n5bkXYhOK3Nn8=; b=5fTcfdOmqZ08ZT8dFcn90X1pLL9cCtOgSPxTMYEmfH5G16APqT5o7llcDilrWOJSt3 vm1vUqzBpxNzIlnwJGhM9b+7X3+Wt3sMHltRukpNa7exwKnlch73vED2a77Aqj1M/61U LBeqYLqzWULg3GFJuPwXH1TmpSo4w9/f5rqGc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4S+m43G3QZeDFEtKdiK3P8yt6oCDy4n5bkXYhOK3Nn8=; b=bWkRApNbdxcBGztpevQYM82lURFqchOC3so/uNXL3tcyQ3/xE0yBAf5+pldOc2H5A7 AYcMXIeZTqwG4CPf1P0I8bgLIeZsuiowRpGYnVp9IzSkQQ6DC91o9Ss+z2T4V9IqZSZ0 zFIKJ5rG1dwWqha6LMzQiWKbP8nEXCoB0b3T3Esf3ZHzV5LETnEvhkXXdxO87ZMMwnfK BDiDmOeV12V82sIYEjHu2/wywtHISBkXFILGf6YME2NcNalWRw3XyzDmTYC+r8aaGr2G rpe9a9sZmpqoXxkWYKg+tRJ+REtv5WESajCDryYS36Vdu4LUJ+6M+Jg4qP3KS0fWYQyf P0uw== X-Gm-Message-State: AA6/9Rl5xOBve/emkxrFTUNAwjmjpm2PxykhYf/qXeA+CM5JUv18GHHmYywqH7jg9wiIrhKTXEF+b7zmmO7YjhsQ X-Received: by 10.25.154.132 with SMTP id c126mr3522416lfe.58.1476200542442; Tue, 11 Oct 2016 08:42:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.66.211 with HTTP; Tue, 11 Oct 2016 08:42:21 -0700 (PDT) In-Reply-To: <83h98idiaw.fsf@gnu.org> References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> <83vax2f1e5.fsf@gnu.org> <83r37pg7zl.fsf@gnu.org> <83y41wenld.fsf@gnu.org> <834m4kduzl.fsf@gnu.org> <831szodsus.fsf@gnu.org> <83zimccbzr.fsf@gnu.org> <83lgxvcd10.fsf@gnu.org> <83k2dfc4ya.fsf@gnu.org> <83h98idiaw.fsf@gnu.org> From: Reuben Thomas Date: Tue, 11 Oct 2016 16:42:21 +0100 Message-ID: Subject: Re: bug#24640: Crashes in 25.1 To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a11401a2cf32d10053e98b8a0 X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) --001a11401a2cf32d10053e98b8a0 Content-Type: text/plain; charset=UTF-8 On 11 October 2016 at 16:19, Eli Zaretskii wrote: > > Alternatively, maybe you could start Emacs yourself, stop it at the > beginning of 'main' (e.g. with the "start" command instead or "run"), > then let me connect to the terminal where GDB runs via 'screen' or > somesuch. (I don't know the details, as I almost never use 'screen', > I just know that someone once provided such a possibility for me from > a remore login.) > I could do this too if you like. -- http://rrt.sc3d.org --001a11401a2cf32d10053e98b8a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = 11 October 2016 at 16:19, Eli Zaretskii <eliz@gnu.org> wrote:
=

Alternatively, maybe you could start Emacs yourself, stop it at the<= br> beginning of 'main' (e.g. with the "start" command instea= d or "run"),
then let me connect to the terminal where GDB runs via 'screen' or<= br> somesuch.=C2=A0 (I don't know the details, as I almost never use 's= creen',
I just know that someone once provided such a possibility for me from
a remore login.)

I could do this too if you = like.

--
http://rrt.sc3d.org
--001a11401a2cf32d10053e98b8a0-- From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 11 12:27:21 2016 Received: (at 24640) by debbugs.gnu.org; 11 Oct 2016 16:27:21 +0000 Received: from localhost ([127.0.0.1]:52344 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btzth-00064o-6I for submit@debbugs.gnu.org; Tue, 11 Oct 2016 12:27:21 -0400 Received: from eggs.gnu.org ([208.118.235.92]:60836) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btztf-00064b-NZ for 24640@debbugs.gnu.org; Tue, 11 Oct 2016 12:27:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btztV-00054p-OE for 24640@debbugs.gnu.org; Tue, 11 Oct 2016 12:27:14 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39899) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btztV-00054i-Ka; Tue, 11 Oct 2016 12:27:09 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1669 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1btztU-00069X-RN; Tue, 11 Oct 2016 12:27:09 -0400 Date: Tue, 11 Oct 2016 19:26:56 +0300 Message-Id: <83eg3mdf73.fsf@gnu.org> From: Eli Zaretskii To: Reuben Thomas In-reply-to: (message from Reuben Thomas on Tue, 11 Oct 2016 16:42:21 +0100) Subject: Re: bug#24640: Crashes in 25.1 References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> <83vax2f1e5.fsf@gnu.org> <83r37pg7zl.fsf@gnu.org> <83y41wenld.fsf@gnu.org> <834m4kduzl.fsf@gnu.org> <831szodsus.fsf@gnu.org> <83zimccbzr.fsf@gnu.org> <83lgxvcd10.fsf@gnu.org> <83k2dfc4ya.fsf@gnu.org> <83h98idiaw.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.3 (-----) > From: Reuben Thomas > Date: Tue, 11 Oct 2016 16:42:21 +0100 > Cc: 24640@debbugs.gnu.org > > On 11 October 2016 at 16:19, Eli Zaretskii wrote: > > Alternatively, maybe you could start Emacs yourself, stop it at the > beginning of 'main' (e.g. with the "start" command instead or "run"), > then let me connect to the terminal where GDB runs via 'screen' or > somesuch. (I don't know the details, as I almost never use 'screen', > I just know that someone once provided such a possibility for me from > a remore login.) > > I could do this too if you like. Let's see if the Xvfb method could be made to work. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 11 12:33:45 2016 Received: (at 24640) by debbugs.gnu.org; 11 Oct 2016 16:33:45 +0000 Received: from localhost ([127.0.0.1]:52357 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btzzt-0006F7-HI for submit@debbugs.gnu.org; Tue, 11 Oct 2016 12:33:45 -0400 Received: from eggs.gnu.org ([208.118.235.92]:34458) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btzzs-0006Ev-18 for 24640@debbugs.gnu.org; Tue, 11 Oct 2016 12:33:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btzzi-0007aX-VV for 24640@debbugs.gnu.org; Tue, 11 Oct 2016 12:33:38 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39997) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btzzi-0007aP-Sk; Tue, 11 Oct 2016 12:33:34 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1695 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1btzzh-0007yO-Ut; Tue, 11 Oct 2016 12:33:34 -0400 Date: Tue, 11 Oct 2016 19:33:20 +0300 Message-Id: <83bmyqdewf.fsf@gnu.org> From: Eli Zaretskii To: Reuben Thomas , Phillip Lord In-reply-to: (message from Reuben Thomas on Tue, 11 Oct 2016 16:41:17 +0100) Subject: Re: bug#24640: Crashes in 25.1 References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> <83vax2f1e5.fsf@gnu.org> <83r37pg7zl.fsf@gnu.org> <83y41wenld.fsf@gnu.org> <834m4kduzl.fsf@gnu.org> <831szodsus.fsf@gnu.org> <83zimccbzr.fsf@gnu.org> <83lgxvcd10.fsf@gnu.org> <83k2dfc4ya.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.3 (-----) > From: Reuben Thomas > Date: Tue, 11 Oct 2016 16:41:17 +0100 > Cc: 24640@debbugs.gnu.org > > Is it possible to disable this loading of undo-tree history? If so, > can you disable it and see if Emacs no longer crashes? If the crashes > stop when undo-tree history is not loaded, we will have to look > closely at what that loading does, because the problem is probably > there. The internals of undo changed in Emacs 25. > > ​Yes, the crashes appear to stop when I comment out (global-undo-tree-mode) in vars.el. OK, so we have our prime suspect. Can you tell where I can find the exact version of undo-tree-mode you are using? Phillip, could you please look into that package and see if you can spot any potential problems with the Emacs 25 undo internals? TIA. From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 11 12:41:26 2016 Received: (at 24640) by debbugs.gnu.org; 11 Oct 2016 16:41:26 +0000 Received: from localhost ([127.0.0.1]:52361 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bu07K-0006Q4-BF for submit@debbugs.gnu.org; Tue, 11 Oct 2016 12:41:26 -0400 Received: from mail-lf0-f41.google.com ([209.85.215.41]:34921) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bu07I-0006Ps-Iy for 24640@debbugs.gnu.org; Tue, 11 Oct 2016 12:41:25 -0400 Received: by mail-lf0-f41.google.com with SMTP id l131so16810851lfl.2 for <24640@debbugs.gnu.org>; Tue, 11 Oct 2016 09:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RcbRqMwy9Q79vbmYF9ubqj2dX1bMh0T6Q/dELrWCG10=; b=KrIP3xOX1X2QDiYIBQ8UcCiY4NEhkEN1z5O8EKwDPNfM+aQAdMHVHcu6X4bIAx957h Pzh5kQLcEW0m737HI/Yt7tcIrevKqR6CXzil7A82cHQ7jj3hnYXK1p1e+qj+ee1nxHLU gPBoAKnS7c62ggOG/H5I1etTrLHCmXs6lSwag= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RcbRqMwy9Q79vbmYF9ubqj2dX1bMh0T6Q/dELrWCG10=; b=EGUrfyKnF4KqFdhQYbWwkKB1IXdPL3BzAKMkXtPnEAzMx2bwB2BbIMJ9KhKYz7wHwG EWxYmvOVT7qGObGrgqUWrUmCBw1s2w005avNn3ljLJtGvAk7iVilvih5S7CQH246s7/3 fZUz3DOO9yvAgiNVC7M3Qf84M052GvkWE3pQNQKAuGBgZi60rXG7YwvUhggQuh0NtwAf LaGXmyfkXCT8sH6jKEWSU84zzou4qYRHZiRupgLskOUWOqDmyhZJBcMqWlYbR6FZmBQ9 +KvMfLE+5nnyqWIybSAleBdMXXVy11qWuiSxJDngR01SJGH6P/7hodM0JzmBcjRyl8Dw BM6Q== X-Gm-Message-State: AA6/9RlXSsmgpub4Kpi97RV0gDtdG4o2MP/sg6KkIobwxmyVAM5EWi6LpOt+FAmVdFyvuH6ZoXLSBbCkgXsVZcz8 X-Received: by 10.25.169.208 with SMTP id s199mr74106lfe.58.1476204078534; Tue, 11 Oct 2016 09:41:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.66.211 with HTTP; Tue, 11 Oct 2016 09:41:17 -0700 (PDT) In-Reply-To: <83bmyqdewf.fsf@gnu.org> References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> <83vax2f1e5.fsf@gnu.org> <83r37pg7zl.fsf@gnu.org> <83y41wenld.fsf@gnu.org> <834m4kduzl.fsf@gnu.org> <831szodsus.fsf@gnu.org> <83zimccbzr.fsf@gnu.org> <83lgxvcd10.fsf@gnu.org> <83k2dfc4ya.fsf@gnu.org> <83bmyqdewf.fsf@gnu.org> From: Reuben Thomas Date: Tue, 11 Oct 2016 17:41:17 +0100 Message-ID: Subject: Re: bug#24640: Crashes in 25.1 To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a11402c06b7a9a1053e998b20 X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org, Phillip Lord X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) --001a11402c06b7a9a1053e998b20 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11 October 2016 at 17:33, Eli Zaretskii wrote: > > From: Reuben Thomas > > Date: Tue, 11 Oct 2016 16:41:17 +0100 > > Cc: 24640@debbugs.gnu.org > > > > Is it possible to disable this loading of undo-tree history? If so, > > can you disable it and see if Emacs no longer crashes? If the crashes > > stop when undo-tree history is not loaded, we will have to look > > closely at what that loading does, because the problem is probably > > there. The internals of undo changed in Emacs 25. > > > > =E2=80=8BYes, the crashes appear to stop when I comment out > (global-undo-tree-mode) in vars.el. > > OK, so we have our prime suspect. Can you tell where I can find the > exact version of undo-tree-mode you are using? > ;; Version: 0.6.6 ;; Keywords: convenience, files, undo, redo, history, tree ;; URL: http://www.dr-qubit.org/emacs.php ;; Repository: http://www.dr-qubit.org/git/undo-tree.git --=20 http://rrt.sc3d.org --001a11402c06b7a9a1053e998b20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = 11 October 2016 at 17:33, Eli Zaretskii <eliz@gnu.org> wrote:
=
> From: Reuben Thomas <rrt@sc3d.org>
> Date: Tue, 11 Oct 2016 16:41:17 +0100
> Cc: 24640@debbugs.gnu.org=
>
>=C2=A0 Is it possible to disable this loa= ding of undo-tree history? If so,
>=C2=A0 can you disable it and see if Emacs no longer crashes? If the cr= ashes
>=C2=A0 stop when undo-tree history is not loaded, we will have to look<= br> >=C2=A0 closely at what that loading does, because the problem is probab= ly
>=C2=A0 there. The internals of undo changed in Emacs 25.
>
> =E2=80=8BYes, the crashes appear to stop when I comment out (global-un= do-tree-mode) in vars.el.

OK, so we have our prime suspect.=C2=A0 Can you tell where I can fin= d the
exact version of undo-tree-mode you are using?

;; Version: 0.6.6
;; Keywords: convenience, files, u= ndo, redo, history, tree

--
--001a11402c06b7a9a1053e998b20-- From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 12 06:31:32 2016 Received: (at 24640) by debbugs.gnu.org; 12 Oct 2016 10:31:32 +0000 Received: from localhost ([127.0.0.1]:52758 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buGot-0008CH-Ti for submit@debbugs.gnu.org; Wed, 12 Oct 2016 06:31:32 -0400 Received: from eggs.gnu.org ([208.118.235.92]:39731) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buGos-0008C5-Nu for 24640@debbugs.gnu.org; Wed, 12 Oct 2016 06:31:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buGoi-0005Z6-MP for 24640@debbugs.gnu.org; Wed, 12 Oct 2016 06:31:25 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53509) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buGoi-0005Yd-Jk; Wed, 12 Oct 2016 06:31:20 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2778 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1buGof-0000rb-I8; Wed, 12 Oct 2016 06:31:18 -0400 Date: Wed, 12 Oct 2016 13:31:05 +0300 Message-Id: <83h98hc106.fsf@gnu.org> From: Eli Zaretskii To: phillip.lord@russet.org.uk, Toby S. Cubitt In-reply-to: <83bmyqdewf.fsf@gnu.org> (message from Eli Zaretskii on Tue, 11 Oct 2016 19:33:20 +0300) Subject: Re: bug#24640: Crashes in 25.1 References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> <83vax2f1e5.fsf@gnu.org> <83r37pg7zl.fsf@gnu.org> <83y41wenld.fsf@gnu.org> <834m4kduzl.fsf@gnu.org> <831szodsus.fsf@gnu.org> <83zimccbzr.fsf@gnu.org> <83lgxvcd10.fsf@gnu.org> <83k2dfc4ya.fsf@gnu.org> <83bmyqdewf.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: 24640 Cc: 24640@debbugs.gnu.org, rrt@sc3d.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.3 (-----) > Date: Tue, 11 Oct 2016 19:33:20 +0300 > From: Eli Zaretskii > Cc: 24640@debbugs.gnu.org > > > ​Yes, the crashes appear to stop when I comment out (global-undo-tree-mode) in vars.el. > > OK, so we have our prime suspect. Can you tell where I can find the > exact version of undo-tree-mode you are using? > > Phillip, could you please look into that package and see if you can > spot any potential problems with the Emacs 25 undo internals? TIA. Some functions in undo-tree refer to or manipulate Emacs undo internals: undo-list-pop-changeset undo-list-transfer-to-tree undo-list-rebuild-from-tree undo-tree-pull-undo-in-region-branch undo-tree-pull-redo-in-region-branch undo-tree-adjust-elements-to-elt undo-tree-apply-deltas undo-tree-undo-1 undo-tree-redo-1 Do they perhaps need some adjustments to Emacs 25's undo? Another potential issue is the new undo timer we have in Emacs 25 (see undo-auto--boundary-ensure-timer in simple.el). One way of checking whether this is related to the crashes is to modify that function to use a much larger value for the 1st argument of run-at-time, say 10000, so that the undo timer never fires during the startup. Reuben, could you try that? From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 12 06:57:36 2016 Received: (at 24640) by debbugs.gnu.org; 12 Oct 2016 10:57:36 +0000 Received: from localhost ([127.0.0.1]:52763 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buHE8-0000KP-4D for submit@debbugs.gnu.org; Wed, 12 Oct 2016 06:57:36 -0400 Received: from mail-lf0-f51.google.com ([209.85.215.51]:34677) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buHE6-0000KD-7y for 24640@debbugs.gnu.org; Wed, 12 Oct 2016 06:57:34 -0400 Received: by mail-lf0-f51.google.com with SMTP id b81so68830438lfe.1 for <24640@debbugs.gnu.org>; Wed, 12 Oct 2016 03:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p1HNA7iZVSCdcrzLPIy92+UXnUfrvmZGoaAnKnsS9Kw=; b=RdeGb0S7YgsK0UZ2ul8269jJYWMfNLgZhKODiic9KaIt+VySryqnf535qCxk+RYA9u VinVJzo2OJYuVQiEB7IXcOW4ezbz7jJBRWaGe7iCV8lFNzMaUHUF7XG5Tqn2DxHD2bJE FyFYvy6BDhfQWAG+ogfuhYQ0MCaL8T8P4uBFY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=p1HNA7iZVSCdcrzLPIy92+UXnUfrvmZGoaAnKnsS9Kw=; b=HNXQTSilL5uGevNDWcJ0Rvv5lB2RmSAB2HcRSM6RpSNkzFxx+oEQcVq36qh+CGDZr9 a1uTjZYm4Bqv+uTlJDpqCaGzGt+xrm8DskIRS76cmx6DsjsuVcyk0z7VBoe0PwP4Q4wn qIexNzYNTDNgoNM+QEXb+6jkp2Mrj8iztG430UgENwUKs0XVgqCdrDHHyZkUMbRLN4uV efb3lukjg4QfB0xR7JuLit1Pkrr53WW6IBgPl1ZY2+0y0RdjfMwK72SOt2/DOCbMZOo2 5czETVVqfRgzf06klCjjgYFeWgajOggutKeTQSIs/C+jEx5vjAUqhLSCUgnogBkcKMLi HwQA== X-Gm-Message-State: AA6/9RlQUsV43ye4hTUt7ilF3jeXTvfAlzT54t8duIQz+QDWmpY7P8RU11yhYsR0THxggkzyAMznk54G/XlGAAVe X-Received: by 10.25.169.208 with SMTP id s199mr457303lfe.58.1476269847876; Wed, 12 Oct 2016 03:57:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.66.211 with HTTP; Wed, 12 Oct 2016 03:57:26 -0700 (PDT) In-Reply-To: <83h98hc106.fsf@gnu.org> References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> <83vax2f1e5.fsf@gnu.org> <83r37pg7zl.fsf@gnu.org> <83y41wenld.fsf@gnu.org> <834m4kduzl.fsf@gnu.org> <831szodsus.fsf@gnu.org> <83zimccbzr.fsf@gnu.org> <83lgxvcd10.fsf@gnu.org> <83k2dfc4ya.fsf@gnu.org> <83bmyqdewf.fsf@gnu.org> <83h98hc106.fsf@gnu.org> From: Reuben Thomas Date: Wed, 12 Oct 2016 11:57:26 +0100 Message-ID: Subject: Re: bug#24640: Crashes in 25.1 To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a11402c06e04686053ea8db05 X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 24640 Cc: "Toby S. Cubitt" , 24640@debbugs.gnu.org, Phillip Lord X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) --001a11402c06e04686053ea8db05 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12 October 2016 at 11:31, Eli Zaretskii wrote: > > Date: Tue, 11 Oct 2016 19:33:20 +0300 > > From: Eli Zaretskii > > Cc: 24640@debbugs.gnu.org > > > > > =E2=80=8BYes, the crashes appear to stop when I comment out > (global-undo-tree-mode) in vars.el. > > > > OK, so we have our prime suspect. Can you tell where I can find the > > exact version of undo-tree-mode you are using? > > > > Phillip, could you please look into that package and see if you can > > spot any potential problems with the Emacs 25 undo internals? TIA. > > Some functions in undo-tree refer to or manipulate Emacs undo > internals: > > undo-list-pop-changeset > undo-list-transfer-to-tree > undo-list-rebuild-from-tree > undo-tree-pull-undo-in-region-branch > undo-tree-pull-redo-in-region-branch > undo-tree-adjust-elements-to-elt > undo-tree-apply-deltas > undo-tree-undo-1 > undo-tree-redo-1 > > Do they perhaps need some adjustments to Emacs 25's undo? > =E2=80=8BAnd regardless of that, should it in principle be possible to cras= h Emacs (other than by exhausting memory or CPU) from Lisp, except by calling external code improperly?=E2=80=8B Another potential issue is the new undo timer we have in Emacs 25 (see > undo-auto--boundary-ensure-timer in simple.el). One way of checking > whether this is related to the crashes is to modify that function to > use a much larger value for the 1st argument of run-at-time, say > 10000, so that the undo timer never fires during the startup. Reuben, > could you try that? > =E2=80=8BSure. I made that change in the sources and rebuilt, and it crashe= d "as usual". --=20 http://rrt.sc3d.org --001a11402c06e04686053ea8db05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = 12 October 2016 at 11:31, Eli Zaretskii <eliz@gnu.org> wrote:
=
> Date: Tue, 11 Oct 2016 19:33:20 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 24640@d= ebbugs.gnu.org
>
> > =E2=80=8BYes, the crashes appear to stop when I comm= ent out (global-undo-tree-mode) in vars.el.
>
> OK, so we have our prime suspect.=C2=A0 Can you tell where I can find = the
> exact version of undo-tree-mode you are using?
>
> Phillip, could you please look into that package and see if you can > spot any potential problems with the Emacs 25 undo internals?=C2=A0 TI= A.

Some functions in undo-tree refer to or manipulate Emacs undo
internals:

=C2=A0 undo-list-pop-changeset
=C2=A0 undo-list-transfer-to-tree
=C2=A0 undo-list-rebuild-from-tree
=C2=A0 undo-tree-pull-undo-in-region-branch
=C2=A0 undo-tree-pull-redo-in-region-branch
=C2=A0 undo-tree-adjust-elements-to-elt
=C2=A0 undo-tree-apply-deltas
=C2=A0 undo-tree-undo-1
=C2=A0 undo-tree-redo-1

Do they perhaps need some adjustments to Emacs 25's undo?

=E2=80=8BAnd regardless of that, should it in principle be possible to c= rash Emacs (other than by exhausting memory or CPU) from Lisp, except by ca= lling external code improperly?=E2=80=8B

Another potential issue is the new undo timer we hav= e in Emacs 25 (see
undo-auto--boundary-ensure-timer in simple.el).=C2=A0 One way of check= ing
whether this is related to the crashes is to modify that function to
use a much larger value for the 1st argument of run-at-time, say
10000, so that the undo timer never fires during the startup.=C2=A0 Reuben,=
could you try that?

=E2=80=8BSure. I made that change in the sources and rebuilt, and it cra= shed "as usual".

--
http://rrt.sc3= d.org
--001a11402c06e04686053ea8db05-- From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 12 07:15:19 2016 Received: (at 24640) by debbugs.gnu.org; 12 Oct 2016 11:15:19 +0000 Received: from localhost ([127.0.0.1]:52769 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buHVD-0000lX-Py for submit@debbugs.gnu.org; Wed, 12 Oct 2016 07:15:19 -0400 Received: from eggs.gnu.org ([208.118.235.92]:48651) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buHVB-0000lK-CS for 24640@debbugs.gnu.org; Wed, 12 Oct 2016 07:15:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buHV3-00030k-O1 for 24640@debbugs.gnu.org; Wed, 12 Oct 2016 07:15:08 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54031) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buHV3-00030e-L9; Wed, 12 Oct 2016 07:15:05 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2844 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1buHV2-0003lf-Og; Wed, 12 Oct 2016 07:15:05 -0400 Date: Wed, 12 Oct 2016 14:14:53 +0300 Message-Id: <83a8e9byz6.fsf@gnu.org> From: Eli Zaretskii To: Reuben Thomas In-reply-to: (message from Reuben Thomas on Wed, 12 Oct 2016 11:57:26 +0100) Subject: Re: bug#24640: Crashes in 25.1 References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> <83vax2f1e5.fsf@gnu.org> <83r37pg7zl.fsf@gnu.org> <83y41wenld.fsf@gnu.org> <834m4kduzl.fsf@gnu.org> <831szodsus.fsf@gnu.org> <83zimccbzr.fsf@gnu.org> <83lgxvcd10.fsf@gnu.org> <83k2dfc4ya.fsf@gnu.org> <83bmyqdewf.fsf@gnu.org> <83h98hc106.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: 24640 Cc: tsc25@cantab.net, 24640@debbugs.gnu.org, phillip.lord@russet.org.uk X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.3 (-----) > From: Reuben Thomas > Date: Wed, 12 Oct 2016 11:57:26 +0100 > Cc: Phillip Lord , "Toby S. Cubitt" , 24640@debbugs.gnu.org > > ​And regardless of that, should it in principle be possible to crash Emacs (other than by exhausting memory or > CPU) from Lisp, except by calling external code improperly?​ No. Otherwise I wouldn't be spending so much time on this ;-) From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 12 09:50:32 2016 Received: (at 24640) by debbugs.gnu.org; 12 Oct 2016 13:50:32 +0000 Received: from localhost ([127.0.0.1]:52811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buJvT-0005zS-M0 for submit@debbugs.gnu.org; Wed, 12 Oct 2016 09:50:31 -0400 Received: from starfish.geekisp.com ([216.168.135.166]:22637) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1buJvR-0005zE-3T for 24640@debbugs.gnu.org; Wed, 12 Oct 2016 09:50:30 -0400 Received: (qmail 279 invoked by uid 1003); 12 Oct 2016 13:49:01 -0000 Received: from marvin.localdomain (localhost.geekisp.com [127.0.0.1]) by localhost.geekisp.com (tmda-ofmipd) with ESMTP; Wed, 12 Oct 2016 09:48:58 -0400 Received: by marvin.localdomain (Postfix, from userid 1000) id 7E3B6120BE91; Wed, 12 Oct 2016 14:50:20 +0100 (BST) Date: Wed, 12 Oct 2016 14:50:20 +0100 To: Eli Zaretskii Subject: Re: bug#24640: Crashes in 25.1 Message-ID: <20161012135020.GA21177@marvin.cs.ucl.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <83h98hc106.fsf@gnu.org> X-PGP-Key: http://www.dr-qubit.org/gpg-toby-pub.asc User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable X-Delivery-Agent: TMDA/1.1.11 (Ladyburn) From: Toby Cubitt X-Primary-Address: toby@dr-qubit.org X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 24640 Cc: rrt@sc3d.org, 24640@debbugs.gnu.org, phillip.lord@russet.org.uk X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) On Wed, Oct 12, 2016 at 01:31:05PM +0300, Eli Zaretskii wrote: > > Date: Tue, 11 Oct 2016 19:33:20 +0300 > > From: Eli Zaretskii > > Cc: 24640@debbugs.gnu.org > >=20 > > > =E2=80=8BYes, the crashes appear to stop when I comment out (global= -undo-tree-mode) in vars.el. You can also disable history loading without disabling global-undo-tree-mode, by disabling undo-tree-auto-save-history. Might be worth doing this more fine-grained check to confirm. > > OK, so we have our prime suspect. Can you tell where I can find the > > exact version of undo-tree-mode you are using? > >=20 > > Phillip, could you please look into that package and see if you can > > spot any potential problems with the Emacs 25 undo internals? TIA. >>From the bug tracker discussion, it sounds like you're close to boiling this down to some simple steps involving one undo-tree history file that trigger the crash. If you can send me the file and a list of steps to reproduce from emacs -Q, I'd be happy to look into the undo-tree side of things. > Some functions in undo-tree refer to or manipulate Emacs undo > internals: >=20 > undo-list-pop-changeset > undo-list-transfer-to-tree > undo-list-rebuild-from-tree > undo-tree-pull-undo-in-region-branch > undo-tree-pull-redo-in-region-branch > undo-tree-adjust-elements-to-elt > undo-tree-apply-deltas > undo-tree-undo-1 > undo-tree-redo-1 >=20 > Do they perhaps need some adjustments to Emacs 25's undo? The only Emacs undo internal that undo-tree manipulates is the buffer-undo-list variable. The only functions that do so are: undo-list-pop-changeset undo-list-transfer-to-tree undo-list-rebuild-from-tree All the others either call one of these, or only touch buffer-undo-tree which is a variable defined in the undo-tree package and which the Emacs undo internals know nothing about. Has the format of buffer-undo-list has changed at all? If so, then the three above might need adjustment. If not, they should work as before. The only other Emacs undo internals used by undo-tree are to call primitive-undo and undo-boundary when undo/redoing. > Another potential issue is the new undo timer we have in Emacs 25 (see > undo-auto--boundary-ensure-timer in simple.el). One way of checking > whether this is related to the crashes is to modify that function to > use a much larger value for the 1st argument of run-at-time, say > 10000, so that the undo timer never fires during the startup. Reuben, > could you try that? As far as I understand, the timer just adds undo boundaries to buffer-undo-list in some of the open buffers. Undo-tree doesn't touch buffer-undo-list (or do anything at all, in fact) until you call one of its interactive commands. Since the timer can't run whilst undo-tree lisp code is running, and extra undo boundaries are no problem for undo-tree, I'd be surprised if the new undo timer is the culprit. Best, Toby --=20 Dr T. S. Cubitt Royal Society University Research Fellow Quantum Information Theory Department of Computer Science University College London email: tsc25@cantab.net web: www.dr-qubit.org From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 12 10:45:23 2016 Received: (at 24640) by debbugs.gnu.org; 12 Oct 2016 14:45:23 +0000 Received: from localhost ([127.0.0.1]:53182 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buKmV-0007PV-Pm for submit@debbugs.gnu.org; Wed, 12 Oct 2016 10:45:23 -0400 Received: from eggs.gnu.org ([208.118.235.92]:52918) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buKmU-0007PI-1K for 24640@debbugs.gnu.org; Wed, 12 Oct 2016 10:45:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buKmL-0002lF-0w for 24640@debbugs.gnu.org; Wed, 12 Oct 2016 10:45:13 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57413) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buKmK-0002k4-Tm; Wed, 12 Oct 2016 10:45:08 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3040 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1buKmI-0002lr-VV; Wed, 12 Oct 2016 10:45:07 -0400 Date: Wed, 12 Oct 2016 17:44:55 +0300 Message-Id: <83vawxaaoo.fsf@gnu.org> From: Eli Zaretskii To: Toby Cubitt In-reply-to: <20161012135020.GA21177@marvin.cs.ucl.ac.uk> (message from Toby Cubitt on Wed, 12 Oct 2016 14:50:20 +0100) Subject: Re: bug#24640: Crashes in 25.1 References: <20161012135020.GA21177@marvin.cs.ucl.ac.uk> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.4 (-----) X-Debbugs-Envelope-To: 24640 Cc: rrt@sc3d.org, 24640@debbugs.gnu.org, phillip.lord@russet.org.uk X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.4 (-----) > Date: Wed, 12 Oct 2016 14:50:20 +0100 > Cc: phillip.lord@russet.org.uk, rrt@sc3d.org, 24640@debbugs.gnu.org > From: Toby Cubitt > > On Wed, Oct 12, 2016 at 01:31:05PM +0300, Eli Zaretskii wrote: > > > Date: Tue, 11 Oct 2016 19:33:20 +0300 > > > From: Eli Zaretskii > > > Cc: 24640@debbugs.gnu.org > > > > > > > ​Yes, the crashes appear to stop when I comment out (global-undo-tree-mode) in vars.el. > > You can also disable history loading without disabling > global-undo-tree-mode, by disabling undo-tree-auto-save-history. Might be > worth doing this more fine-grained check to confirm. Thanks for chiming in. > > > Phillip, could you please look into that package and see if you can > > > spot any potential problems with the Emacs 25 undo internals? TIA. > > >From the bug tracker discussion, it sounds like you're close to boiling > this down to some simple steps involving one undo-tree history file that > trigger the crash. They are only simple on Reuben's machine, as they involve a very large setup of his Emacs sessions. We don't have a reproducer for any other machine. What's more, the steps to reproduce may be simple (start Emacs and wait for it to crash), finding the code that is the culprit for this is anything but easy. The crash is triggered by GC, and is due to an invalid object being present in the value of read_objects, which holds the object read by Emacs with the #n=object form. The problem is that the faulty object is deep in that list, so catching the code that puts it there is not easy. I'm still trying to devise a way for that, with no real success so far. > If you can send me the file and a list of steps to reproduce from > emacs -Q, I'd be happy to look into the undo-tree side of things. Thanks. Maybe Reuben will be able to do that. > > Some functions in undo-tree refer to or manipulate Emacs undo > > internals: > > > > undo-list-pop-changeset > > undo-list-transfer-to-tree > > undo-list-rebuild-from-tree > > undo-tree-pull-undo-in-region-branch > > undo-tree-pull-redo-in-region-branch > > undo-tree-adjust-elements-to-elt > > undo-tree-apply-deltas > > undo-tree-undo-1 > > undo-tree-redo-1 > > > > Do they perhaps need some adjustments to Emacs 25's undo? > > The only Emacs undo internal that undo-tree manipulates is the > buffer-undo-list variable. The only functions that do so are: > > undo-list-pop-changeset > undo-list-transfer-to-tree > undo-list-rebuild-from-tree > > All the others either call one of these, or only touch buffer-undo-tree > which is a variable defined in the undo-tree package and which the Emacs > undo internals know nothing about. > > Has the format of buffer-undo-list has changed at all? If so, then the > three above might need adjustment. If not, they should work as before. > > The only other Emacs undo internals used by undo-tree are to call > primitive-undo and undo-boundary when undo/redoing. I counted this last class among those listed above. > > Another potential issue is the new undo timer we have in Emacs 25 (see > > undo-auto--boundary-ensure-timer in simple.el). One way of checking > > whether this is related to the crashes is to modify that function to > > use a much larger value for the 1st argument of run-at-time, say > > 10000, so that the undo timer never fires during the startup. Reuben, > > could you try that? > > As far as I understand, the timer just adds undo boundaries to > buffer-undo-list in some of the open buffers. Undo-tree doesn't touch > buffer-undo-list (or do anything at all, in fact) until you call one of > its interactive commands. Does restoring undo-tree history manipulates buffer-undo-list of any buffers in any way? > Since the timer can't run whilst undo-tree lisp code is running It can run if during restoring the history, undo-tree calls sit-for, or asks a question, or calls some other API that enters redisplay and/or involves user input. > I'd be surprised if the new undo timer is the culprit. It could be a culprit, but evidently isn't, as Reuben already tried to disable it. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 12 12:57:08 2016 Received: (at 24640) by debbugs.gnu.org; 12 Oct 2016 16:57:08 +0000 Received: from localhost ([127.0.0.1]:53269 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buMq4-0003ow-7s for submit@debbugs.gnu.org; Wed, 12 Oct 2016 12:57:08 -0400 Received: from sanddollar.geekisp.com ([216.168.135.167]:1649) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1buMq3-0003oL-DC for 24640@debbugs.gnu.org; Wed, 12 Oct 2016 12:57:07 -0400 Received: (qmail 15431 invoked by uid 1003); 12 Oct 2016 16:51:35 -0000 Received: from marvin.localdomain (localhost.geekisp.com [127.0.0.1]) by localhost.geekisp.com (tmda-ofmipd) with ESMTP; Wed, 12 Oct 2016 12:51:31 -0400 Received: by marvin.localdomain (Postfix, from userid 1000) id 7F7A812150E7; Wed, 12 Oct 2016 17:56:56 +0100 (BST) Date: Wed, 12 Oct 2016 17:56:56 +0100 To: Eli Zaretskii Subject: Re: bug#24640: Crashes in 25.1 Message-ID: <20161012165656.GA19297@marvin.cs.ucl.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83vawxaaoo.fsf@gnu.org> X-PGP-Key: http://www.dr-qubit.org/gpg-toby-pub.asc User-Agent: Mutt/1.5.24 (2015-08-30) X-Delivery-Agent: TMDA/1.1.11 (Ladyburn) From: Toby Cubitt X-Primary-Address: toby@dr-qubit.org X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 24640 Cc: rrt@sc3d.org, 24640@debbugs.gnu.org, phillip.lord@russet.org.uk X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) On Wed, Oct 12, 2016 at 05:44:55PM +0300, Eli Zaretskii wrote: > What's more, the steps to reproduce may be simple (start Emacs and > wait for it to crash), finding the code that is the culprit for this > is anything but easy. The crash is triggered by GC, and is due to an > invalid object being present in the value of read_objects, which holds > the object read by Emacs with the #n=object form. The problem is that > the faulty object is deep in that list, so catching the code that puts > it there is not easy. I'm still trying to devise a way for that, with > no real success so far. I understand. I can't help at all with the GC bug, unfortunately, as it's well outside my Emacs knowledge. I know what the buffer-undo-tree data structure looks like that gets written and read from file, so if I can help at any point by picking apart or simplifying that lisp structure, let me know. > > > Some functions in undo-tree refer to or manipulate Emacs undo > > > internals: > > > > > > undo-list-pop-changeset > > > undo-list-transfer-to-tree > > > undo-list-rebuild-from-tree > > > undo-tree-pull-undo-in-region-branch > > > undo-tree-pull-redo-in-region-branch > > > undo-tree-adjust-elements-to-elt > > > undo-tree-apply-deltas > > > undo-tree-undo-1 > > > undo-tree-redo-1 > > > > > > Do they perhaps need some adjustments to Emacs 25's undo? > > > > The only Emacs undo internal that undo-tree manipulates is the > > buffer-undo-list variable. The only functions that do so are: > > > > undo-list-pop-changeset > > undo-list-transfer-to-tree > > undo-list-rebuild-from-tree > > > > All the others either call one of these, or only touch buffer-undo-tree > > which is a variable defined in the undo-tree package and which the Emacs > > undo internals know nothing about. > > > > Has the format of buffer-undo-list has changed at all? If so, then the > > three above might need adjustment. If not, they should work as before. > > > > The only other Emacs undo internals used by undo-tree are to call > > primitive-undo and undo-boundary when undo/redoing. > > I counted this last class among those listed above. Indeed. I was attempting to explain which ones manipulate buffer-undo-list "behind Emacs' back", and which ones just call out to undo functions. In case it helps, note that none of the above functions get called when reloading history from file. > > > Another potential issue is the new undo timer we have in Emacs 25 (see > > > undo-auto--boundary-ensure-timer in simple.el). One way of checking > > > whether this is related to the crashes is to modify that function to > > > use a much larger value for the 1st argument of run-at-time, say > > > 10000, so that the undo timer never fires during the startup. Reuben, > > > could you try that? > > > > As far as I understand, the timer just adds undo boundaries to > > buffer-undo-list in some of the open buffers. Undo-tree doesn't touch > > buffer-undo-list (or do anything at all, in fact) until you call one of > > its interactive commands. > > Does restoring undo-tree history manipulates buffer-undo-list of any > buffers in any way? No. It just reads a lisp structure from file into the buffer-undo-tree variable. > > Since the timer can't run whilst undo-tree lisp code is running > > It can run if during restoring the history, undo-tree calls sit-for, or > asks a question, or calls some other API that enters redisplay and/or > involves user input. During history loading it doesn't access buffer-undo-list at all, so it shouldn't matter if the timer runs. When undoing, everything that accesses or touches buffer-undo-list is encapsulated in the three functions I listed. None of these call sit-for, prompt for input, or display anything. As far as I understand it, they shouldn't be able to trigger redisplay at all (caveat I'm no redisplay expert - that's you!) I don't think the undo timer can trigger elsewhere during undo-tree undo. Even if it does somehow trigger outside those three functions, this shouldn't break anything. Depending on when it triggers, undo-tree will either pick up the extra undo boundary added to buffer-undo-list this time around, or next time you undo. > > I'd be surprised if the new undo timer is the culprit. > > It could be a culprit, but evidently isn't, as Reuben already tried to > disable it. Indeed. But even if it's not to blame here, I still ought double-check the above carefully to make sure the new undo timer doesn't interact with undo-tree in some subtle way I've overlooked. Cheers, Toby -- Dr T. S. Cubitt Royal Society University Research Fellow Quantum Information Theory Department of Computer Science University College London email: tsc25@cantab.net web: www.dr-qubit.org From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 12 13:29:19 2016 Received: (at 24640) by debbugs.gnu.org; 12 Oct 2016 17:29:19 +0000 Received: from localhost ([127.0.0.1]:53300 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buNL9-0004aP-EM for submit@debbugs.gnu.org; Wed, 12 Oct 2016 13:29:19 -0400 Received: from eggs.gnu.org ([208.118.235.92]:38949) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buNL8-0004aA-3r for 24640@debbugs.gnu.org; Wed, 12 Oct 2016 13:29:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buNKz-00037e-0d for 24640@debbugs.gnu.org; Wed, 12 Oct 2016 13:29:08 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59827) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buNKy-00037A-TL; Wed, 12 Oct 2016 13:29:04 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3288 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1buNKw-0008Hl-Ju; Wed, 12 Oct 2016 13:29:03 -0400 Date: Wed, 12 Oct 2016 20:28:47 +0300 Message-Id: <83k2dda33k.fsf@gnu.org> From: Eli Zaretskii To: Toby Cubitt In-reply-to: <20161012165656.GA19297@marvin.cs.ucl.ac.uk> (message from Toby Cubitt on Wed, 12 Oct 2016 17:56:56 +0100) Subject: Re: bug#24640: Crashes in 25.1 References: <20161012165656.GA19297@marvin.cs.ucl.ac.uk> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.4 (-----) X-Debbugs-Envelope-To: 24640 Cc: rrt@sc3d.org, 24640@debbugs.gnu.org, phillip.lord@russet.org.uk X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.4 (-----) > Date: Wed, 12 Oct 2016 17:56:56 +0100 > Cc: phillip.lord@russet.org.uk, rrt@sc3d.org, 24640@debbugs.gnu.org > From: Toby Cubitt > > > Does restoring undo-tree history manipulates buffer-undo-list of any > > buffers in any way? > > No. It just reads a lisp structure from file into the buffer-undo-tree > variable. In that case, changes in Emacs undo internals are probably off the hook. Hmm... which leaves us with what other suspects? > > > Since the timer can't run whilst undo-tree lisp code is running > > > > It can run if during restoring the history, undo-tree calls sit-for, or > > asks a question, or calls some other API that enters redisplay and/or > > involves user input. > > During history loading it doesn't access buffer-undo-list at all, so it > shouldn't matter if the timer runs. > > When undoing, everything that accesses or touches buffer-undo-list is > encapsulated in the three functions I listed. None of these call sit-for, > prompt for input, or display anything. As far as I understand it, they > shouldn't be able to trigger redisplay at all (caveat I'm no redisplay > expert - that's you!) Well, one place where redisplay could be triggered is those messages about failure to load history, like this one (which actually happens during restoring Emacs sessions from Reuben's desktop file): Error reading undo-tree history from "/home/user/.emacs.d/undo-tree/.!home!user!Foo!Bar!baz!doc!yyy.tex.~undo-tree~" (I obfuscated a few directory names here to protect Reuben's privacy.) Each such message enters redisplay. But again, the undo timer is not the culprit, so this is just for completeness. > I don't think the undo timer can trigger elsewhere during undo-tree > undo. Even if it does somehow trigger outside those three functions, this > shouldn't break anything. Depending on when it triggers, undo-tree will > either pick up the extra undo boundary added to buffer-undo-list this > time around, or next time you undo. I originally asked that question because Reuben's setup arranges for restoring the session lazily, which means buffers are restored from their files by functions that run off the idle timer. So I thought about two timers stepping on each other's toes. Again, that proved to be a dead end, at least for now. > Indeed. But even if it's not to blame here, I still ought double-check > the above carefully to make sure the new undo timer doesn't interact with > undo-tree in some subtle way I've overlooked. That's prudent, of course. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 12 14:09:29 2016 Received: (at 24640) by debbugs.gnu.org; 12 Oct 2016 18:09:29 +0000 Received: from localhost ([127.0.0.1]:53333 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buNy0-0005X7-OU for submit@debbugs.gnu.org; Wed, 12 Oct 2016 14:09:28 -0400 Received: from sanddollar.geekisp.com ([216.168.135.167]:18947) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1buNxz-0005Wu-NH for 24640@debbugs.gnu.org; Wed, 12 Oct 2016 14:09:24 -0400 Received: (qmail 22222 invoked by uid 1003); 12 Oct 2016 18:04:12 -0000 Received: from marvin.localdomain (localhost.geekisp.com [127.0.0.1]) by localhost.geekisp.com (tmda-ofmipd) with ESMTP; Wed, 12 Oct 2016 14:04:08 -0400 Received: by marvin.localdomain (Postfix, from userid 1000) id C53B212151FE; Wed, 12 Oct 2016 19:07:26 +0100 (BST) Date: Wed, 12 Oct 2016 19:07:26 +0100 To: Eli Zaretskii Subject: Re: bug#24640: Crashes in 25.1 Message-ID: <20161012180726.GA6818@marvin.cs.ucl.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83k2dda33k.fsf@gnu.org> X-PGP-Key: http://www.dr-qubit.org/gpg-toby-pub.asc User-Agent: Mutt/1.5.24 (2015-08-30) X-Delivery-Agent: TMDA/1.1.11 (Ladyburn) From: Toby Cubitt X-Primary-Address: toby@dr-qubit.org X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 24640 Cc: rrt@sc3d.org, 24640@debbugs.gnu.org, phillip.lord@russet.org.uk X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) On Wed, Oct 12, 2016 at 08:28:47PM +0300, Eli Zaretskii wrote: > > Date: Wed, 12 Oct 2016 17:56:56 +0100 > > Cc: phillip.lord@russet.org.uk, rrt@sc3d.org, 24640@debbugs.gnu.org > > From: Toby Cubitt > > > > > Does restoring undo-tree history manipulates buffer-undo-list of any > > > buffers in any way? > > > > No. It just reads a lisp structure from file into the buffer-undo-tree > > variable. > > In that case, changes in Emacs undo internals are probably off the > hook. Hmm... which leaves us with what other suspects? Does loading Reuben's history file using undo-tree-load-history starting from emacs -Q trigger the crash? From the discussion, I'm guessing not... > Well, one place where redisplay could be triggered is those messages > about failure to load history, like this one (which actually happens > during restoring Emacs sessions from Reuben's desktop file): > > Error reading undo-tree history from "/home/user/.emacs.d/undo-tree/.!home!user!Foo!Bar!baz!doc!yyy.tex.~undo-tree~" > > (I obfuscated a few directory names here to protect Reuben's privacy.) That's odd. That particular error message can only be triggered if one of the two (read (current-buffer)) calls fails. It means the undo history file exists, but `read' could not parse the contents into a lisp expression (or errored for some other reason). This shouldn't be possible. Undo-tree uses `prin1` to write one hash and one complicated lisp structure to the file when it saves history. The lisp structure does have a read syntax. Unless the history file has been modified outside of undo-tree, it should always be able to read these back in. Normal situations, like failing to find an undo history file or detecting that the file has changed since the history was written, trigger different error messages. Maybe this is a red herring, since failing to read a lisp expression shouldn't crash Emacs anyway. But it's odd to me that this message is triggered at all... T. -- Dr T. S. Cubitt Royal Society University Research Fellow Quantum Information Theory Department of Computer Science University College London email: tsc25@cantab.net web: www.dr-qubit.org From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 12 15:16:38 2016 Received: (at 24640) by debbugs.gnu.org; 12 Oct 2016 19:16:38 +0000 Received: from localhost ([127.0.0.1]:53354 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buP10-00074y-Az for submit@debbugs.gnu.org; Wed, 12 Oct 2016 15:16:38 -0400 Received: from eggs.gnu.org ([208.118.235.92]:38086) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buP0y-00074l-OT for 24640@debbugs.gnu.org; Wed, 12 Oct 2016 15:16:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buP0p-0004jG-ED for 24640@debbugs.gnu.org; Wed, 12 Oct 2016 15:16:27 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33080) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buP0p-0004j3-B1; Wed, 12 Oct 2016 15:16:23 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3465 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1buP0m-0006Wb-69; Wed, 12 Oct 2016 15:16:21 -0400 Date: Wed, 12 Oct 2016 22:15:59 +0300 Message-Id: <83d1j59y4w.fsf@gnu.org> From: Eli Zaretskii To: Toby Cubitt In-reply-to: <20161012180726.GA6818@marvin.cs.ucl.ac.uk> (message from Toby Cubitt on Wed, 12 Oct 2016 19:07:26 +0100) Subject: Re: bug#24640: Crashes in 25.1 References: <20161012180726.GA6818@marvin.cs.ucl.ac.uk> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.4 (-----) X-Debbugs-Envelope-To: 24640 Cc: rrt@sc3d.org, 24640@debbugs.gnu.org, phillip.lord@russet.org.uk X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.4 (-----) > Date: Wed, 12 Oct 2016 19:07:26 +0100 > Cc: phillip.lord@russet.org.uk, rrt@sc3d.org, 24640@debbugs.gnu.org > From: Toby Cubitt > > Does loading Reuben's history file using undo-tree-load-history starting > from emacs -Q trigger the crash? From the discussion, I'm guessing not... Reuben said no. And I see it in my debugging on his machine: the bug is triggered in a very specific place for a single file, although several other files have their undo-tree history read and restored. > > Well, one place where redisplay could be triggered is those messages > > about failure to load history, like this one (which actually happens > > during restoring Emacs sessions from Reuben's desktop file): > > > > Error reading undo-tree history from "/home/user/.emacs.d/undo-tree/.!home!user!Foo!Bar!baz!doc!yyy.tex.~undo-tree~" > > > > (I obfuscated a few directory names here to protect Reuben's privacy.) > > That's odd. That particular error message can only be triggered if one of > the two (read (current-buffer)) calls fails. It means the undo history > file exists, but `read' could not parse the contents into a lisp > expression (or errored for some other reason). > > This shouldn't be possible. Undo-tree uses `prin1` to write one hash and > one complicated lisp structure to the file when it saves history. The > lisp structure does have a read syntax. Unless the history file has been > modified outside of undo-tree, it should always be able to read these > back in. > > Normal situations, like failing to find an undo history file or detecting > that the file has changed since the history was written, trigger > different error messages. > > Maybe this is a red herring, since failing to read a lisp expression > shouldn't crash Emacs anyway. But it's odd to me that this message is > triggered at all... Your surprise is IMO a reason good enough to ask Reuben to send you the undo-tree history file for analysis. Who knows, it might even be the clue we are looking for. (I agree that the error alone should not, and most probably is not, the cause of the crash.) In the *Messages* buffer at the point of the crash, I see error messages like above for 2 more files (but only one of the 3 immediately precedes a crash in GC, although GC happens after the previous errors as well). From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 12 16:45:24 2016 Received: (at 24640) by debbugs.gnu.org; 12 Oct 2016 20:45:24 +0000 Received: from localhost ([127.0.0.1]:53495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buQOy-0000mL-2x for submit@debbugs.gnu.org; Wed, 12 Oct 2016 16:45:24 -0400 Received: from mail-lf0-f52.google.com ([209.85.215.52]:36524) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buQOv-0000m8-WF for 24640@debbugs.gnu.org; Wed, 12 Oct 2016 16:45:22 -0400 Received: by mail-lf0-f52.google.com with SMTP id b75so94184745lfg.3 for <24640@debbugs.gnu.org>; Wed, 12 Oct 2016 13:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ju6abI8rh1DBNnuhUqaTy+O7++u/n0rwn0zg4+MGvGY=; b=uWFDVpCCLnwN9r7pwdtglkQtTYQJ/9EwX6mbATxfYMGmw9L6XvaWxOq9NmYuODJxCu QTuZIbNERaRqU0Z3grpcs38KV4qb5X60UVkSoRQ8Lj34aTcEMG4VY2zQAigEZThFbi+u xAJr8IkTXqfGd5ZToVrN3AzhF27zj9OldFLiQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ju6abI8rh1DBNnuhUqaTy+O7++u/n0rwn0zg4+MGvGY=; b=ju0Hjn+yEBtwDTM+L7MCuyEiZXDaUwexRYoWT9tgvbea9kolKARxFQNd7N4Jjtu9lD Z3CIkr0j1XbNyWbFBpcwTTT3p4PzE+g7Np51xsvVuwZrXBlLErwPRnYEQtRKWXUWuhDi j9EyKvzyhez9em+tcVOQTZGntlCpv0xargbzILF45tTiSstFO9PxCG/Yd319V3y8VzZC 5AydmMPjetAPBeUXNo32MFXBnjQSalJEE3mFOt6KnviPwLJ/pfbrdJW62NBt6vrmKT24 5aMeamQUlW+7oyLIN8ZyBU9cDNYWNlWh9ppFfgFurRAb6W9B1CZraenxIy0OO3QpTwwh a7aA== X-Gm-Message-State: AA6/9RlWHO96TY7t8vbyicxsUaY84wklqbIL8t/1KgA+FkCZw8sdp/kBmZSzuya5cGPnplFlZTgPsGNvkrJ7YRrm X-Received: by 10.25.34.11 with SMTP id i11mr4033169lfi.119.1476305115770; Wed, 12 Oct 2016 13:45:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.158.206 with HTTP; Wed, 12 Oct 2016 13:45:14 -0700 (PDT) In-Reply-To: <83d1j59y4w.fsf@gnu.org> References: <20161012180726.GA6818@marvin.cs.ucl.ac.uk> <83d1j59y4w.fsf@gnu.org> From: Reuben Thomas Date: Wed, 12 Oct 2016 21:45:14 +0100 Message-ID: Subject: Re: bug#24640: Crashes in 25.1 To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a113aa9100177ff053eb112b2 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 24640 Cc: Toby Cubitt , 24640@debbugs.gnu.org, Phillip Lord X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --001a113aa9100177ff053eb112b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12 October 2016 at 20:15, Eli Zaretskii wrote: > > Your surprise is IMO a reason good enough to ask Reuben to send you > the undo-tree history file for analysis. Who knows, it might even be > the clue we are looking for. (I agree that the error alone should > not, and most probably is not, the cause of the crash.) > =E2=80=8BToby, I'm happy to send you this file if you like.=E2=80=8B =E2=80=8BApologies, I'm having trouble following all the ramifications of E= li's energetic debugging effort; is there any other action you (Toby) would like me to take? --=20 http://rrt.sc3d.org --001a113aa9100177ff053eb112b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = 12 October 2016 at 20:15, Eli Zaretskii <eliz@gnu.org> wrote:
=

Your surprise is IMO a reason good enough to ask Reuben to send you<= br> the undo-tree history file for analysis.=C2=A0 Who knows, it might even be<= br> the clue we are looking for.=C2=A0 (I agree that the error alone should
not, and most probably is not, the cause of the crash.)

=E2=80=8BToby, I'm happy to send you this file if you like.= =E2=80=8B

=E2=80=8BApologies, I'm ha= ving trouble following all the ramifications of Eli's energetic debuggi= ng effort; is there any other action you (Toby) would like me to take?

--
http://rrt.= sc3d.org
--001a113aa9100177ff053eb112b2-- From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 14 16:06:22 2016 Received: (at 24640-done) by debbugs.gnu.org; 14 Oct 2016 20:06:22 +0000 Received: from localhost ([127.0.0.1]:55762 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bv8kD-0002KI-Tr for submit@debbugs.gnu.org; Fri, 14 Oct 2016 16:06:22 -0400 Received: from eggs.gnu.org ([208.118.235.92]:43334) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bv8kB-0002K4-RB for 24640-done@debbugs.gnu.org; Fri, 14 Oct 2016 16:06:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bv8k4-0005Tf-5R for 24640-done@debbugs.gnu.org; Fri, 14 Oct 2016 16:06:10 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59910) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bv8k4-0005TP-21; Fri, 14 Oct 2016 16:06:08 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2717 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bv8k2-0004hJ-Pm; Fri, 14 Oct 2016 16:06:07 -0400 Date: Fri, 14 Oct 2016 23:06:00 +0300 Message-Id: <83vawu3dcn.fsf@gnu.org> From: Eli Zaretskii To: Reuben Thomas In-reply-to: (message from Reuben Thomas on Wed, 12 Oct 2016 21:45:14 +0100) Subject: Re: bug#24640: Crashes in 25.1 References: <20161012180726.GA6818@marvin.cs.ucl.ac.uk> <83d1j59y4w.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.4 (-----) X-Debbugs-Envelope-To: 24640-done Cc: tsc25@cantab.net, 24640-done@debbugs.gnu.org, phillip.lord@russet.org.uk X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.4 (-----) > From: Reuben Thomas > Date: Wed, 12 Oct 2016 21:45:14 +0100 > Cc: Toby Cubitt , Phillip Lord , 24640@debbugs.gnu.org > > On 12 October 2016 at 20:15, Eli Zaretskii wrote: > > Your surprise is IMO a reason good enough to ask Reuben to send you > the undo-tree history file for analysis. Who knows, it might even be > the clue we are looking for. (I agree that the error alone should > not, and most probably is not, the cause of the crash.) > > ​Toby, I'm happy to send you this file if you like.​ > > ​Apologies, I'm having trouble following all the ramifications of Eli's energetic debugging effort; is there any > other action you (Toby) would like me to take? This bug is now fixed on the emacs-25 branch. It was caused by a change 2 years ago that placed a stack-allocated cons cell in a staticpro'd list that is a value of a global variable, which isn't cleared when that stack slot goes out of scope. Many thanks to Reuben for letting me (ab)use his system and his time in order to find and fix this bug. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 10 15:06:57 2016 Received: (at control) by debbugs.gnu.org; 10 Nov 2016 20:06:57 +0000 Received: from localhost ([127.0.0.1]:52705 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c4vcf-0005l6-Bb for submit@debbugs.gnu.org; Thu, 10 Nov 2016 15:06:57 -0500 Received: from eggs.gnu.org ([208.118.235.92]:43016) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c4vcd-0005ks-9W for control@debbugs.gnu.org; Thu, 10 Nov 2016 15:06:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c4vcU-0002zi-Aj for control@debbugs.gnu.org; Thu, 10 Nov 2016 15:06:50 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47943) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4vcU-0002za-7D; Thu, 10 Nov 2016 15:06:46 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4948 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c4vcS-0004Ja-TD; Thu, 10 Nov 2016 15:06:45 -0500 Date: Thu, 10 Nov 2016 22:06:38 +0200 Message-Id: <83oa1ndrqp.fsf@gnu.org> From: Eli Zaretskii To: Gemini Lasswell In-reply-to: (message from Gemini Lasswell on Thu, 10 Nov 2016 11:25:52 -0800) Subject: Re: bug#24911: 25.1; Emacs hangs or crashes on use of read syntax for circular objects in IELM References: <837f8bfgaq.fsf@gnu.org> <83zil7dz6f.fsf@gnu.org> <83shqzdv6r.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.9 (-------) X-Debbugs-Envelope-To: control Cc: 24911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.9 (-------) forcemerge 24640 24911 thanks > From: Gemini Lasswell > Cc: > Date: Thu, 10 Nov 2016 11:25:52 -0800 > > I have just made it happen under gdb, with a breakpoint on > handle_sigsegv. Here is the output of 'bt full'. It tells me > 'xbacktrace' is an undefined command. This is my first time working with > gdb. > > (gdb) bt full > #0 0x000000010023ca45 in mark_object (arg=...) at alloc.c:6501 > obj = {i = 4287568137794125953} > po = 0x3b8080813b808080 > cdr_count = 0 > #1 0x000000010023cca1 in mark_object (arg=...) at alloc.c:6552 > ptr = 0x7fff5fbf8288 > obj = {i = 140734799774347} > po = 0x7fff5fbf8288 > cdr_count = 1 > #2 0x000000010023b8fb in garbage_collect_1 (end=0x7fff5fbf69a8) at alloc.c:5760 > nextb = 0x0 > stack_top_variable = 0 '\000' > i = 201 ^^^^^^^ This is bug#24640, already fixed on the emacs-25 branch. From unknown Mon Aug 11 19:05:39 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 09 Dec 2016 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator