From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Nicolas Richard Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Apr 2014 07:45:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 17168@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.139642467222483 (code B ref -1); Wed, 02 Apr 2014 07:45:05 +0000 Received: (at submit) by debbugs.gnu.org; 2 Apr 2014 07:44:32 +0000 Received: from localhost ([127.0.0.1]:60315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVFqY-0005qV-Eg for submit@debbugs.gnu.org; Wed, 02 Apr 2014 03:44:31 -0400 Received: from eggs.gnu.org ([208.118.235.92]:56452) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVFqU-0005qM-Bb for submit@debbugs.gnu.org; Wed, 02 Apr 2014 03:44:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WVFqM-0004Uj-Ub for submit@debbugs.gnu.org; Wed, 02 Apr 2014 03:44:26 -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,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:56715) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVFqM-0004Uf-R0 for submit@debbugs.gnu.org; Wed, 02 Apr 2014 03:44:18 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58166) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVFqG-0007Wp-Gg for bug-gnu-emacs@gnu.org; Wed, 02 Apr 2014 03:44:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WVFq9-0004TK-9K for bug-gnu-emacs@gnu.org; Wed, 02 Apr 2014 03:44:12 -0400 Received: from mxin.ulb.ac.be ([164.15.128.112]:5096) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVFq8-0004T1-Oq for bug-gnu-emacs@gnu.org; Wed, 02 Apr 2014 03:44:05 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApELAEe/O1OkD4Xx/2dsb2JhbABZg0GrGAIKglgBl3F0glNqJDQBiEQBFJ4yj22ZUwGIM4doi0cEjlmJfYY4hCaHW4MyOw Received: from mathsrv4.ulb.ac.be (HELO geodiff-mac3) ([164.15.133.241]) by smtp.ulb.ac.be with ESMTP; 02 Apr 2014 09:44:03 +0200 From: Nicolas Richard Date: Wed, 02 Apr 2014 09:44:25 +0200 Message-ID: <87y4zop44m.fsf@yahoo.fr> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -5.0 (-----) This happened while I was away. Program received signal SIGSEGV, Segmentation fault. mark_object (arg=194) at alloc.c:6127 6127 if (ptr->gcmarkbit) #0 mark_object (arg=194) at alloc.c:6127 #1 0x081b2a14 in mark_vectorlike (ptr=0xb9b0db0) at alloc.c:5785 #2 0x081b30df in mark_object (arg=194710965) at alloc.c:6117 #3 0x081b3116 in mark_object (arg=188747058) at alloc.c:6131 #4 0x081b1434 in mark_maybe_pointer (p=0xb400d30) at alloc.c:4563 #5 0x081b1484 in mark_memory (start=0xbfffd08c, end=0xbfffebdc) at alloc.c:4638 #6 0x081b14d1 in mark_stack () at alloc.c:4872 #7 0x081b231c in Fgarbage_collect () at alloc.c:5545 #8 0x0814bbb6 in maybe_gc () at lisp.h:4518 #9 0x081cdd73 in Ffuncall (nargs=2, args=0xbfffd2d0) at eval.c:2766 #10 0x081cbb68 in internal_condition_case_n (bfun=0x81cdcbb , nargs=2, args=0xbfffd2d0, handlers=139298778, hfun=0x8073814 ) at eval.c:1436 #11 0x0807392c in safe_call (nargs=2, func=141642493) at xdisp.c:2609 #12 0x08073969 in safe_call1 (fn=141642493, arg=139298754) at xdisp.c:2625 #13 0x080875a8 in prepare_menu_bars () at xdisp.c:11512 #14 0x0808ab42 in redisplay_internal () at xdisp.c:13403 #15 0x08089e98 in redisplay () at xdisp.c:13022 #16 0x08153013 in read_char (commandflag=1, map=218382190, prev_event=139298754, used_mouse_menu=0xbfffe8a3, end_time=0x0) at keyboard.c:2567 #17 0x0815d730 in read_key_sequence (keybuf=0xbfffe9c0, bufsize=30, prompt=139298754, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9079 #18 0x08151016 in command_loop_1 () at keyboard.c:1449 #19 0x081cb7e6 in internal_condition_case (bfun=0x8150cd3 , handlers=139331834, hfun=0x81506a9 ) at eval.c:1354 #20 0x08150a6f in command_loop_2 (ignore=139298754) at keyboard.c:1174 #21 0x081cb16e in internal_catch (tag=139329882, func=0x8150a4b , arg=139298754) at eval.c:1118 #22 0x08150a29 in command_loop () at keyboard.c:1153 #23 0x08150345 in recursive_edit_1 () at keyboard.c:777 #24 0x08150481 in Frecursive_edit () at keyboard.c:845 #25 0x0814e8b1 in main (argc=2, argv=0xbfffecd4) at emacs.c:1646 Lisp Backtrace: "Automatic GC" (0x84c678c) 0x8714af8 PVEC_COMPILED "redisplay_internal (C function)" (0x84c678c) #0 mark_object (arg=194) at alloc.c:6127 ptr = 0xc0 ptrx = 0xbfffcea8 obj = 192 cdr_count = 0 #1 0x081b2a14 in mark_vectorlike (ptr=0xb9b0db0) at alloc.c:5785 size = 36 i = 14 #2 0x081b30df in mark_object (arg=194710965) at alloc.c:6117 ptr = 0xb9b0db0 pvectype = 0 obj = 194710960 cdr_count = 0 #3 0x081b3116 in mark_object (arg=188747058) at alloc.c:6131 ptr = 0xb400d30 ptrx = 0x12 obj = 188747056 cdr_count = 0 #4 0x081b1434 in mark_maybe_pointer (p=0xb400d30) at alloc.c:4563 obj = 188747058 m = 0xb709250 #5 0x081b1484 in mark_memory (start=0xbfffd08c, end=0xbfffebdc) at alloc.c:4638 p = 0xb400d30 pp = 0xbfffde90 i = 0 #6 0x081b14d1 in mark_stack () at alloc.c:4872 end = 0xbfffd08c #7 0x081b231c in Fgarbage_collect () at alloc.c:5545 nextb = 0x0 stack_top_variable = 0 '\000' i = 1617 message_p = true count = 7 start = { tv_sec = 1396375514, tv_nsec = 188980653 } retval = 139298754 tot_before = 0 #8 0x0814bbb6 in maybe_gc () at lisp.h:4518 No locals. #9 0x081cdd73 in Ffuncall (nargs=2, args=0xbfffd2d0) at eval.c:2766 fun = 139319504 original_fun = 139319297 funcar = 0 numargs = 1 lisp_numargs = -1073753480 val = 138917188 internal_args = 0x0 i = 5 #10 0x081cbb68 in internal_condition_case_n (bfun=0x81cdcbb , nargs=2, args=0xbfffd2d0, handlers=139298778, hfun=0x8073814 ) at eval.c:1436 val = 139352440 c = 0x84e6500 #11 0x0807392c in safe_call (nargs=2, func=141642493) at xdisp.c:2609 i = 2 count = 5 gcpro1 = { next = 0x8714afd, var = 0xffd340, nvars = 2 } ap = 0xbfffd33c "H\323\377\277\005\262\024\bH\230U\b\310\323\377\277\250u\b\b\375Jq\b\302\207M\b\320\330M\b" args = 0xbfffd2d0 val = 136011655 #12 0x08073969 in safe_call1 (fn=141642493, arg=139298754) at xdisp.c:2625 No locals. #13 0x080875a8 in prepare_menu_bars () at xdisp.c:11512 windows = 139298754 all_windows = false some_windows = true gcpro1 = { next = 0xa0e9c28, var = 0x1, nvars = 1 } gcpro2 = { next = 0x0, var = 0xbfffd378, nvars = 134576184 } tooltip_frame = 139298754 #14 0x0808ab42 in redisplay_internal () at xdisp.c:13403 w = 0xb75b720 sw = 0xb75b720 fr = 0x84e46d0 pending = 0 must_finish = false match_p = false tlbufpos = { charpos = 136133708, bytepos = 139298754 } tlendpos = { charpos = 141207980, bytepos = -1073748696 } number_of_visible_frames = 1 count = 2 sf = 0x84e46d0 polling_stopped_here = 0 tail = 139298754 frame = 139347669 consider_all_windows_p = 8 update_miniwindow_p = false #15 0x08089e98 in redisplay () at xdisp.c:13022 No locals. #16 0x08153013 in read_char (commandflag=1, map=218382190, prev_event=139298754, used_mouse_menu=0xbfffe8a3, end_time=0x0) at keyboard.c:2567 echo_current = false c = 139298754 jmpcount = -1073748040 local_getcjmp = {{ __jmpbuf = {-1073748232, 136044005, 139319504, 0, -1073748264, 136011529}, __mask_was_saved = 141081056, __saved_mask = { __val = {141081056, 3221219032, 136133786, 139298754, 139319504, 141081056, 141431720, 139360971, 0, 3221219128, 135679500, 141431722, 139298778, 3221218816, 4294967295, 192, 0, 139298754, 3221219080, 135571235, 218382182, 3221219128, 135982083, 218382182, 218382174, 141431722, 141503502, 139298754, 139298754, 2, 139298754, 222500864} } }} save_jump = {{ __jmpbuf = {56, 139360971, 162623043, 169126963, 177160939, 206411387}, __mask_was_saved = 216942387, __saved_mask = { __val = {3067047979, 3068297204, 3068298304, 0, 28, 3067056153, 198911504, 178059944, 28, 4, 211656168, 3221214072, 3221218920, 135574114, 139319504, 6, 3067056073, 0, 0, 139319504, 3221218952, 135574114, 139319504, 6, 3221218984, 136011027, 139319509, 139319504, 3221218968, 135574303, 139319509, 139321778} } }} tem = 139298754 save = 142664326 previous_echo_area_message = 139298754 also_record = 139298754 reread = false gcpro1 = { next = 0x84de1b2, var = 0xbfffe6f8, nvars = 136044861 } gcpro2 = { next = 0x2fc, var = 0x1000006, nvars = 0 } polling_stopped_here = false orig_kboard = 0x889e340 #17 0x0815d730 in read_key_sequence (keybuf=0xbfffe9c0, bufsize=30, prompt=139298754, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9079 interrupted_kboard = 0x889e340 interrupted_frame = 0x84e46d0 key = 139319509 used_mouse_menu = false echo_local_start = 0 last_real_key_start = 0 keys_local_start = 0 new_binding = 139347669 count = 2 t = 0 echo_start = 0 keys_start = 0 current_binding = 218382190 first_event = 139298754 first_unbound = 31 mock_input = 0 fkey = { parent = 140966150, map = 140966150, start = 0, end = 0 } keytran = { parent = 139286286, map = 139286286, start = 0, end = 0 } indec = { parent = 140966158, map = 140966158, start = 0, end = 0 } shift_translated = false delayed_switch_frame = 139298754 original_uppercase = 134622171 original_uppercase_position = -1 dummyflag = false starting_buffer = 0x84dd8d0 fake_prefixed_keys = 139298754 gcpro1 = { next = 0x84d87c2, var = 0xbfffe8c8, nvars = 136011655 } #18 0x08151016 in command_loop_1 () at keyboard.c:1449 cmd = 141463658 keybuf = {96, 12, 137180145, 139298754, 139370802, 139298754, 4, 139298754, 141445706, 0, -1073747448, 135596160, 139329858, 210791238, 137180145, 139298754, 197184288, 0, -1073747352, 135595989, 210791238, -1073747409, -1073747384, 136104088, 2, 193733073, -1227911223, 0, 1919251558, 1797271584} i = 2 prev_modiff = 11 prev_buffer = 0x84dd8d0 already_adjusted = false #19 0x081cb7e6 in internal_condition_case (bfun=0x8150cd3 , handlers=139331834, hfun=0x81506a9 ) at eval.c:1354 val = 193733073 c = 0x84e6428 #20 0x08150a6f in command_loop_2 (ignore=139298754) at keyboard.c:1174 val = 0 #21 0x081cb16e in internal_catch (tag=139329882, func=0x8150a4b , arg=139298754) at eval.c:1118 val = 139298754 c = 0x88a0570 #22 0x08150a29 in command_loop () at keyboard.c:1153 No locals. #23 0x08150345 in recursive_edit_1 () at keyboard.c:777 count = 1 val = -1073747128 #24 0x08150481 in Frecursive_edit () at keyboard.c:845 count = 0 buffer = 139298754 #25 0x0814e8b1 in main (argc=2, argv=0xbfffecd4) at emacs.c:1646 dummy = 2 stack_bottom_variable = 0 '\000' do_initial_setlocale = true dumping = false skip_args = 1 rlim = { rlim_cur = 8388608, rlim_max = 18446744073709551615 } no_loadup = false junk = 0x0 dname_arg = 0x0 ch_to_dir = 0x0 original_pwd = 0x0 Lisp Backtrace: "Automatic GC" (0x84c678c) 0x8714af8 PVEC_COMPILED "redisplay_internal (C function)" (0x84c678c) #0 mark_object (arg=194) at alloc.c:6127 #1 0x081b2a14 in mark_vectorlike (ptr=0xb9b0db0) at alloc.c:5785 #2 0x081b30df in mark_object (arg=194710965) at alloc.c:6117 #3 0x081b3116 in mark_object (arg=188747058) at alloc.c:6131 #4 0x081b1434 in mark_maybe_pointer (p=0xb400d30) at alloc.c:4563 #5 0x081b1484 in mark_memory (start=0xbfffd08c, end=0xbfffebdc) at alloc.c:4638 #6 0x081b14d1 in mark_stack () at alloc.c:4872 #7 0x081b231c in Fgarbage_collect () at alloc.c:5545 #8 0x0814bbb6 in maybe_gc () at lisp.h:4518 #9 0x081cdd73 in Ffuncall (nargs=2, args=0xbfffd2d0) at eval.c:2766 #10 0x081cbb68 in internal_condition_case_n (bfun=0x81cdcbb , nargs=2, args=0xbfffd2d0, handlers=139298778, hfun=0x8073814 ) at eval.c:1436 #11 0x0807392c in safe_call (nargs=2, func=141642493) at xdisp.c:2609 #12 0x08073969 in safe_call1 (fn=141642493, arg=139298754) at xdisp.c:2625 #13 0x080875a8 in prepare_menu_bars () at xdisp.c:11512 #14 0x0808ab42 in redisplay_internal () at xdisp.c:13403 #15 0x08089e98 in redisplay () at xdisp.c:13022 #16 0x08153013 in read_char (commandflag=1, map=218382190, prev_event=139298754, used_mouse_menu=0xbfffe8a3, end_time=0x0) at keyboard.c:2567 #17 0x0815d730 in read_key_sequence (keybuf=0xbfffe9c0, bufsize=30, prompt=139298754, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9079 #18 0x08151016 in command_loop_1 () at keyboard.c:1449 #19 0x081cb7e6 in internal_condition_case (bfun=0x8150cd3 , handlers=139331834, hfun=0x81506a9 ) at eval.c:1354 #20 0x08150a6f in command_loop_2 (ignore=139298754) at keyboard.c:1174 #21 0x081cb16e in internal_catch (tag=139329882, func=0x8150a4b , arg=139298754) at eval.c:1118 #22 0x08150a29 in command_loop () at keyboard.c:1153 #23 0x08150345 in recursive_edit_1 () at keyboard.c:777 #24 0x08150481 in Frecursive_edit () at keyboard.c:845 #25 0x0814e8b1 in main (argc=2, argv=0xbfffecd4) at emacs.c:1646 Lisp Backtrace: "Automatic GC" (0x84c678c) 0x8714af8 PVEC_COMPILED "redisplay_internal (C function)" (0x84c678c) In GNU Emacs 24.3.50.7 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2014-03-27 on geodiff-mac3 Windowing system distributor `The X.Org Foundation', version 11.0.11304000 System Description: Gentoo Base System release 2.2 Configured using: `configure --with-x-toolkit=lucid 'CFLAGS= -O0 -g3'' Important settings: value of $LANG: fr_FR.UTF-8 locale-coding-system: utf-8-unix -- Nico. From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Apr 2014 15:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Nicolas Richard , 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139645401216167 (code B ref 17168); Wed, 02 Apr 2014 15:54:02 +0000 Received: (at 17168) by debbugs.gnu.org; 2 Apr 2014 15:53:32 +0000 Received: from localhost ([127.0.0.1]:33120 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVNTn-0004Ch-JP for submit@debbugs.gnu.org; Wed, 02 Apr 2014 11:53:31 -0400 Received: from dancol.org ([96.126.100.184]:41332) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVNTk-0004CV-Oi for 17168@debbugs.gnu.org; Wed, 02 Apr 2014 11:53:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=elv/keH6O3xQjAQTzrDqmo7cNrGvN2LOWm2IVynssAw=; b=Yh4pWNYW/h+PvWUvJ2Ob2K1++aClBnHQ5Upzt5xvBo/8mYdvvWFLgx8cDkVE1KvW99uWcdE5vBHBREcD5HZIkTIqaQEr5pO9g3L+dRbDAB39KI/aTgw/Y+gcvsp8+ofWlMOnKNQadVldZysltsji64wE2fvgqsGYWbcNJZGm7+tpZ0K24KgCcpW9by4qh5+1yunuHx2ShaV5p1z4bxlY+pjXvLoMJnFPjDJCynr7+VKKkc/Kna2iICEwgFw6Iw8USi6gCqvdeHB5kWOZSWwuQfr8UxzN8c5K5Qb6Y99n6oacl+7NrKolqMnIIfXhlZ4Wy+41zHiN5WXG1Syamc/Njw==; Received: from c-24-19-133-76.hsd1.wa.comcast.net ([24.19.133.76] helo=[192.168.1.50]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WVNTk-0005LJ-2P; Wed, 02 Apr 2014 08:53:28 -0700 Message-ID: <533C3277.30706@dancol.org> Date: Wed, 02 Apr 2014 08:53:27 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> In-Reply-To: <87y4zop44m.fsf@yahoo.fr> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UoLSEbQ9oPoenugn86o958GIBFvLSGsT7" X-Spam-Score: -0.6 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.6 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UoLSEbQ9oPoenugn86o958GIBFvLSGsT7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/02/2014 12:44 AM, Nicolas Richard wrote: > This happened while I was away. i686? Linux? mark_vectorlike? Good. This bug sounds like a manifestation of the GC bug we've been hunting for a while. Would you be comfortable sharing a core dump next time (perhaps privately)? If not, please collect a core dump anyway so that we can ask you questions about it. --UoLSEbQ9oPoenugn86o958GIBFvLSGsT7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTPDJ3AAoJEMAaIROpHW7IsjcP/2XYtC6x6sWfnqxG7SQq+7/E 4TpWQvt6i/OblkRTb/XdyXa3+mK/5CDtSWW99RileYLQUgQJ+eowqt2s8IMkFkNy DA9muoGPHcptAJ0RZTer6V9jlukNclelcli5bgyDtoAvIyGiD7RMENAu/xW8YUKG +bYse4VoRWIaG/qPMSEAZQmHkTJB4h3jxmLIL0e0z52oDv2Ku+gYTIOpEj6/ocs7 HJT1ZhLV3HEbpS/qgLlJOJ7dTH95jZPrVoQuIlDU6dKNt7EtcNZkZmcWCQ7/AVDt awcx110t0KZCVClEBeh5wz0zvLwneFjqD8S/z+F5yZtVNMop7M7FskcWGSfANWka 4hWzu2OhCnRQXJmapICl4WSu3ewUar/8fF5tVjRxwkcWvC7fqFLiJ8pRgtUENxV/ tuaMpP87tj7BiaoNb48UcILQg+s3M0qHJKLjm5VFwx7hFv7XwqLj8tceCH5e0lQi prs3Tfini7z3wdf5tfOafYdYMKvT3VxffvtsyOTysudKT7kA0zBqiDARtC5DPHDE eKYA4UKE1G1YkOSZXanZ7dVyR9iHiYvC+VQIZTHc4uJTcEx8rn7DuOZQRYTtwmdy 9Uy/4Z0Mul6jgNgUQV3O1TqQYWrPyHxXRJmFIKleQFGouoABE9/yopU7sEtk0IDJ LSneZ/UV4t3cOPlhMTZT =0UzC -----END PGP SIGNATURE----- --UoLSEbQ9oPoenugn86o958GIBFvLSGsT7-- From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 02 11:53:38 2014 Received: (at control) by debbugs.gnu.org; 2 Apr 2014 15:53:38 +0000 Received: from localhost ([127.0.0.1]:33123 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVNTt-0004Cz-WD for submit@debbugs.gnu.org; Wed, 02 Apr 2014 11:53:38 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:56886) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVNTs-0004Cs-5j for control@debbugs.gnu.org; Wed, 02 Apr 2014 11:53:36 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1WVNTr-0003tG-Rw for control@debbugs.gnu.org; Wed, 02 Apr 2014 11:53:35 -0400 Date: Wed, 02 Apr 2014 11:53:35 -0400 Message-Id: Subject: control message for bug 17168 To: X-Mailer: mail (GNU Mailutils 2.1) From: Glenn Morris X-Spam-Score: -5.6 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -5.6 (-----) merge 17167 17168 From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Dmitry Antipov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Apr 2014 16:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Nicolas Richard Cc: 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139645618924394 (code B ref 17168); Wed, 02 Apr 2014 16:30:02 +0000 Received: (at 17168) by debbugs.gnu.org; 2 Apr 2014 16:29:49 +0000 Received: from localhost ([127.0.0.1]:33167 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVO2u-0006LO-KN for submit@debbugs.gnu.org; Wed, 02 Apr 2014 12:29:48 -0400 Received: from forward2l.mail.yandex.net ([84.201.143.145]:53315) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVO2r-0006LE-PF for 17168@debbugs.gnu.org; Wed, 02 Apr 2014 12:29:47 -0400 Received: from smtp3h.mail.yandex.net (smtp3h.mail.yandex.net [84.201.186.20]) by forward2l.mail.yandex.net (Yandex) with ESMTP id 694F11AC10F7; Wed, 2 Apr 2014 20:29:44 +0400 (MSK) Received: from smtp3h.mail.yandex.net (localhost [127.0.0.1]) by smtp3h.mail.yandex.net (Yandex) with ESMTP id 029C81B437F8; Wed, 2 Apr 2014 20:29:43 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp3h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 7GXEpr1ZtQ-Thf0rt5P; Wed, 2 Apr 2014 20:29:43 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 2cd5d70a-ecf6-499b-84da-6cea77c4c287 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1396456183; bh=vuxWtfmXXnADSHB+uZXLt9tFYuefvauIm9ofjXRZDl0=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=hiTjRA4sqOC4s65/PIpCp3LmevSICMfc7XMiHuw3xJm8C5RT6zR/jivOyXEmnunQZ qB1D3U1MI+eEBn06qlbkUv5WVvBfappE55LrkPMxMBVRd7fk+EefRpOOGcn9X+FTl/ C+oEiFa4XNk/5r0uZZoWQjApumzxqD+UyzW/O5pM= Authentication-Results: smtp3h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <533C3AF5.6070502@yandex.ru> Date: Wed, 02 Apr 2014 20:29:41 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> In-Reply-To: <87y4zop44m.fsf@yahoo.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 04/02/2014 11:44 AM, Nicolas Richard wrote: > This happened while I was away. IIUC this is pretty similar to GC crashes observed by RMS (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15688). What gcc did you use to compile this binary? Dmitry From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Nicolas Richard Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Apr 2014 18:00:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: Nicolas Richard , 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.13964615555514 (code B ref 17168); Wed, 02 Apr 2014 18:00:04 +0000 Received: (at 17168) by debbugs.gnu.org; 2 Apr 2014 17:59:15 +0000 Received: from localhost ([127.0.0.1]:33240 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVPRT-0001Qs-D7 for submit@debbugs.gnu.org; Wed, 02 Apr 2014 13:59:15 -0400 Received: from mailrelay008.isp.belgacom.be ([195.238.6.174]:11824) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVPRR-0001Qh-5b for 17168@debbugs.gnu.org; Wed, 02 Apr 2014 13:59:13 -0400 X-Belgacom-Dynamic: yes Received: from 55.22-200-80.adsl-dyn.isp.belgacom.be (HELO LDLC-portable) ([80.200.22.55]) by relay.skynet.be with ESMTP; 02 Apr 2014 19:59:12 +0200 From: Nicolas Richard References: <87y4zop44m.fsf@yahoo.fr> <533C3277.30706@dancol.org> Date: Wed, 02 Apr 2014 19:59:11 +0200 In-Reply-To: <533C3277.30706@dancol.org> (Daniel Colascione's message of "Wed, 02 Apr 2014 08:53:27 -0700") Message-ID: <87vburr4sw.fsf@yahoo.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (/) Daniel Colascione writes: > On 04/02/2014 12:44 AM, Nicolas Richard wrote: >> This happened while I was away. > > i686? Linux? mark_vectorlike? Good. This bug sounds like a manifestation > of the GC bug we've been hunting for a while. Would you be comfortable > sharing a core dump next time (perhaps privately)? If not, please > collect a core dump anyway so that we can ask you questions about it. For the record, I sent the core dump privately. I also kept the gdb session open. -- Nico. From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Apr 2014 19:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Antipov , Nicolas Richard Cc: 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139646798916678 (code B ref 17168); Wed, 02 Apr 2014 19:47:01 +0000 Received: (at 17168) by debbugs.gnu.org; 2 Apr 2014 19:46:29 +0000 Received: from localhost ([127.0.0.1]:33305 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVR7E-0004Kv-Kl for submit@debbugs.gnu.org; Wed, 02 Apr 2014 15:46:29 -0400 Received: from dancol.org ([96.126.100.184]:42410) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVR7B-0004Ki-BP for 17168@debbugs.gnu.org; Wed, 02 Apr 2014 15:46:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=RrxxpvsdIrT/8BHJhm6n3MsZrTOUhwiI5NUmyoXSbFw=; b=MayNh8uW/erpnOgFNyaQ4Bf1RXmF/KjPeEP0lP2grAjgasNUAbsrm2leRbw535rBW7cz/oYOe1B3apZcxyK7Dk586296C6U2mR6npn5ICb4xmjqcA2tKWL1KjwiSBvEygU44lT6JujQ5faCzucaFin7xXbf/ii6G6lOQ7g0ngI4WGs2vMjlgd83Idsga8o5cSkIO3/9SOcqdyLE3yA090ZY5LJGQfaA24QUNDp0T/x0BQ82Ik4wTiCMlaSe0IrlLkFK7VAVU4rMBvqepC9Jp94G3Tfsy3pC30Dm2h/MOOcKzRD4En7NlD0zo12TIPLshdVIHF7E3DGj3+0PJs6Mbtg==; Received: from 66-192-186-66.static.twtelecom.net ([66.192.186.66] helo=[172.26.194.174]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WVR76-0006NJ-B1; Wed, 02 Apr 2014 12:46:20 -0700 Message-ID: <533C6905.9060309@dancol.org> Date: Wed, 02 Apr 2014 12:46:13 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> In-Reply-To: <533C3AF5.6070502@yandex.ru> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1o6Cm0IUIXdi1rxuWuFEI5Bh2FmxU6UKE" X-Spam-Score: -0.6 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.6 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1o6Cm0IUIXdi1rxuWuFEI5Bh2FmxU6UKE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/02/2014 09:29 AM, Dmitry Antipov wrote: > On 04/02/2014 11:44 AM, Nicolas Richard wrote: >=20 >> This happened while I was away. >=20 > IIUC this is pretty similar to GC crashes observed by RMS > (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D15688). > What gcc did you use to compile this binary? It's exactly the same crash. We're trying to mark clear-transient-map. Nicolas, what is the bzr revision from which this Emacs was compiled? (Is there a way to get this information from a core other than just walking the symbol obarray?) --1o6Cm0IUIXdi1rxuWuFEI5Bh2FmxU6UKE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTPGkFAAoJEMAaIROpHW7IGUAP/1uGKrl89nuQAEtGvKa6bY/b n+nMnbAcKNeqF8FceqYrS2kf6a4ulxffEI4voLQsz8ujRrK/nZrA7sxnsCxIC2fu aAuFgC4prC/siFWmKThCgucPqAl6lRLxJ6yTXsKaDROEx+gKTJ9eN4XbI6ELxs2C H8tdq9Ll1CIt+J/crWvBAkf+nfQYD3N5yMJRZi71KcDKd67BI7n6wisj9T3MSGDN lsZPuBOhjz4UmgI1Jc9HNdQJNu0WDsWzbOYtFHPwP5VWrPmRp9xf5KqwgA6Qy/bb 4j8zKnUyjeh97cnwCC2PZqUXZ+JMletEWxciQbHetxHrJqXpCD8ChkygrsyYyJYR GGE/0D0iUqy3IidH60U2q4g2DEEjc+rP5aLoA5te4YkpNGUV8EeSs0Qfk5S5Tk05 vxNFiiWoWFyBGsyr1qL4aZHMiiKylKrA9JMBVDXXYOGKHSKIJY38SbZ+xWMLj+ge n6A6Zszcwnh/0fZAO0UWnKQZVay4yK4fb2pw7soNsPP0B97ebBtD8wQMYmZsgKiB lcUFkq93R+1S5LJQc7C6ntMtOpW8eUrkghd5vJLthL4kzsVLFbZ+qU9xFaDQENuf 8LNCOh7L/r5Jp7sSsUAzeNN05sqj6NksKT1wPH2zNBDfY/q3bQ3X7DunE4LPM5cB vJ+x6fAIXdf6o9TNLKzR =PM+9 -----END PGP SIGNATURE----- --1o6Cm0IUIXdi1rxuWuFEI5Bh2FmxU6UKE-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Apr 2014 20:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Antipov , Nicolas Richard Cc: 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139647080621591 (code B ref 17168); Wed, 02 Apr 2014 20:34:02 +0000 Received: (at 17168) by debbugs.gnu.org; 2 Apr 2014 20:33:26 +0000 Received: from localhost ([127.0.0.1]:33345 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVRqf-0005cA-Mu for submit@debbugs.gnu.org; Wed, 02 Apr 2014 16:33:26 -0400 Received: from dancol.org ([96.126.100.184]:42625) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVRqb-0005bz-3t for 17168@debbugs.gnu.org; Wed, 02 Apr 2014 16:33:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=qtM3/GPXNm33f8fPzWw1aaPHVgZHb05eoegnLpIim10=; b=B3FLmXnY0LEyo/+GHavr4DCh4bY4b5bdY4q7dZMdLm+5C2aLTsyNDtLYq2b7X3NlXpVPpPaSGJ5SA5/3PAXrnTiCi7S7UATmv1Jj/M00RmWtx35XuV0m8gldw/j5wRyyHRkCGnP6JmsoXWs042NeO6Rm5z/HAu5WgthwJ5RrBK5yzpbU5hkQfZDin4hieOYQrqafVqqSfzT+crz9Oxo+fJwutntb4IP9WrKwgbEls7b31cfhDi+Gqcc3n+SgHgiJv7QOZ9dxxB8xPcYwmuxeF/ZMQlei54DnDmEFRI5Mbks6jAt3DEvSgJJxRg2BKnlMvI6tdrldcVE1XYqCCeuVSw==; Received: from [2620:0:1cfe:a0:863a:4bff:fec8:e538] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WVRqW-0006aV-JU; Wed, 02 Apr 2014 13:33:16 -0700 Message-ID: <533C7401.1070203@dancol.org> Date: Wed, 02 Apr 2014 13:33:05 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> In-Reply-To: <533C6905.9060309@dancol.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jBDqfDRfUmEFuXP8kgbPIcGHvuqoUutXW" X-Spam-Score: -0.6 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.6 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jBDqfDRfUmEFuXP8kgbPIcGHvuqoUutXW Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/02/2014 12:46 PM, Daniel Colascione wrote: > On 04/02/2014 09:29 AM, Dmitry Antipov wrote: >> On 04/02/2014 11:44 AM, Nicolas Richard wrote: >> >>> This happened while I was away. >> >> IIUC this is pretty similar to GC crashes observed by RMS >> (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D15688). >> What gcc did you use to compile this binary? >=20 > It's exactly the same crash. We're trying to mark clear-transient-map. > Nicolas, what is the bzr revision from which this Emacs was compiled? > (Is there a way to get this information from a core other than just > walking the symbol obarray?) Also, Nicolas, can you call mem_find on 194710965, 188747058, and 1947109= 60? --jBDqfDRfUmEFuXP8kgbPIcGHvuqoUutXW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTPHQBAAoJEMAaIROpHW7I3fgP/3H/85sQpGnhM5K3VVKjUspL aRogRh6Ss4R177VkfJLjh96d3MzFezjzQ4ozIbSWRujlUKBXlSWESsjG6ploLB8E C6tbs3M/tNtSZBvL5fDNZPPj+RYELFdYSCcwpBoJi0ImvKVFxYckOMQP91raysZV iciltE4xmukMubozYeKHU4LdLocTBU51XsH1jaEIbvjvYzaira5LHEdtMpUiZdzh mVFKCKYnbcQlAJwgGmrFUT8OBN6lFtClx/rMbtpYxURdHfHQdb0tB5IflRud9Q5L DvH8t8bfgPcJskPuaMQXtnPhmtKivcltOiokgaLsOvg3HE5Ec/Z41sD+4rjrgCc/ UdBuV8kGNkodCt0LFF2grDbwqXIyPA4EaxHjH5igxWZeK86jvMfG+LzKm5RF+rk0 3faYRXD26lXdkRXqRXkqkRNZQic9myh+Nmoal9JAaYwJ760gi7j+Wjp2KLIg4oGA DVqzTzcvS1ovOsBj7Zq6Hqsk5Pew4cFUw8sOSIe/GEJPy3+LP642jDwPUfOarrey HnEuI80Xpf+eKb3hTZB16kvaGJ45ZPjXK3yNHJxxa/7wMuFyCTjAiT0DugFPJ3Vp Vx+DFpAFKtUTm1aWvMICcPIhC2OfR1DWbyaQic7Ar8STduiYLkVeS6HGLgaDvBpP 5KH7npjP5ctlF+3X1plS =EliM -----END PGP SIGNATURE----- --jBDqfDRfUmEFuXP8kgbPIcGHvuqoUutXW-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Apr 2014 20:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: theonewiththeevillook@yahoo.fr, dmantipov@yandex.ru, 17168@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139647101721925 (code B ref 17168); Wed, 02 Apr 2014 20:37:01 +0000 Received: (at 17168) by debbugs.gnu.org; 2 Apr 2014 20:36:57 +0000 Received: from localhost ([127.0.0.1]:33352 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVRu4-0005hY-Il for submit@debbugs.gnu.org; Wed, 02 Apr 2014 16:36:56 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:54318) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVRu2-0005hP-0h for 17168@debbugs.gnu.org; Wed, 02 Apr 2014 16:36:55 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0N3F003007IEY900@a-mtaout22.012.net.il> for 17168@debbugs.gnu.org; Wed, 02 Apr 2014 23:36:52 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N3F003B87XGLI90@a-mtaout22.012.net.il>; Wed, 02 Apr 2014 23:36:52 +0300 (IDT) Date: Wed, 02 Apr 2014 23:37:04 +0300 From: Eli Zaretskii In-reply-to: <533C6905.9060309@dancol.org> X-012-Sender: halo1@inter.net.il Message-id: <83bnwjbh8v.fsf@gnu.org> References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: 1.0 (+) > Date: Wed, 02 Apr 2014 12:46:13 -0700 > From: Daniel Colascione > Cc: 17168@debbugs.gnu.org > > Nicolas, what is the bzr revision from which this Emacs was compiled? > (Is there a way to get this information from a core other than just > walking the symbol obarray?) Like this: (gdb) p Fsymbol_value(intern("emacs-bzr-version")) $5 = 57020481 (gdb) xtype Lisp_String (gdb) xstring $6 = (struct Lisp_String *) 0x3661040 "116894 rudalics@gmx.at-20140402143333-a56l2vy9oak0njsg" Alas, you cannot do this when debugging a core file, you need a running program. From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Apr 2014 20:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: theonewiththeevillook@yahoo.fr, dmantipov@yandex.ru, 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139647123222415 (code B ref 17168); Wed, 02 Apr 2014 20:41:02 +0000 Received: (at 17168) by debbugs.gnu.org; 2 Apr 2014 20:40:32 +0000 Received: from localhost ([127.0.0.1]:33359 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVRxX-0005pS-PN for submit@debbugs.gnu.org; Wed, 02 Apr 2014 16:40:32 -0400 Received: from dancol.org ([96.126.100.184]:42639) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVRxR-0005p9-IP for 17168@debbugs.gnu.org; Wed, 02 Apr 2014 16:40:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=SjxovQ14Fm+j7a3SFNLv6RHgMQdZDyqjBbmkhjmjHnM=; b=XkmrPYXonMyUOnVyNT24gTEWBLzG0fJo04O0cnJsAnniNU0hH24cZAVZghLfrkf7W2L89Z/oGhL2jhiU/nQXVzAHCq0X2dEegBYWcxN/iCWFvZi7G4CcdExbZV2ZTEb1jqHYg//jM1akffCP5VCH+g/UCMhMiRH7z2ffYPfPUyn8ZZ9L537KiwD88kOJO6XsMKAJvpLh2q3wNOJfDZEczQuHxa5rGBJKac5YZJJoX14DTJhP4UCpKq6ssYbVKDGyo+4OT5NOLjPoI2JdlYH3w+kmHxYJ2hV18LWOXSiLvNnG9yGb+GIEcaUFtgM20Uj/pcfzKJsdMxwq+o1b4Ng9xQ==; Received: from [2620:0:1cfe:a0:863a:4bff:fec8:e538] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WVRxE-0006cG-Sf; Wed, 02 Apr 2014 13:40:12 -0700 Message-ID: <533C75A6.60900@dancol.org> Date: Wed, 02 Apr 2014 13:40:06 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> In-Reply-To: <83bnwjbh8v.fsf@gnu.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wBmAdDEQsfasNh7gCaBx5miAxWv8MRHip" X-Spam-Score: -0.6 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.6 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wBmAdDEQsfasNh7gCaBx5miAxWv8MRHip Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/02/2014 01:37 PM, Eli Zaretskii wrote: >> Date: Wed, 02 Apr 2014 12:46:13 -0700 >> From: Daniel Colascione >> Cc: 17168@debbugs.gnu.org >> >> Nicolas, what is the bzr revision from which this Emacs was compiled? >> (Is there a way to get this information from a core other than just >> walking the symbol obarray?) >=20 > Like this: >=20 > (gdb) p Fsymbol_value(intern("emacs-bzr-version")) > $5 =3D 57020481 > (gdb) xtype > Lisp_String > (gdb) xstring > $6 =3D (struct Lisp_String *) 0x3661040 > "116894 rudalics@gmx.at-20140402143333-a56l2vy9oak0njsg" >=20 > Alas, you cannot do this when debugging a core file, you need a > running program. I was afraid of that. Would you object to declaring emacs-repository-version in C so that we can find it more easily in core dumps? --wBmAdDEQsfasNh7gCaBx5miAxWv8MRHip Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTPHWmAAoJEMAaIROpHW7IAvAQAJcUG4OVflfqRSdWEtk42RQM rw8DhGfLOAX8txhKcb7/zmXUa6Mzq9lP3y/YYlFyBWysYJn1YX150ZgI+P522Bzq GhuHdPQfJcHwhzlbdowZKG/nG25hpLmmx4nIs0yQdUlZvvvb/bvjlZkA9Ldr2Rba aaLNogcc9Q8M4yndhuUTwpdDwYvOE9NKUD5sHP7ry0reO99zDIiXAt45iGFy791s 7zodZU7OPHK+1L/ZBT29DwCJOsrxsOCdf/8PFRLZh1UaOw0nMueMUZ6umHRr+RBq Ec5prxQR358tLot2VDUsrddQbJbh9vEX/bXVRrW5bRNC6qDR//eTgrzUB+qE3yGW mfnn7V9YdX4wjW7z6Eqxe7/ecLUJyPNEfhFCYRppI6mqzIkrH8vopGAmFez+W76B +p+A1/0oHwT0xlaVi/6rF1CDNxXv7uWl5Ob6bHM7q9GtP61697C+Pg16F4VpXhcA 5X8b8I4duOnekXXHR86jCI/Bt/rmlwjCEZE3GPs9euo8UgSGpoDABVkGscfNNBjr UMX4Qj0lAogtstxlrXo3+pVn/PH1DXoX8plRKP8VUriRZ1vDJkFBXBuZqOEzK144 Dhc5hFdJp8iutdt9RhyWGODI/IuQ4sxAWx/YaKngz8ETVrDqMB1EM529+SRcExz0 21viofaBvR/JqN5ymZb8 =g59f -----END PGP SIGNATURE----- --wBmAdDEQsfasNh7gCaBx5miAxWv8MRHip-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Nicolas Richard Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Apr 2014 20:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: Nicolas Richard , Dmitry Antipov , 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139647175923313 (code B ref 17168); Wed, 02 Apr 2014 20:50:01 +0000 Received: (at 17168) by debbugs.gnu.org; 2 Apr 2014 20:49:19 +0000 Received: from localhost ([127.0.0.1]:33364 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVS62-00063x-Bn for submit@debbugs.gnu.org; Wed, 02 Apr 2014 16:49:18 -0400 Received: from mailrelay002.isp.belgacom.be ([195.238.6.175]:50368) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVS5y-00063h-BG for 17168@debbugs.gnu.org; Wed, 02 Apr 2014 16:49:16 -0400 X-Belgacom-Dynamic: yes Received: from 55.22-200-80.adsl-dyn.isp.belgacom.be (HELO LDLC-portable) ([80.200.22.55]) by relay.skynet.be with ESMTP; 02 Apr 2014 22:49:12 +0200 From: Nicolas Richard References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> Date: Wed, 02 Apr 2014 22:49:12 +0200 In-Reply-To: <533C6905.9060309@dancol.org> (Daniel Colascione's message of "Wed, 02 Apr 2014 12:46:13 -0700") Message-ID: <87r45fqwxj.fsf@yahoo.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (/) Daniel Colascione writes: > On 04/02/2014 09:29 AM, Dmitry Antipov wrote: >> IIUC this is pretty similar to GC crashes observed by RMS >> (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15688). >> What gcc did you use to compile this binary? > > It's exactly the same crash. We're trying to mark clear-transient-map. > Nicolas, what is the bzr revision from which this Emacs was compiled? I don't use the bzr repo, but the git repo, so emacs-bzr-version will be nil. Unless I updated my git repo (but I don't think I did), it was git commit 5f7fb09: Author: YAMAMOTO Mitsuharu Date: Thu Mar 27 18:25:17 2014 +0200 -- Nico. From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Apr 2014 20:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: theonewiththeevillook@yahoo.fr, dmantipov@yandex.ru, 17168@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139647212523926 (code B ref 17168); Wed, 02 Apr 2014 20:56:02 +0000 Received: (at 17168) by debbugs.gnu.org; 2 Apr 2014 20:55:25 +0000 Received: from localhost ([127.0.0.1]:33368 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVSBw-0006Dp-H0 for submit@debbugs.gnu.org; Wed, 02 Apr 2014 16:55:24 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:58233) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVSBs-0006Dd-Gk for 17168@debbugs.gnu.org; Wed, 02 Apr 2014 16:55:22 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N3F008008K0J100@a-mtaout20.012.net.il> for 17168@debbugs.gnu.org; Wed, 02 Apr 2014 23:55:18 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N3F008YY8S6ES20@a-mtaout20.012.net.il>; Wed, 02 Apr 2014 23:55:18 +0300 (IDT) Date: Wed, 02 Apr 2014 23:55:30 +0300 From: Eli Zaretskii In-reply-to: <533C75A6.60900@dancol.org> X-012-Sender: halo1@inter.net.il Message-id: <83a9c3bge5.fsf@gnu.org> References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: 1.0 (+) > Date: Wed, 02 Apr 2014 13:40:06 -0700 > From: Daniel Colascione > CC: dmantipov@yandex.ru, theonewiththeevillook@yahoo.fr, > 17168@debbugs.gnu.org > > > (gdb) p Fsymbol_value(intern("emacs-bzr-version")) > > $5 = 57020481 > > (gdb) xtype > > Lisp_String > > (gdb) xstring > > $6 = (struct Lisp_String *) 0x3661040 > > "116894 rudalics@gmx.at-20140402143333-a56l2vy9oak0njsg" > > > > Alas, you cannot do this when debugging a core file, you need a > > running program. > > I was afraid of that. Would you object to declaring > emacs-repository-version in C so that we can find it more easily in core > dumps? I don't see anything wrong with that. From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Nicolas Richard Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Apr 2014 20:59:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: Nicolas Richard , Dmitry Antipov , 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139647228724209 (code B ref 17168); Wed, 02 Apr 2014 20:59:03 +0000 Received: (at 17168) by debbugs.gnu.org; 2 Apr 2014 20:58:07 +0000 Received: from localhost ([127.0.0.1]:33373 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVSEY-0006IO-Fj for submit@debbugs.gnu.org; Wed, 02 Apr 2014 16:58:06 -0400 Received: from mailrelay003.isp.belgacom.be ([195.238.6.53]:41806) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVSEV-0006IF-Sd for 17168@debbugs.gnu.org; Wed, 02 Apr 2014 16:58:04 -0400 X-Belgacom-Dynamic: yes Received: from 55.22-200-80.adsl-dyn.isp.belgacom.be (HELO LDLC-portable) ([80.200.22.55]) by relay.skynet.be with ESMTP; 02 Apr 2014 22:57:57 +0200 From: Nicolas Richard References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <533C7401.1070203@dancol.org> Date: Wed, 02 Apr 2014 22:57:57 +0200 In-Reply-To: <533C7401.1070203@dancol.org> (Daniel Colascione's message of "Wed, 02 Apr 2014 13:33:05 -0700") Message-ID: <87mwg3qwiy.fsf@yahoo.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (/) Daniel Colascione writes: > Also, Nicolas, can you call mem_find on 194710965, 188747058, and > 194710960? I must warn you that I'm a total ignorant of many things, including C and gdb. Here's my attempt : (gdb) mem_find(194710965) Undefined command: "mem_find". Try "help". (gdb) p mem_find(194710965) $1 = (struct mem_node *) 0xb9b1d50 (gdb) p mem_find(188747058) $2 = (struct mem_node *) 0xb709250 (gdb) p mem_find(194710960) $3 = (struct mem_node *) 0xb9b1d50 I guess that this information is of little value by itself, but I don't want to mess up things while trying to get more information. -- Nico. From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 02 17:41:40 2014 Received: (at control) by debbugs.gnu.org; 2 Apr 2014 21:41:40 +0000 Received: from localhost ([127.0.0.1]:33405 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVSuh-0007XA-FC for submit@debbugs.gnu.org; Wed, 02 Apr 2014 17:41:39 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:34546) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVSue-0007Wy-Hp for control@debbugs.gnu.org; Wed, 02 Apr 2014 17:41:37 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1WVSue-0000NF-4n for control@debbugs.gnu.org; Wed, 02 Apr 2014 17:41:36 -0400 Date: Wed, 02 Apr 2014 17:41:36 -0400 Message-Id: Subject: control message for bug 17168 To: X-Mailer: mail (GNU Mailutils 2.1) From: Glenn Morris X-Spam-Score: -5.6 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -5.6 (-----) forcemerge 15688 17168 From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Apr 2014 21:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Nicolas Richard Cc: Dmitry Antipov , 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.13964754421821 (code B ref 17168); Wed, 02 Apr 2014 21:51:01 +0000 Received: (at 17168) by debbugs.gnu.org; 2 Apr 2014 21:50:42 +0000 Received: from localhost ([127.0.0.1]:33420 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVT3R-0000TF-3F for submit@debbugs.gnu.org; Wed, 02 Apr 2014 17:50:41 -0400 Received: from dancol.org ([96.126.100.184]:42963) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVT3P-0000T7-38 for 17168@debbugs.gnu.org; Wed, 02 Apr 2014 17:50:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=H21XFi/uih5WA8u3ya2Q6Yg9TfhK0WbfVWUvcufNKik=; b=PNLyxbStpW4oeHzhcnoaV6f+h3qdAmF/6wyO7sqc2g2EByyaTGKgoxWkMXBKSLQmcAxW+wWxK2h/N17cfRxeU9cesItwtYdp/GvKrim8EJlyljJZnG7mfIZwZJGVjUD3HGrerfEoJ6gGL1JIqqtqK6pW8nf0EkahH5giEKKukEPwpRBpbVwmooN3IXRdN79OXM8sYU6G9sTwrPkqK65ZvZtFw2MPo5IvnltooZWAhlNRoTh4GKAckWbuvkKvPUzG/yhazzVYBypwvMZsafOoyIyMEEBHMg+PW1Hyqd9jnUPvjdlgLNPlUGU205MFe7MvKJok/T0W7E3kONtFtxYnEQ==; Received: from [2620:0:1cfe:a1:2b5:6dff:fe00:f9a6] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WVT3J-0006tE-DT; Wed, 02 Apr 2014 14:50:33 -0700 Message-ID: <533C8621.5070805@dancol.org> Date: Wed, 02 Apr 2014 14:50:25 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <533C7401.1070203@dancol.org> <87mwg3qwiy.fsf@yahoo.fr> In-Reply-To: <87mwg3qwiy.fsf@yahoo.fr> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sVCb5wdUpcifK8hFjaqrqmEq3mwt32l5W" X-Spam-Score: -0.6 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.6 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sVCb5wdUpcifK8hFjaqrqmEq3mwt32l5W Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/02/2014 01:57 PM, Nicolas Richard wrote: > Daniel Colascione writes: >> Also, Nicolas, can you call mem_find on 194710965, 188747058, and >> 194710960? >=20 > I must warn you that I'm a total ignorant of many things, including C > and gdb. Here's my attempt : >=20 > (gdb) mem_find(194710965) > Undefined command: "mem_find". Try "help". > (gdb) p mem_find(194710965) > $1 =3D (struct mem_node *) 0xb9b1d50 > (gdb) p mem_find(188747058) > $2 =3D (struct mem_node *) 0xb709250 > (gdb) p mem_find(194710960) > $3 =3D (struct mem_node *) 0xb9b1d50 >=20 > I guess that this information is of little value by itself, but I don't= > want to mess up things while trying to get more information. Thanks. I looked at the dump and checked that what we already know is correct. The vector we're trying to mark is in mem_node 0xb9b1d50: (gdb) set $m =3D (struct mem_node *) 0xb9b1d50 (gdb) print *$m $116 =3D { left =3D 0x84b6c20 , right =3D 0x84b6c20 , parent =3D 0x93b2f08, start =3D 0xb9b0d50, end =3D 0xb9b1d48, color =3D MEM_RED, type =3D MEM_TYPE_VECTOR_BLOCK The contents of the block begin here: (gdb) set $block =3D (struct vector_block*) ($m->start) (gdb) print $block $122 =3D (struct vector_block *) 0xb9b0d50 (gdb) set $vector =3D (struct Lisp_Vector*) $block->data (gdb) print *$block $123 =3D { data =3D "\023\000\000\200\342\210M\bJ\334M\bJ\334M\bJ\334M\bJ\334M\bJ\334M\bJ\334= M\bJ\334M\bJ\334M\b\201\331p\nJ\334M\bJ\334M\bJ\334M\bJ\334M\bJ\334M\bJ\3= 34M\bJ\334M\bJ\334M\bJ\334M\b\006\000\000\314\302\207M\b\201\272\271\fm=C9= =8F\v$\000\000\200&\243\060\f\302\207M\b\"_m\b\000\020\000Ax\366\267\f\b\= 200\000\311]S@\f=CD=9E\234\f\325\330M\b\302\207M\b\302\207M\b=CD=9E\234\f= \302\207M\b\025\016\233\v\302\000\000\000+", '\000' , "\302\000\000\000+", '\000' , "\061\064:0\002\000\000\200%\016\233\v\245\016\233\vven "..., next =3D 0xb9cc2a8 The vector we're trying to mark is 96 bytes inside this block: (gdb) print (char*)ptr - (char*)$vector $135 =3D 96 The first vector in the block is a regular vector with 0x13 elements: (gdb) print/x $vector->header.size $156 =3D 0x80000013 It's 80 bytes long: (gdb) print header_size + (($vector->header.size &~ ARRAY_MARK_FLAG) * word_size) $148 =3D 80 The next vector in the block is a PVEC_COMPILED: (gdb) print/x $vector->header.size $159 =3D 0xcc000006 It's 32 bytes long, which means that we're trying to mark a pointer into the middle of the vector. The clear-transient-map symbol itself, of course, is live. It's perfectly normal and its value slot is set to Qunbound. --sVCb5wdUpcifK8hFjaqrqmEq3mwt32l5W Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTPIYhAAoJEMAaIROpHW7Is9QQAMCYHaYQshPDGcE3zfNYvJ5F n7NYG5L0ugHYrsA3lAGT/jEPTw+MU98smLbgWJZdmE4FI6VcMSt9QUJxRuwR02ND MZKXuFeqvKp257bhUh09KjepSixS3YF5V4hSrflWNzoXr8RUwxbj7l3WQVHvzVUK pY61MS0DhK2DTKvlhTE/1Yr4C5nna7wdxrtbyz7JXs59alh8WdjhjSCXHx6qA+XK jHenqUmNSKC5wmB1iv+o7/caRZ4UffDAzkFJBq40kwtVAkYttTmGOETJ29WizMqO GzKhINFuGrRhXcMxjEeIs1lCw4NeJmNxMGarQnZpdcOAmlT6Li/lTEQjU22YMLNE dvXO22HUZ0a2KZUOXF5RxzIRbwcFtBzjyrpGWSSAwZaOkppW3cul0CcoHhuilMtX ebxGtNBojuKgF2SZGrR0RCbVNwFwqDj8GKEE5zE+roBHFKTm5q2FEyr3Csys8zkx LLlX1rmChr7kAZFAXYuinGwk/50qH0qUFQJpzyoKXPhrMgnVANLQHTqjx+0Z/PwA qKC3eSF8tGF7QoVZeYiIxZdeutCF5vkriSd/alZzaGLEm5gqyRD+FmRlM61guWmy VkkjD3KM2dL38FarSk5zQI2wLhAZhxao0zcmo71bN6ETDUdq/099Pq7/1sJ9QxqP ufQ+pz6KBMBCBcLkZ04n =njL/ -----END PGP SIGNATURE----- --sVCb5wdUpcifK8hFjaqrqmEq3mwt32l5W-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Apr 2014 23:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Daniel Colascione Cc: Nicolas Richard , Dmitry Antipov , 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139648108111618 (code B ref 17168); Wed, 02 Apr 2014 23:25:02 +0000 Received: (at 17168) by debbugs.gnu.org; 2 Apr 2014 23:24:41 +0000 Received: from localhost ([127.0.0.1]:33456 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVUWO-00031J-SV for submit@debbugs.gnu.org; Wed, 02 Apr 2014 19:24:41 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:38973) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVUWM-00031A-Ru for 17168@debbugs.gnu.org; Wed, 02 Apr 2014 19:24:39 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s32NOVNR001435; Wed, 2 Apr 2014 19:24:31 -0400 Received: by pastel.home (Postfix, from userid 20848) id D386C602E2; Wed, 2 Apr 2014 19:24:30 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <533C7401.1070203@dancol.org> <87mwg3qwiy.fsf@yahoo.fr> <533C8621.5070805@dancol.org> Date: Wed, 02 Apr 2014 19:24:30 -0400 In-Reply-To: <533C8621.5070805@dancol.org> (Daniel Colascione's message of "Wed, 02 Apr 2014 14:50:25 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4900=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4900> : inlines <685> : streams <1150664> : uri <1718448> X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -1.9 (-) > It's 32 bytes long, which means that we're trying to mark a pointer into > the middle of the vector. > The clear-transient-map symbol itself, of course, is live. It's > perfectly normal and its value slot is set to Qunbound. So, IIUC the symbol-function slot of the clear-transient-map symbol points in the middle of a vector? Since the symbol-function slot of the clear-transient-map symbol is only set once, I think this means that the vector to which it pointed has been somehow freed. Of course that shouldn't be possible: at any previous GC, either the clear-transient-map symbol was found live and traced (so the vector to which it pointed shouldn't have been freed) or it wasn't found live, in which case the symbol-function slot should have been set to the special "dead" value. Stefan From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Apr 2014 00:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Stefan Monnier Cc: Nicolas Richard , Dmitry Antipov , 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139648493718049 (code B ref 17168); Thu, 03 Apr 2014 00:29:01 +0000 Received: (at 17168) by debbugs.gnu.org; 3 Apr 2014 00:28:57 +0000 Received: from localhost ([127.0.0.1]:33480 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVVWa-0004h2-B0 for submit@debbugs.gnu.org; Wed, 02 Apr 2014 20:28:56 -0400 Received: from dancol.org ([96.126.100.184]:43626) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVVWW-0004gq-Vy for 17168@debbugs.gnu.org; Wed, 02 Apr 2014 20:28:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=EEoWCr83+KYl/h6yP7XO2N56pfJHI7bcyYo4O6UuoKE=; b=rNADU2REPICoaCu+PFGm2gTPh/4xBeNgM2ST8nRyY9qJ0OZ10pNFDlxQpFP9i+sUOuHNkPVEbtg/qnGi01pKDJgoOh8U/VeDI/rm2/jlSYf9JPVqNx9H9kSx+7ZK/LFgD/u9P1a3qWliEG6lNqaziy+g9jUVpPEOoFJA2G1ss3to0OF82SagEoUA4d61uFV5HVIEUCAYvxMXEIGfjmhNgF20gdSdbucNdSlD/CL9+jAVWxr/EyZ57/zdnCqVtPoznSEVzi3c3hnRD+pMV7nvZIjbxzn6P0dZIATQKGAZlOv/pLihDlK9ktHPeXTMgn5qaB8/KGQvAzpC8TvfW+f1Qw==; Received: from [2620:0:1cfe:a1:2b5:6dff:fe00:f9a6] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WVVWQ-0007Uu-FE; Wed, 02 Apr 2014 17:28:46 -0700 Message-ID: <533CAB36.7080505@dancol.org> Date: Wed, 02 Apr 2014 17:28:38 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <533C7401.1070203@dancol.org> <87mwg3qwiy.fsf@yahoo.fr> <533C8621.5070805@dancol.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KiMnbAApevhXlWXWn8CcuCO9mUTjnPTx2" X-Spam-Score: -0.6 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.6 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KiMnbAApevhXlWXWn8CcuCO9mUTjnPTx2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/02/2014 04:24 PM, Stefan Monnier wrote: >> It's 32 bytes long, which means that we're trying to mark a pointer in= to >> the middle of the vector. >> The clear-transient-map symbol itself, of course, is live. It's >> perfectly normal and its value slot is set to Qunbound. >=20 > So, IIUC the symbol-function slot of the clear-transient-map symbol > points in the middle of a vector? That's what my analysis seems to indicate. > Since the symbol-function slot of the clear-transient-map symbol is onl= y > set once, I think this means that the vector to which it pointed has > been somehow freed. That's what I speculated last week, but I still have no idea how it would be possible. > Of course that shouldn't be possible: at any previous GC, either the > clear-transient-map symbol was found live and traced (so the vector to > which it pointed shouldn't have been freed) or it wasn't found live, in= > which case the symbol-function slot should have been set to the special= > "dead" value. I added some code to trunk that might help track down the problem. Now we can mark certain objects as "suspicious" (only vectors for now, but that's sufficient); when we free one of these suspicious objects, we record a stack trace. This way, if we crash later, we can figure out where things went wrong. --KiMnbAApevhXlWXWn8CcuCO9mUTjnPTx2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTPKs2AAoJEMAaIROpHW7IYGgP/1IMl27Qp0inSkj4VaawhK3j sWfBYDK8JzKHLgU2fGy5ORn9sS9oN4vwUlhfaAoKIwMNp6xDC6ruLVwFlq2MdYw7 u2Mi2FyLcqFwK0PO7PbUgBINZ1H2JDmvSiWNqaqEsNnu6bAFj4Wk8XNomO8ohZlE XPhXxOHPSnkVKLdFuhYNAfkJa7WZvM04tLIErCDFEwWywANEVFrSwWMTUqSc2j7w AOnkTYzIcVJi6FfvAejT7CD+KWvaACPwZiGhiZvaESLG8MBE3VJP2GCP9n3W5Lu7 DlCHd86RPfmcmBVh4k7EOTnkDwXFFCO7WzzqODTENJ+y+xmE0VeSnHQ0RW/E0Z5+ mIMtpbyW0Jbk8+UN/kx1I4ZfTSbF4thY5CKm3sI0kZurKm0q6ESSeljUd/wWz8rN YxBVczMnfuWo7oXd0Cx4uGgIGglRLiLXWfHzf48s0K3+ruztqnoRlC1S/OxDlFXi E/31KAbggCYg0/RrZHBZPWhyGlO4W5BZ2gSDdBYkWPXgNik0HP2Emd+LP9MS23Hh uo/xfSBp42T1lp9qNWnZ86K+bNQ/uLvoiZaKVV6aYEx+9f+N66JfR/jI8fGypEa3 pxqn/SLFsXdB/6oaEiA4a8XMpRXuSvM/KaRQlWKUavBS7FJzmDhcYokSqWmVn1ef GEp9BN+RHrX5SJr8bcI8 =9T4I -----END PGP SIGNATURE----- --KiMnbAApevhXlWXWn8CcuCO9mUTjnPTx2-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Dmitry Antipov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Apr 2014 07:00:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: 17168@debbugs.gnu.org Cc: theonewiththeevillook@yahoo.fr, Eli Zaretskii , Daniel Colascione Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139650839825528 (code B ref 17168); Thu, 03 Apr 2014 07:00:03 +0000 Received: (at 17168) by debbugs.gnu.org; 3 Apr 2014 06:59:58 +0000 Received: from localhost ([127.0.0.1]:33662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVbcz-0006de-Hm for submit@debbugs.gnu.org; Thu, 03 Apr 2014 02:59:58 -0400 Received: from forward8l.mail.yandex.net ([84.201.143.141]:54183) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVbcv-0006dR-S9 for 17168@debbugs.gnu.org; Thu, 03 Apr 2014 02:59:55 -0400 Received: from smtp2h.mail.yandex.net (smtp2h.mail.yandex.net [84.201.187.145]) by forward8l.mail.yandex.net (Yandex) with ESMTP id 90E4E1A40E2E; Thu, 3 Apr 2014 10:59:51 +0400 (MSK) Received: from smtp2h.mail.yandex.net (localhost [127.0.0.1]) by smtp2h.mail.yandex.net (Yandex) with ESMTP id EFE891703F20; Thu, 3 Apr 2014 10:59:50 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp2h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id fBDtCJCLH2-xoFO2IhX; Thu, 3 Apr 2014 10:59:50 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 35abbbae-0cb8-44d6-a5b9-195cb108748a DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1396508390; bh=zWiiklPV+C46Xvu2KabIefyxNxLH7QPzEWEtq126mBE=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type; b=eJxgZ7z9NVuHT81UoUaK+njpYMW6bpShOJGDBeJIM5f1+M91RKnlIMJZYNSGkwGTk MH3DHiQl5sULkNeSKYwMFxrnrsq9bIrqn2jRauL+PgF59hpkodmjxbP1DJXcGtUDYE r5SivVUH37fFMjCBjxlsZ/0kGc6rmW7RNvUUpugY= Authentication-Results: smtp2h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <533D06E6.2060001@yandex.ru> Date: Thu, 03 Apr 2014 10:59:50 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> In-Reply-To: <533C75A6.60900@dancol.org> Content-Type: multipart/mixed; boundary="------------050401080701070809060504" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (/) This is a multi-part message in MIME format. --------------050401080701070809060504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hopefully I found the way to catch bogus object in 'function' slot of a Lisp_Symbol. 100% reproducible for me, as of bzr revision 116934. 1. Apply this patch. 2. Compile with -O0 -g3 and --enable-checking. 3. Run 'emacs -Q', then M-x byte-force-recompile /path/to/trunk/lis/org 4. Crash ==> #0 0x000000379220f62b in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37 #1 0x0000000000569aff in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at ../../trunk/src/emacs.c:382 #2 0x00000000005f089a in die ( msg=0x70f498 "SYMBOLP (sym->s.function) || CONSP (sym->s.function) || COMPILEDP (sym->s.function) || SUBRP (sym->s.function)", file=0x70e420 "../../trunk/src/alloc.c", line=6613) at ../../trunk/src/alloc.c:6913 #3 0x00000000005f00b5 in sweep_symbols () at ../../trunk/src/alloc.c:6610 #4 0x00000000005f03bb in gc_sweep () at ../../trunk/src/alloc.c:6735 #5 0x00000000005ede1e in Fgarbage_collect () at ../../trunk/src/alloc.c:5632 #6 0x0000000000567706 in maybe_gc () at ../../trunk/src/lisp.h:4520 #7 0x000000000065b95f in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=2, args=0x7fff66de7f70) at ../../trunk/src/bytecode.c:954 [...next frames probably irrelevant...] Dmitry --------------050401080701070809060504 Content-Type: text/x-patch; name="bug17168_bogus_function_eassert.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bug17168_bogus_function_eassert.patch" === modified file 'src/alloc.c' --- src/alloc.c 2014-04-03 00:37:51 +0000 +++ src/alloc.c 2014-04-03 06:42:53 +0000 @@ -6174,6 +6174,11 @@ break; CHECK_ALLOCATED_AND_LIVE (live_symbol_p); ptr->gcmarkbit = 1; + /* Attempt to catch bogus objects. */ + eassert (SYMBOLP (ptr->function) + || CONSP (ptr->function) + || COMPILEDP (ptr->function) + || SUBRP (ptr->function)); mark_object (ptr->function); mark_object (ptr->plist); switch (ptr->redirect) @@ -6601,6 +6606,11 @@ if (!pure_p) eassert (!STRING_MARKED_P (XSTRING (sym->s.name))); sym->s.gcmarkbit = 0; + /* Attempt to catch bogus objects. */ + eassert (SYMBOLP (sym->s.function) + || CONSP (sym->s.function) + || COMPILEDP (sym->s.function) + || SUBRP (sym->s.function)); } } --------------050401080701070809060504-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Dmitry Antipov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Apr 2014 07:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139650866026136 (code B ref 17168); Thu, 03 Apr 2014 07:05:01 +0000 Received: (at 17168) by debbugs.gnu.org; 3 Apr 2014 07:04:20 +0000 Received: from localhost ([127.0.0.1]:33674 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVbhE-0006nT-1k for submit@debbugs.gnu.org; Thu, 03 Apr 2014 03:04:20 -0400 Received: from forward3l.mail.yandex.net ([84.201.143.136]:45208) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVbhA-0006nK-V7 for 17168@debbugs.gnu.org; Thu, 03 Apr 2014 03:04:17 -0400 Received: from smtp2h.mail.yandex.net (smtp2h.mail.yandex.net [84.201.187.145]) by forward3l.mail.yandex.net (Yandex) with ESMTP id C49B61500E53 for <17168@debbugs.gnu.org>; Thu, 3 Apr 2014 11:04:15 +0400 (MSK) Received: from smtp2h.mail.yandex.net (localhost [127.0.0.1]) by smtp2h.mail.yandex.net (Yandex) with ESMTP id 5C9361703F27 for <17168@debbugs.gnu.org>; Thu, 3 Apr 2014 11:04:15 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp2h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id BbUKIpHawJ-4FF8JP9m; Thu, 3 Apr 2014 11:04:15 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 1a33769f-00a5-4cd5-a6ce-93f77b565a89 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1396508655; bh=Xk8Dx6g6eRTvMB+/rgREZ5neM3e642LRr/AX0BB5IN4=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=KJb6tF3QUHbPJyKIDDbjDEvXC5GMprdG+oBa/frhlZUobIy8OPQq3KFBMwcEK8pLv +FWukDvDb6Pb+si+SrHjcncUjUiM4ZCHo/nYvi+88A6QXGdrrWadpmP9s8kGQbzKNT M9Rx/qjdPYCydnRd5oBs4UMlVZoB2RQ0f5PuOEz8= Authentication-Results: smtp2h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <533D07EF.1040502@yandex.ru> Date: Thu, 03 Apr 2014 11:04:15 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> In-Reply-To: <533D06E6.2060001@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 04/03/2014 10:59 AM, Dmitry Antipov wrote: > 3. Run 'emacs -Q', then M-x byte-force-recompile > /path/to/trunk/lis/org ^^^^^^^ Mean /path/to/trunk/lisp/org, i.e. all Org mode. Dmitry From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Apr 2014 07:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Dmitry Antipov , 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139651172331092 (code B ref 17168); Thu, 03 Apr 2014 07:56:02 +0000 Received: (at 17168) by debbugs.gnu.org; 3 Apr 2014 07:55:23 +0000 Received: from localhost ([127.0.0.1]:33698 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVcUc-00085N-H1 for submit@debbugs.gnu.org; Thu, 03 Apr 2014 03:55:23 -0400 Received: from dancol.org ([96.126.100.184]:45967) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVcUX-00085C-CJ for 17168@debbugs.gnu.org; Thu, 03 Apr 2014 03:55:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=QAQ1HO6JfIPx1ZOWIGeBHH0QzZJylTD/zLib6z06SHw=; b=eFpk3r8FYqLr5sPv48qc3H0LT0ZWewMwU8Mht67QypYXikpkQ0kbPNtxe7gIkirYU4slK2OJ1nX6oTR7RTNyKGW9cXxD11qZ2H3HHptO443FQQvJ0Ot3EG5YVEd9kB4SYd20g2urVx7Oi0BEhmmwJhYKtzDJf1gEL5eOfxmZP/gzZMQ6KqkUdgeY1CyextqTV4d8j+LrMcuRTCd1/h3D2jNNdqfUt+/t9YZIZlNRcLYAiyDVoQGNMAhrKYoJyIcrH4axEBrg02T4zpe4kVIHbkHKU2zbwkynY9/T6cdkf1/hyv9nXp15Y/z46YueueYJOyIFt3ddPR0mTiSBr7gcDQ==; Received: from [2601:8:b200:551::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WVcUW-0001AB-6h; Thu, 03 Apr 2014 00:55:16 -0700 Message-ID: <533D13E2.3060300@dancol.org> Date: Thu, 03 Apr 2014 00:55:14 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> In-Reply-To: <533D07EF.1040502@yandex.ru> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CrRGoDVqg6eqe4uhgqBgG4cEAgsTUJKn7" X-Spam-Score: -0.6 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.6 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CrRGoDVqg6eqe4uhgqBgG4cEAgsTUJKn7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/03/2014 12:04 AM, Dmitry Antipov wrote: > On 04/03/2014 10:59 AM, Dmitry Antipov wrote: >=20 >> 3. Run 'emacs -Q', then M-x byte-force-recompile >> /path/to/trunk/lis/org > ^^^^^^^ > Mean /path/to/trunk/lisp/org, i.e. all Org mode. Nice work. What gave you the idea of using byte-force-recompile to repro? I'd tried a few other stress cases myself and couldn't find anything. Your repro works perfectly. In eval-after-load, we have code that looks like this: (fset fun (lambda (file) (when (equal file lfn) (remove-hook 'after-load-functions fun) (funcall func)))) This code looks just like the subr.el code that was causing problems for Richard. I changed eval-after-load locally to something like this and re-ran: (fset fun (suspicious-object (lambda (file) (when (equal file lfn) (remove-hook 'after-load-functions fun) (funcall func))))) When your assertion hits, the vector we're trying to free mark is dead and seems to have garbage in the function slot. It's already been freed. Below is the spot where we're freeing that lambda. If we don't set an alloc.c breakpoint and let the code continue to assertion failure, then the stack in suspicious_free_history is exactly what's below. Breakpoint 4, detect_suspicious_free (ptr=3D0x1c363f8) at alloc.c:6868 6868 rec =3D &suspicious_free_history[suspicious_free_history_index++]; (gdb) wher #0 detect_suspicious_free (ptr=3D0x1c363f8) at alloc.c:6868 #1 0x000000000056779e in cleanup_vector (vector=3D0x1c363f8) at alloc.c:= 2959 #2 0x0000000000567962 in sweep_vectors () at alloc.c:3017 #3 0x000000000056dd69 in gc_sweep () at alloc.c:6738 #4 0x000000000056b893 in Fgarbage_collect () at alloc.c:5632 #5 0x00000000004e4c95 in maybe_gc () at lisp.h:4520 #6 0x00000000005d96f4 in exec_byte_code (bytestr=3D13432081, vector=3D29098381, maxdepth=3D16, args_template=3D0, nargs=3D0, args=3D0x7fffffff9410) at bytecode.c:753 #7 0x0000000000590e39 in funcall_lambda (fun=3D29327469, nargs=3D0, arg_vector=3D0x7fffffff9410) at eval.c:2983 #8 0x0000000000590828 in Ffuncall (nargs=3D1, args=3D0x7fffffff9408) at eval.c:2864 #9 0x00000000005d9ecb in exec_byte_code (bytestr=3D13433121, vector=3D29327533, maxdepth=3D4, args_template=3D0, nargs=3D0, args=3D0x7fffffff9928) at bytecode.c:919 #10 0x0000000000590e39 in funcall_lambda (fun=3D29098549, nargs=3D0, arg_vector=3D0x7fffffff9928) at eval.c:2983 #11 0x0000000000590828 in Ffuncall (nargs=3D1, args=3D0x7fffffff9920) at eval.c:2864 #12 0x000000000058ee87 in eval_sub (form=3D29022502) at eval.c:2157 #13 0x000000000058cb9a in internal_lisp_condition_case (var=3D13413026, bodyform=3D29022502, handlers=3D29022406) at eval.c:1323 #14 0x00000000005db0ac in exec_byte_code (bytestr=3D13431537, vector=3D18344837, maxdepth=3D64, args_template=3D1028, nargs=3D1, args=3D0x7fffffffa0f8= ) at bytecode.c:1169 #15 0x0000000000590e39 in funcall_lambda (fun=3D18345373, nargs=3D1, arg_vector=3D0x7fffffffa0f0) at eval.c:2983 #16 0x0000000000590828 in Ffuncall (nargs=3D2, args=3D0x7fffffffa0e8) at eval.c:2864 #17 0x00000000005d9ecb in exec_byte_code (bytestr=3D13425857, vector=3D18336269, maxdepth=3D68, args_template=3D2052, nargs=3D2, args=3D0x7fffffffa680= ) at bytecode.c:919 #18 0x0000000000590e39 in funcall_lambda (fun=3D18337101, nargs=3D2, arg_vector=3D0x7fffffffa670) at eval.c:2983 #19 0x0000000000590828 in Ffuncall (nargs=3D3, args=3D0x7fffffffa668) at eval.c:2864 #20 0x00000000005d9ecb in exec_byte_code (bytestr=3D13424785, vector=3D17895757, maxdepth=3D40, args_template=3D4100, nargs=3D3, args=3D0x7fffffffabd0= ) at bytecode.c:919 #21 0x0000000000590e39 in funcall_lambda (fun=3D17895885, nargs=3D3, arg_vector=3D0x7fffffffabb8) at eval.c:2983 #22 0x0000000000590828 in Ffuncall (nargs=3D4, args=3D0x7fffffffabb0) at eval.c:2864 #23 0x00000000005d9ecb in exec_byte_code (bytestr=3D13414625, vector=3D17008333, maxdepth=3D28, args_template=3D0, nargs=3D0, args=3D0x7fffffffb0e0) at bytecode.c:919 #24 0x0000000000590e39 in funcall_lambda (fun=3D18006989, nargs=3D0, arg_vector=3D0x7fffffffb0e0) at eval.c:2983 #25 0x0000000000590828 in Ffuncall (nargs=3D1, args=3D0x7fffffffb0d8) at eval.c:2864 #26 0x00000000005d9ecb in exec_byte_code (bytestr=3D13424001, vector=3D18250445, maxdepth=3D4, args_template=3D0, nargs=3D0, args=3D0x7fffffffb5f8) at bytecode.c:919 #27 0x0000000000590e39 in funcall_lambda (fun=3D18327557, nargs=3D0, arg_vector=3D0x7fffffffb5f8) at eval.c:2983 #28 0x0000000000590828 in Ffuncall (nargs=3D1, args=3D0x7fffffffb5f0) at eval.c:2864 #29 0x000000000058ee87 in eval_sub (form=3D13218422) at eval.c:2157 #30 0x000000000058cb9a in internal_lisp_condition_case (var=3D13412402, bodyform=3D13218422, handlers=3D13218310) at eval.c:1323 #31 0x00000000005db0ac in exec_byte_code (bytestr=3D13414065, vector=3D17986453, maxdepth=3D104, args_template=3D3076, nargs=3D3, args=3D0x7fffffffbdf= 0) at bytecode.c:1169 #32 0x0000000000590e39 in funcall_lambda (fun=3D17986813, nargs=3D3, arg_vector=3D0x7fffffffbdd8) at eval.c:2983 #33 0x0000000000590828 in Ffuncall (nargs=3D4, args=3D0x7fffffffbdd0) at eval.c:2864 #34 0x00000000005d9ecb in exec_byte_code (bytestr=3D13413841, vector=3D17986061, maxdepth=3D20, args_template=3D1028, nargs=3D1, args=3D0x7fffffffc278= ) at bytecode.c:919 #35 0x0000000000590e39 in funcall_lambda (fun=3D17986093, nargs=3D1, arg_vector=3D0x7fffffffc270) at eval.c:2983 #36 0x0000000000590b45 in apply_lambda (fun=3D17986093, args=3D17246278) at eval.c:2924 #37 0x000000000058f191 in eval_sub (form=3D17246438) at eval.c:2230 #38 0x00000000005c0a79 in readevalloop (readcharfun=3D17665045, stream=3D= 0x0, sourcename=3D13097937, printflag=3Dfalse, unibyte=3D12966770, readfun=3D12966770, start=3D12966770, end=3D12966770) at lread.c:1934 #39 0x00000000005c0d4f in Feval_buffer (buffer=3D17665045, printflag=3D12966770, filename=3D16200945, unibyte=3D12966770, do_allow_print=3D12966818) at lread.c:1995 #40 0x0000000000590702 in Ffuncall (nargs=3D6, args=3D0x7fffffffc5e8) at eval.c:2831 #41 0x00000000005d9ecb in exec_byte_code (bytestr=3D9101593, vector=3D910= 1629, maxdepth=3D24, args_template=3D12966770, nargs=3D0, args=3D0x0) at bytecode.c:919 #42 0x0000000000591224 in funcall_lambda (fun=3D9101469, nargs=3D4, arg_vector=3D0x8ae13d ) at eval.c:3049 #43 0x0000000000590828 in Ffuncall (nargs=3D5, args=3D0x7fffffffcb80) at eval.c:2864 #44 0x00000000005900a9 in call4 (fn=3D13233138, arg1=3D16200945, arg2=3D1= 6200945, arg3=3D12966770, arg4=3D12966818) at eval.c:2663 #45 0x00000000005bf0ce in Fload (file=3D12968289, noerror=3D12966770, nomessage=3D12966818, nosuffix=3D12966770, must_suffix=3D12966770) at lread.c:1305 #46 0x0000000000590702 in Ffuncall (nargs=3D4, args=3D0x7fffffffcf18) at eval.c:2831 #47 0x00000000005d9ecb in exec_byte_code (bytestr=3D9509777, vector=3D950= 9813, maxdepth=3D92, args_template=3D1028, nargs=3D1, args=3D0x7fffffffd468= ) at bytecode.c:919 #48 0x0000000000590e39 in funcall_lambda (fun=3D9509733, nargs=3D1, arg_vector=3D0x7fffffffd460) at eval.c:2983 #49 0x0000000000590828 in Ffuncall (nargs=3D2, args=3D0x7fffffffd458) at eval.c:2864 #50 0x00000000005d9ecb in exec_byte_code (bytestr=3D9483993, vector=3D948= 4029, maxdepth=3D68, args_template=3D0, nargs=3D0, args=3D0x7fffffffd9f8) at bytecode.c:919 #51 0x0000000000590e39 in funcall_lambda (fun=3D9483949, nargs=3D0, arg_vector=3D0x7fffffffd9f8) at eval.c:2983 #52 0x0000000000590828 in Ffuncall (nargs=3D1, args=3D0x7fffffffd9f0) at eval.c:2864 #53 0x00000000005d9ecb in exec_byte_code (bytestr=3D9480481, vector=3D948= 0517, maxdepth=3D48, args_template=3D0, nargs=3D0, args=3D0x7fffffffded0) at bytecode.c:919 #54 0x0000000000590e39 in funcall_lambda (fun=3D9480437, nargs=3D0, arg_vector=3D0x7fffffffded0) at eval.c:2983 #55 0x0000000000590b45 in apply_lambda (fun=3D9480437, args=3D12966770) at eval.c:2924 #56 0x000000000058f191 in eval_sub (form=3D13213110) at eval.c:2230 #57 0x000000000058e66c in Feval (form=3D13213110, lexical=3D12966770) at eval.c:2003 #58 0x00000000004eb0a4 in top_level_2 () at keyboard.c:1183 #59 0x000000000058ccfd in internal_condition_case ( bfun=3D0x4eb087 , handlers=3D13017586, hfun=3D0x4eab6d ) at eval.c:1354 #60 0x00000000004eb0de in top_level_1 (ignore=3D12966770) at keyboard.c:1= 191 #61 0x000000000058c181 in internal_catch (tag=3D13013522, func=3D0x4eb0a6 , arg=3D12966770) at eval.c:1118 #62 0x00000000004eaffd in command_loop () at keyboard.c:1152 #63 0x00000000004ea678 in recursive_edit_1 () at keyboard.c:777 #64 0x00000000004ea85d in Frecursive_edit () at keyboard.c:845 #65 0x00000000004e8748 in main (argc=3D5, argv=3D0x7fffffffe3a8) at emacs= =2Ec:1654 Lisp Backtrace: "Automatic GC" (0xc51790) 0x1bf8068 PVEC_COMPILED 0x1bc0230 PVEC_COMPILED "funcall" (0xffff9920) "byte-compile-from-buffer" (0xffffa0f0) "byte-compile-file" (0xffffa670) "byte-recompile-file" (0xffffabb8) 0x112c3c8 PVEC_COMPILED 0x117a800 PVEC_COMPILED "funcall" (0xffffb5f0) "byte-recompile-directory" (0xffffbdd8) "byte-force-recompile" (0xffffc270) "eval-buffer" (0xffffc5f0) "load-with-code-conversion" (0xffffcb88) "load" (0xffffcf20) "command-line-1" (0xffffd460) "command-line" (0xffffd9f8) "normal-top-level" (0xffffded0) --CrRGoDVqg6eqe4uhgqBgG4cEAgsTUJKn7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTPRPiAAoJEMAaIROpHW7IoLIQAJveV6ywCgVwQ0cO6CpDN2xJ chrRO5pFefGmN1Unl7LEm/GhrSd8+8oiPdop7ni5Tto6xts2wo98m+xh6OmIA6hY bxpjxL/qTadmXIpixUwQT7sKsEpWHRnFVZ75gBZHdd8DEXl9r+UDzu5Oq+nN7+iK 7OfwTIXQqD/UeRrWauhLXDDsrLazEnlaN8qXnUaC6v4mTsEe8JoBUCzOf40KHZgb jbrjSZ2q4wY6kSCSebVM4Im5lD2k0kF7g4shWlZLr5djpXijlyXWzhX/MY78Vvtl n6gamGYJMrSVFlvx5srcSJ7iXyfSsDQDW346Qa28XfE5h2IScMwBkCLWQGG86FMC oYutCisYdEUnheVjDRbfbC99z08HetOUuS620XnsIoJaZaEbMTeREdq08pku0tnS to8MLhUPzHYHMGO2eXXCMs5b0v0oOs6lurlwvh0L8t0LgzSuhNJaZ3YrrILLQ9Oz kzfT72IDIPC/7FSW8/sEiDgD4CIk6GvYH++4/Bg9xAzEzeVOvpaTJyPr+DtEEWZh KIzRDr+yJMu5kOurBXNkWkP2IjTplGKIhKaclAlS0X85FIExVf22CKzxXGUDOEOu UMl4uHCnnMFBirzQbzhOCDLIvTCsxaTTT5kPW+/n3gGhtN9pMoJ8MNFl7TycYyCo bIsq81VbvYs61dxelIxO =4gXW -----END PGP SIGNATURE----- --CrRGoDVqg6eqe4uhgqBgG4cEAgsTUJKn7-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Apr 2014 09:09:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Dmitry Antipov , 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.13965161405999 (code B ref 17168); Thu, 03 Apr 2014 09:09:03 +0000 Received: (at 17168) by debbugs.gnu.org; 3 Apr 2014 09:09:00 +0000 Received: from localhost ([127.0.0.1]:33755 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVddq-0001Ye-U3 for submit@debbugs.gnu.org; Thu, 03 Apr 2014 05:08:59 -0400 Received: from dancol.org ([96.126.100.184]:46294) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVddh-0001YM-BY for 17168@debbugs.gnu.org; Thu, 03 Apr 2014 05:08:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=fqAL792o76QyjQP2mOLqFgNfctWutMYA3IS4OMxfJUk=; b=Z4FsRG+UeBdY52Oz+1Xc1jEEIZyFttCzQ2VPq0hdnMU2U/wbsRlyA2jJP0n8sSZOuOcDnXIGaSL4A+5qoSaLDpZx4mmzdyeH6IK5nq/M4p9YTy9VlH7ozzUFpirWneZ+f581B82oIs9XamaOSQYkbBWC9JORrJ15TpxfSmYpoj7ojw8pfnhorUQitQ9zwYlLDKuqBvn+F9LCH3/muNFmJEafwLFwAOK+onJeGcNuHZCi7La7X1fMGyp3WXMvVpt+mATn+tF+Qd6YVsumecF2SzgwZiXT2+2YYxunF1GXo77QeLsN9AXREcU+luv8fYJvPNZhdY3ruOqEbwQwwFsvIQ==; Received: from [2601:8:b200:551::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WVddf-0001QU-Hg; Thu, 03 Apr 2014 02:08:47 -0700 Message-ID: <533D251E.3030108@dancol.org> Date: Thu, 03 Apr 2014 02:08:46 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> In-Reply-To: <533D13E2.3060300@dancol.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9uXv6wnDlTG3eqqhlP7jLnrjbtj4sgOU2" X-Spam-Score: -0.6 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.6 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9uXv6wnDlTG3eqqhlP7jLnrjbtj4sgOU2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/03/2014 12:55 AM, Daniel Colascione wrote: > On 04/03/2014 12:04 AM, Dmitry Antipov wrote: >> On 04/03/2014 10:59 AM, Dmitry Antipov wrote: >> >>> 3. Run 'emacs -Q', then M-x byte-force-recompile >>> /path/to/trunk/lis/org >> ^^^^^^^ >> Mean /path/to/trunk/lisp/org, i.e. all Org mode. >=20 > Nice work. What gave you the idea of using byte-force-recompile to > repro? I'd tried a few other stress cases myself and couldn't find > anything. Your repro works perfectly. >=20 Found the bug: that symbol's name is in pure storage, so we ignore the value of sym->s.gcmarkbit and assume the symbol is always live: we never put it on the free list, so we never set its function slot to Vdead. Later, during another GC pass, conservative GC scanning happens to find a pointer to the symbol. We begin marking it, descend into the function slot, which is still pointing to the old, dead object value. We try to mark memory being used for some other purpose and enter la-la land= =2E --9uXv6wnDlTG3eqqhlP7jLnrjbtj4sgOU2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTPSUeAAoJEMAaIROpHW7IylsP/1VsEaDeO9mGV+E/nDlbvkgI 3qlanlhkW2ZSWPJOn2f1pcI9LO1Ww80BzwNMW/xJJAN84uIBZLNchonbqXyRGFDY 2EMYn5mhhpGiZzmvv/7dukEku2KoEG/necmlGEfr7L2POcxaQQlNtsCmQrJOAGKn pg+lN5PzdWkiJaPPkgaaDS+kQ2X5hYhkFFS2esXEss+pjDQWV6TZPh/vfYglvTAA n4B6aopzEF9T7estIg7HTFckMcl48ILpJBUpPzeiA8jxCJlmnEGhD4mzhFEOsCBd Z1iDJJeO/rVNXYj+02x3KZYSU/rriz5TmIt1jAyScdGnfgXR3pY3dM+/nuXP9jCJ JHr4C9wEwBQENtLJqBOARg5D1ycbDDzpJZtNBfqlTKEDOMK12oRyCHNUVvRSspaD cC5a2aFS7dza2+Fl+6CK3treZ9rL/BwwrEZbKjA6C/1VBxGuboT7xbHJxEyYaizH dNgJgQX119XeiX9RDLSJ1m2aTV8TD9EfI3WdcaJt8lNsiMeWpLEjM57tQLyV3zg6 7ytRtibR89yCqXHKCNvQSNqWCyc5+4i/57OQk7WW0Vhm00tSWGfZsMW5D38cOAW6 nN3LmK5QDz4qdhAUNDmsNbse/OjQu+H9SjJk7klvIHn2x7jjCfVVXO4BTAIU7ztv o7rpD2zDawggW54Mj3Z9 =9tdn -----END PGP SIGNATURE----- --9uXv6wnDlTG3eqqhlP7jLnrjbtj4sgOU2-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Dmitry Antipov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Apr 2014 14:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Daniel Colascione Cc: 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.13965337937417 (code B ref 17168); Thu, 03 Apr 2014 14:04:02 +0000 Received: (at 17168) by debbugs.gnu.org; 3 Apr 2014 14:03:13 +0000 Received: from localhost ([127.0.0.1]:34524 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WViEa-0001vZ-DI for submit@debbugs.gnu.org; Thu, 03 Apr 2014 10:03:12 -0400 Received: from forward5l.mail.yandex.net ([84.201.143.138]:38164) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WViEW-0001vP-Oc for 17168@debbugs.gnu.org; Thu, 03 Apr 2014 10:03:10 -0400 Received: from smtp2h.mail.yandex.net (smtp2h.mail.yandex.net [84.201.187.145]) by forward5l.mail.yandex.net (Yandex) with ESMTP id 2887EC40DA2; Thu, 3 Apr 2014 18:03:07 +0400 (MSK) Received: from smtp2h.mail.yandex.net (localhost [127.0.0.1]) by smtp2h.mail.yandex.net (Yandex) with ESMTP id 9CF861703F30; Thu, 3 Apr 2014 18:03:06 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp2h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id GLsbWe75YX-36FOdFj2; Thu, 3 Apr 2014 18:03:06 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: de455332-527c-425c-b01a-ea26e86372e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1396533786; bh=bKgN6Q6NksgppAmX76gv5E+L5VBPG7mVT8PgJEA9Zxw=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type; b=JK3x7zeRqWg7oFUl6o+pVIhwlMpctftDo9nu8HLd5XqvdaGntSC/P3RuN+tuoBB1S 2l8udzx/yghm2itrgQa9mxIys0TemaZN18rtn3QQ8LvTNCqMA3YSPpqjpdDkvtsjsd uS2/Qccc80G53Xt1J+rSgaNMRn7gn+0hF8/zaIpw= Authentication-Results: smtp2h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <533D6A19.8050504@yandex.ru> Date: Thu, 03 Apr 2014 18:03:05 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> In-Reply-To: <533D251E.3030108@dancol.org> Content-Type: multipart/mixed; boundary="------------050208090709090606020406" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (/) This is a multi-part message in MIME format. --------------050208090709090606020406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 04/03/2014 01:08 PM, Daniel Colascione wrote: > Found the bug: that symbol's name is in pure storage, so we ignore the > value of sym->s.gcmarkbit and assume the symbol is always live: we > never put it on the free list, so we never set its function slot to > Vdead. Later, during another GC pass, conservative GC scanning happens > to find a pointer to the symbol. We begin marking it, descend into the > function slot, which is still pointing to the old, dead object value. We > try to mark memory being used for some other purpose and enter la-la land. What about this workaround? Until we find a better solution, this should prevent crashes at least. Dmitry --------------050208090709090606020406 Content-Type: text/x-patch; name="bug17168_workaround.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bug17168_workaround.patch" === modified file 'src/alloc.c' --- src/alloc.c 2014-04-03 00:37:51 +0000 +++ src/alloc.c 2014-04-03 13:59:58 +0000 @@ -3382,6 +3382,13 @@ CHECK_STRING (name); + /* If not loadup, avoid symbols with names from pure space. + Current GC has problems treating such a symbols - see + http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17168. */ + if (NILP (Vpurify_flag) && PURE_POINTER_P (XPNTR (name))) + name = make_specified_string (SSDATA (name), SCHARS (name), + SBYTES (name), STRING_MULTIBYTE (name)); + MALLOC_BLOCK_INPUT; if (symbol_free_list) @@ -6174,6 +6181,12 @@ break; CHECK_ALLOCATED_AND_LIVE (live_symbol_p); ptr->gcmarkbit = 1; + /* Attempt to catch bogus objects. In particular, see + http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17168. */ + eassert (SYMBOLP (ptr->function) + || CONSP (ptr->function) + || COMPILEDP (ptr->function) + || SUBRP (ptr->function)); mark_object (ptr->function); mark_object (ptr->plist); switch (ptr->redirect) @@ -6601,6 +6614,12 @@ if (!pure_p) eassert (!STRING_MARKED_P (XSTRING (sym->s.name))); sym->s.gcmarkbit = 0; + /* Attempt to catch bogus objects. In particular, see + http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17168. */ + eassert (SYMBOLP (sym->s.function) + || CONSP (sym->s.function) + || COMPILEDP (sym->s.function) + || SUBRP (sym->s.function)); } } --------------050208090709090606020406-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Apr 2014 15:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Dmitry Antipov Cc: Daniel Colascione , 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139653978417531 (code B ref 17168); Thu, 03 Apr 2014 15:44:02 +0000 Received: (at 17168) by debbugs.gnu.org; 3 Apr 2014 15:43:04 +0000 Received: from localhost ([127.0.0.1]:34620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVjnD-0004Yf-Co for submit@debbugs.gnu.org; Thu, 03 Apr 2014 11:43:04 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:41111) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVjnA-0004YF-Ai for 17168@debbugs.gnu.org; Thu, 03 Apr 2014 11:43:01 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s33FgtWi024636; Thu, 3 Apr 2014 11:42:55 -0400 Received: by pastel.home (Postfix, from userid 20848) id CBE45603AE; Thu, 3 Apr 2014 11:42:54 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> Date: Thu, 03 Apr 2014 11:42:54 -0400 In-Reply-To: <533D6A19.8050504@yandex.ru> (Dmitry Antipov's message of "Thu, 03 Apr 2014 18:03:05 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4901=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4901> : inlines <688> : streams <1151245> : uri <1719212> X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -1.9 (-) > What about this workaround? Until we find a better solution, > this should prevent crashes at least. Let's try to find a better fix instead of another workaround around the existing workaround. So the existing workaround is here: /* Check if the symbol was created during loadup. In such a case it might be pointed to by pure bytecode which we don't trace, so we conservatively assume that it is live. */ bool pure_p = PURE_POINTER_P (XSTRING (sym->s.name)); if (!sym->s.gcmarkbit && !pure_p) { if (sym->s.redirect == SYMBOL_LOCALIZED) xfree (SYMBOL_BLV (&sym->s)); sym->s.next = symbol_free_list; symbol_free_list = &sym->s; #if GC_MARK_STACK symbol_free_list->function = Vdead; #endif ++this_free; } else { ++num_used; if (!pure_p) eassert (!STRING_MARKED_P (XSTRING (sym->s.name))); sym->s.gcmarkbit = 0; } I.e. any symbol with a pure name is assumed to be potentially reachable from some pure objects. But not only this assumption is wrong, but its implementation is wrong as well: we just keep the symbol without making sure we also keep the objects it points to. Furthermore, in theory some pure object may very well point to a symbol whose name was not made pure. Worse, a pure object may point to several other kinds of non-pure objects, so this special treatment we have for symbols should really be applied to other "non-purifyable" objects. How 'bout we change `purecopy' such that before doing /* Not purified, don't hash-cons. */ return obj; it adds the object to a table of "objects pointed from pure space"? This table should probably be a hash-table (for simplicity), and of course we'd only add objects to it when the purecopy call was a recursive call, not for toplevel calls (i.e. calling (purecopy ) should not add to the table since it's not pointed to from a pure object, whereas (purecopy '()) should). Stefan From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Apr 2014 16:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Stefan Monnier , Dmitry Antipov Cc: 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139654364824244 (code B ref 17168); Thu, 03 Apr 2014 16:48:02 +0000 Received: (at 17168) by debbugs.gnu.org; 3 Apr 2014 16:47:28 +0000 Received: from localhost ([127.0.0.1]:34672 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVknX-0006Ix-TZ for submit@debbugs.gnu.org; Thu, 03 Apr 2014 12:47:28 -0400 Received: from dancol.org ([96.126.100.184]:48328) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVknV-0006Il-7N for 17168@debbugs.gnu.org; Thu, 03 Apr 2014 12:47:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=G88bD0nZOa4W+PUXs1MjTuPz6uD8tOHLYuP7que/Zao=; b=OckImxKRkDQlz14F937EMfIJXLvknqT7TWOnX6g1Lj8qG6uhL1E7+kmZJ+ig4THAlJ15UPwjemQA0IjLKgfAtNUrY8LiPc4QyxfzonW+7ohgV7qk0QbRZQONPE2Y8LUYWJF60i1WrY6iGF/eUVYmb9GKigPUoA108uWd3AvMEsCN0NuMWDdENdkf2hTm8CHuhcJCfRbC1tX9V0dsQ9rR/CxrXgZYikSGlVTXNGdW7TuSvbgCLRD8G2eUunnHwKMk69SRgEl9UaDThbEX2X2XuklZ1TFJ7OG3kxZsMOzdzZwZ6w47r+ulJciWBdkTPlBOhxkXXCJRHf7pxnY05Omxpg==; Received: from [2601:8:b200:551::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WVknS-0004VB-Ap; Thu, 03 Apr 2014 09:47:22 -0700 Message-ID: <533D9099.3000104@dancol.org> Date: Thu, 03 Apr 2014 09:47:21 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="j7flI8cFTxbFGrLtkJPOhlIRB8g07gx73" X-Spam-Score: -0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --j7flI8cFTxbFGrLtkJPOhlIRB8g07gx73 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/03/2014 08:42 AM, Stefan Monnier wrote: >> What about this workaround? Until we find a better solution, >> this should prevent crashes at least. What about just eliminating the concept of pure storage? Is it really worth the complexity on modern systems? --j7flI8cFTxbFGrLtkJPOhlIRB8g07gx73 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTPZCZAAoJEMAaIROpHW7IYfQP/jTQjr1N+Q/k0UfoyILMA89O DrPvdq8FRMDb5bTCvjaOtOYW3f9CY4DPa4BVg7ikOUF6MIQEubzdAeu6KMKg3b0V 275PkLyagrzIMyBiCKrM1MMQK+Ps0UnnMavHPKwxcbU7lPsNp4MIF77IayBL+z3Y 8V5DFT8H1C1nVxtOcR38eNlVygPuVPYbK2rf2VXTyxH6m/1zPdRccpwI4pbriK/u Ct9y9hsIi/GoCmeM6Useua5Pk0mjYyxK1EJbyjJfsTgtw9MXBeCNY7DMHt2IbWKP 2+PBqPuA7LyHo+I+R66K/Upl4n7tjNWEj7mywNWoFUtcQwIu8OOFjHWRqobvxSSu Xu3PohZLM5AXF5zHc3JJNw69etRNy04cBY9LVGbQj4NQN1tqvmD2A+Gnd3uDbUHp Z0wn/JGd6dXjjK3TTfI4MtglwBv2Q0OmTcXAizuy960cgFXb9krGVPL+o5WQaKJN WQy/+3YlbpWW55AbnWGBSTkKgGXVJz8iweNAGcMLvBGu2WbPDj4Q9qb5tl3rNq/m 8ZlUCB1ySFR4BTEjUgiwmRtjDcVsY7lpoNo/K8kceY4jcykQZZ29+qHNjBYoAOpk 60Ox9GDR+4Df4qfNkUiA3DUimNMIXgZeDk3rDiFjgp3JCMbB+v6Lq444OLJPkK17 0kJtVQSLxPhFd+xh+xGn =gCFQ -----END PGP SIGNATURE----- --j7flI8cFTxbFGrLtkJPOhlIRB8g07gx73-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Dmitry Antipov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Apr 2014 17:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Daniel Colascione , Stefan Monnier Cc: 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139654737930590 (code B ref 17168); Thu, 03 Apr 2014 17:50:02 +0000 Received: (at 17168) by debbugs.gnu.org; 3 Apr 2014 17:49:39 +0000 Received: from localhost ([127.0.0.1]:34715 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVllj-0007xJ-3z for submit@debbugs.gnu.org; Thu, 03 Apr 2014 13:49:39 -0400 Received: from forward6l.mail.yandex.net ([84.201.143.139]:46367) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVllf-0007x9-Oa for 17168@debbugs.gnu.org; Thu, 03 Apr 2014 13:49:37 -0400 Received: from smtp4h.mail.yandex.net (smtp4h.mail.yandex.net [84.201.186.21]) by forward6l.mail.yandex.net (Yandex) with ESMTP id EC0BB14E0D4F; Thu, 3 Apr 2014 21:49:33 +0400 (MSK) Received: from smtp4h.mail.yandex.net (localhost [127.0.0.1]) by smtp4h.mail.yandex.net (Yandex) with ESMTP id 6762B2C366D; Thu, 3 Apr 2014 21:49:33 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp4h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id VZNkOnsVxM-nWGWG1ls; Thu, 3 Apr 2014 21:49:32 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 529230ac-552f-4619-950e-1a8563ecc2bd DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1396547372; bh=fraxa9T7xBYa7RH2Ah71FZA0SPOzaglJE//cl53NINI=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=VRzl7H4f/LgNHp//7NW9i6ar3+y/ygh+5CEK83qPX1DT2FK62sGzZVNOhO8iaxuhe g/O+yfh5o9X5FlUF1TIkuoiF/qVu+GkSh1RHC/bPdmGFPhNEDj3wnj+UfVYJONCvCz yVQF/WpscBM0mYa+8MGdu2a/bRtqyL+Eryyzw3kY= Authentication-Results: smtp4h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <533D9F2C.7030500@yandex.ru> Date: Thu, 03 Apr 2014 21:49:32 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> In-Reply-To: <533D9099.3000104@dancol.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 04/03/2014 08:47 PM, Daniel Colascione wrote: > What about just eliminating the concept of pure storage? Is it really > worth the complexity on modern systems? Maybe; but now I'm thinking about just releasing pretest free from serious known issues. Dmitry From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Apr 2014 17:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Dmitry Antipov , Stefan Monnier Cc: 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139654752730846 (code B ref 17168); Thu, 03 Apr 2014 17:53:02 +0000 Received: (at 17168) by debbugs.gnu.org; 3 Apr 2014 17:52:07 +0000 Received: from localhost ([127.0.0.1]:34719 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVlo6-00081R-T0 for submit@debbugs.gnu.org; Thu, 03 Apr 2014 13:52:07 -0400 Received: from dancol.org ([96.126.100.184]:48651) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVlo0-00080u-F2 for 17168@debbugs.gnu.org; Thu, 03 Apr 2014 13:52:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=iZ9oGlT1mRdxRhbjW1P9ARiVYbAxh36tzjJgZo39ERg=; b=HIa1Y2mHVS7taXP7PdSa1qi+uIiTbII9LzXIfUoerQzSKb+xA8JIfdiVC++Mn3X4mTYxIILaKyuj+GA3RNs2mySoLg8LZNaKtDJmKRjF0+8XlG7NUPCcg8/Xj1WUBtb/AEY1k2WBDIocI9iWVXp1RB+A8OLruxCWV66H/PFulILNsUVAYWGqy8YvuQItjkfAjrTV5X2DvRX5VASnDRiHT/pS90DI4H727Kytgj2tUwTTN+5xVQePA+bMJbO1SEX6ks4KJxwJtsA2Ea2OgUuDQ4B5TnLS9+Epqb7ZoPGZgXiu6onCs6PsO2m+Lbyse72Y49jrqCa0p/IUMzk8F+NOxA==; Received: from [2601:8:b200:551::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WVlnx-0004o3-8F; Thu, 03 Apr 2014 10:51:57 -0700 Message-ID: <533D9FBB.2050803@dancol.org> Date: Thu, 03 Apr 2014 10:51:55 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> In-Reply-To: <533D9F2C.7030500@yandex.ru> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BKStci6dIW3DsuGQG8l3OHANbA9u3lr2k" X-Spam-Score: -0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BKStci6dIW3DsuGQG8l3OHANbA9u3lr2k Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/03/2014 10:49 AM, Dmitry Antipov wrote: > On 04/03/2014 08:47 PM, Daniel Colascione wrote: >=20 >> What about just eliminating the concept of pure storage? Is it really >> worth the complexity on modern systems? >=20 > Maybe; but now I'm thinking about just releasing pretest free from > serious known issues. Sure; I don't think it's too late to take pure storage out of 24.4 though. Pure storage is an optimization. --BKStci6dIW3DsuGQG8l3OHANbA9u3lr2k Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTPZ+7AAoJEMAaIROpHW7IhXEP/R04uZtjcTJ1+QWHa4d4PIrN UoReJXuvG1A2bAjThi6OvyyQ8K+rU9UCecXw5Xfi2hCGk9lxPOZ6t0WnNN4Sxw7c lpoUnU9Mfl5dWivpPG9fPuSWYs4FGuIkqBNg1H2mQ+X6e6L09E329kxk6aVTUT8L zA4VphMGg8i5f4j4oI6KFc8jAwX0opPdP5vRGOmJixKRYdBMfRILj7q1Xr1vqUVV Kyi1falC+xnwuY+ZrF1xDK8DsXfdOhG+Xa8GIQNAT6JmZGhfzmnjkn1hbg9yFVls EOh5hZYsgx6GUvOUbJDq3NXShykAXZt4/oZps0HoISh7FVracNqHiX58lokSfuac /tHMGM50X9cuchmjNVmMvEjfIuprt93QCig4Dl0/a9GotvIqMvBZBPvxBF51jrzH 9mwb8ZWgVp7makyGUtZ6ZrGd0rW6UXstedxNpD/WZTqfF2Qj02ypYESsx1DDrLhf xVWPdS/wEfC2rcQ4MWhajNacv+D6Ysv8hofBVkdtHG0/pPN0STgXq4Tu954ER9sb o5Kkcuy8+Tuj58KioGnwQ6QJENHG8OPK2g7ISOke9jjkQhIGDsCp+e+URpljPOwR p+OT/WKDn6KofCssC6fqNlXwHr2UJW1hkd+GXwdXIUuOi4qvO2SUhE/iRtwQap9N OxU6zZolV/QkNGd3Krsg =opHm -----END PGP SIGNATURE----- --BKStci6dIW3DsuGQG8l3OHANbA9u3lr2k-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Apr 2014 19:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Daniel Colascione Cc: Dmitry Antipov , 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.13965529137775 (code B ref 17168); Thu, 03 Apr 2014 19:22:02 +0000 Received: (at 17168) by debbugs.gnu.org; 3 Apr 2014 19:21:53 +0000 Received: from localhost ([127.0.0.1]:34753 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVnCz-00021L-5W for submit@debbugs.gnu.org; Thu, 03 Apr 2014 15:21:53 -0400 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:54458) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVnCw-00021C-Sx for 17168@debbugs.gnu.org; Thu, 03 Apr 2014 15:21:51 -0400 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 1B03184E4B; Thu, 3 Apr 2014 15:21:50 -0400 (EDT) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id CA2721E5B74; Thu, 3 Apr 2014 15:21:25 -0400 (EDT) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id A2FA8B4128; Thu, 3 Apr 2014 15:21:25 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> Date: Thu, 03 Apr 2014 15:21:25 -0400 In-Reply-To: <533D9FBB.2050803@dancol.org> (Daniel Colascione's message of "Thu, 03 Apr 2014 10:51:55 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -2.9 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -2.9 (--) > Sure; I don't think it's too late to take pure storage out of 24.4 It is definitely too late for that. Stefan From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Apr 2014 19:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Stefan Monnier Cc: Dmitry Antipov , 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.13965529527859 (code B ref 17168); Thu, 03 Apr 2014 19:23:02 +0000 Received: (at 17168) by debbugs.gnu.org; 3 Apr 2014 19:22:32 +0000 Received: from localhost ([127.0.0.1]:34757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVnDb-00022g-Pi for submit@debbugs.gnu.org; Thu, 03 Apr 2014 15:22:32 -0400 Received: from dancol.org ([96.126.100.184]:49068) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVnDY-00022X-PP for 17168@debbugs.gnu.org; Thu, 03 Apr 2014 15:22:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=+y0R+bgamW2xKGKT6863dkOvDItHkOFM95MW/bv2P7o=; b=Bn3Zsg2E01zvHSaFXcqcjUJ5aJlKQehKdNH+VdYOgze0jeJiSwaFdpVj+C8mR6ZYnsHnYpYBz8aGUxI90cqDGIbNA/5/MZRtpX0pnZuEFvkgc7W5YvS769X5ecD3UOKTb+UjWSgXA/DO9uV2AqIW8UKc+rMyeSNMef/r1ugEkE+EsY5uvt1GjtAjya83Dgd6GtrO/1GUXNDImAMBvpA/50ghXl+oFnfvOv34BFpI+OAHztFh3GjhG1N+0GMAaK2u5MldxmpGEsM61PTYd82012NksPIGJG9ae71bzlCtODTlS35JzS4y+1DcoEO0LCyYP0eX34l80QQgHC59GxtfJQ==; Received: from [2601:8:b200:551::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WVnDW-0005CI-Ia; Thu, 03 Apr 2014 12:22:26 -0700 Message-ID: <533DB4F0.20706@dancol.org> Date: Thu, 03 Apr 2014 12:22:24 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7fIcOSIj66k9jJPsj328kR8aJAb7np6MG" X-Spam-Score: -0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7fIcOSIj66k9jJPsj328kR8aJAb7np6MG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/03/2014 12:21 PM, Stefan Monnier wrote: >> Sure; I don't think it's too late to take pure storage out of 24.4 >=20 > It is definitely too late for that. Okay. Let's try your proposed solution then. I'll see whether I can code something up today. --7fIcOSIj66k9jJPsj328kR8aJAb7np6MG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTPbTwAAoJEMAaIROpHW7ING8P/jHI/BuguVrpoJfxVppfBu8P t3StHwH/Yic7qadZ2x1/aPMX9LyJ8mP3KzCUPkFKsOYT/qGkAH3PWybM5HCuwdoq p0llEnDu9AYU+tRv+30Ha4qmnFQIbgJoiY8JOIea5vjSML+k0eesKY1bdW9L0+5O aa9fx4FB8kcyVq0QrL4unHv11P45YVXG1sy/NSrbPT91rF5//cClbAlGoJ6TpeMH EAEeW7pFX33SxmUYAhWP/iPN6vzmX+lGvHDJvQS4eV0PnzSr8rPnuhjelFPPxzrK 83JGX0YGstdv66QAZlAwttqXv4af/F2DhcyzS83smSiUwh29DVgRjAGmI2gKmrnC HPrny/lejBWp3kj4aFUkC6jMMC2DO+lObN0lxhyLlS/78KomlyetvnDG11CkdvQt L3qkU30SZbe9MfsWAN3NLsiAuRWTlUpkF5z994t7nhYF1VUUyBD3zSB58uiQXreg Fe0ZXfIxRkq8u5ijY063GW8j4ba7ejPZL/W3be5i98go7iOPOTlVTxzEf0CgPzJm JXkUi81EJBn6+XXg80K+nr0NtdDmmFSvukCSKHUVphxRDtVcAcdP8Rpw80bAIEOS CspPGEvCkK8QDBc4LVwNRT8f9ZB+aYBVIncMUmdqLHBOB4smwPE34t0s28R4LfvG rRyVKdSLezGi+Cp7Juxu =ZVvM -----END PGP SIGNATURE----- --7fIcOSIj66k9jJPsj328kR8aJAb7np6MG-- From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 04 17:37:50 2014 Received: (at control) by debbugs.gnu.org; 4 Apr 2014 21:37:50 +0000 Received: from localhost ([127.0.0.1]:35716 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWBo5-0006AF-8L for submit@debbugs.gnu.org; Fri, 04 Apr 2014 17:37:50 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:50578) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWBo2-0006A6-7J for control@debbugs.gnu.org; Fri, 04 Apr 2014 17:37:47 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1WWBo1-0003yj-VN for control@debbugs.gnu.org; Fri, 04 Apr 2014 17:37:46 -0400 Date: Fri, 04 Apr 2014 17:37:45 -0400 Message-Id: Subject: control message for bug 17184 To: X-Mailer: mail (GNU Mailutils 2.1) From: Glenn Morris X-Spam-Score: -5.6 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -5.6 (-----) forcemerge 17168 17184 From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Apr 2014 22:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Stefan Monnier Cc: Dmitry Antipov , 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.13967374727886 (code B ref 17168); Sat, 05 Apr 2014 22:38:02 +0000 Received: (at 17168) by debbugs.gnu.org; 5 Apr 2014 22:37:52 +0000 Received: from localhost ([127.0.0.1]:37150 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWZDi-000236-8a for submit@debbugs.gnu.org; Sat, 05 Apr 2014 18:37:51 -0400 Received: from dancol.org ([96.126.100.184]:39466) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWZDb-00022r-Pc for 17168@debbugs.gnu.org; Sat, 05 Apr 2014 18:37:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=7RGIiTjW1PqktEmrQV37LClKtxDzyoC6Esxl964zOcE=; b=O2RDB71HkrgTj2zVX06qdx3j28P0MHmcE/K+ATkPrAFo6q/fZcpbzFOORgym1XfX7Rb6SAhmLTt1zDjwkjLOBsz86bPvDDdYsQE5EFAfhk9PRxLhy3wnIA679EXDW5W+vtK3DIIcjlvEQIrTg7dqUf2qAuz9S4ZyjiQ8skbqFVSCJ+tFF5qCdy6b6D07xIFln/xBNQiEYjUIkjO+O+f4H/Y8ZYWA5hP/Ru/FYegW52dvzihB8hqdPgz/t2SwqWnJfsM/Nn8LToPmz9LDvbbLLiUabs9sWZg/m8N5Zm3qO9lO8Nku4JD7041XhssZ3s8tMg3lZqgXpC7e2CrWrnAooQ==; Received: from [2601:8:b200:551::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WWZDX-00013e-CZ; Sat, 05 Apr 2014 15:37:39 -0700 Message-ID: <534085B1.9070307@dancol.org> Date: Sat, 05 Apr 2014 15:37:37 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> In-Reply-To: <533DB4F0.20706@dancol.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="52bOscr0PMTNj4eALxsMbESsfSCn58PSL" X-Spam-Score: -0.6 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.6 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --52bOscr0PMTNj4eALxsMbESsfSCn58PSL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/03/2014 12:22 PM, Daniel Colascione wrote: > On 04/03/2014 12:21 PM, Stefan Monnier wrote: >>> Sure; I don't think it's too late to take pure storage out of 24.4 >> >> It is definitely too late for that. >=20 > Okay. Let's try your proposed solution then. I'll see whether I can cod= e > something up today. The patch came out more complicated than I'd hoped. Basically, we define a new variable Vpure_reachable, accessible only from C. Early in startup, we make it a plain list and cons reachable but non-pure objects from Fpurecopy onto it. Once we have hash tables available, we turn it into a hash table. At the end of loadup, instead of just setting purify-flag to nil, we call a new subr finalize-pure-storage. finalize-pure-storage sets purify-flag to nil by side effect and, as new behavior, makes purify-flag constant so that it can never again become non-nil. Before returning, finalize-pure-storage also turns Vpure_reachable into a vector *in pure storage* of objects we need to keep around. Fgarbage_collect knows how to mark objects in Vpure_reachable and understands that if Vpure_reachable is a vector, its contents should be marked, not the vector itself. This scheme works and passes Dmitry's test, but the resulting Vpure_reachable vector has over 8,000 items. Most of these items are ordinary interned symbols. As an optimization, when we build the final vector form of Fpure_reachable, we see whether each item is a symbol interned in the initial obarray. If it is, then instead of adding it to the vector, we mark the symbol as un-uninternable, and add code to Funintern to look for this new flag. After this optimization, Vpure-reachable only has 251 elements. Please review. =3D=3D=3D modified file 'lisp/loadup.el' --- lisp/loadup.el 2014-02-10 01:34:22 +0000 +++ lisp/loadup.el 2014-04-05 22:24:34 +0000 @@ -56,7 +56,7 @@ t)) (let ((dir (car load-path))) ;; We'll probably overflow the pure space. - (setq purify-flag nil) + (finalize-pure-storage) (setq load-path (list (expand-file-name "." dir) (expand-file-name "emacs-lisp" dir) (expand-file-name "language" dir) @@ -389,12 +389,11 @@ (message "Pure-hashed: %d strings, %d vectors, %d conses, %d bytecodes, %d others" strings vectors conses bytecodes others))) -;; Avoid error if user loads some more libraries now and make sure the -;; hash-consing hash table is GC'd. -(setq purify-flag nil) - -(if (null (garbage-collect)) - (setq pure-space-overflow t)) +;; Runs garbage-collect and sets purify-flag to nil by side effect. +(when (and purify-flag + (progn (finalize-pure-storage) + (not (garbage-collect)))) + (setq pure-space-overflow t)) (if (or (member (nth 3 command-line-args) '("dump" "bootstrap")) (member (nth 4 command-line-args) '("dump" "bootstrap"))) =3D=3D=3D modified file 'src/alloc.c' --- src/alloc.c 2014-04-03 09:50:58 +0000 +++ src/alloc.c 2014-04-05 22:30:18 +0000 @@ -173,6 +173,14 @@ static char *purebeg; static ptrdiff_t pure_size; +/* Data structure holding non-pure objects reachable from objects in + pure storage. Initially a list, since we need this data structure + before we've initialized enough of Emacs to make hash tables. We + transform it into a hash table when hash tables become available. + In `finalize-pure-storage', we turn Vpure_reachable into a vector in + pure storage. */ +static Lisp_Object Vpure_reachable; + /* Number of bytes of pure storage used before pure storage overflowed. If this is non-zero, this implies that an overflow occurred. */ @@ -196,6 +204,8 @@ const char *pending_malloc_warning; +static Lisp_Object purecopy_1 (Lisp_Object obj, bool top_level); + #if 0 /* Normally, pointer sanity only on request... */ #ifdef ENABLE_CHECKING #define SUSPICIOUS_OBJECT_CHECKING 1 @@ -5228,8 +5238,8 @@ Lisp_Object new; struct Lisp_Cons *p =3D pure_alloc (sizeof *p, Lisp_Cons); XSETCONS (new, p); - XSETCAR (new, Fpurecopy (car)); - XSETCDR (new, Fpurecopy (cdr)); + XSETCAR (new, purecopy_1 (car, false)); + XSETCDR (new, purecopy_1 (cdr, false)); return new; } @@ -5261,12 +5271,8 @@ return new; } - -DEFUN ("purecopy", Fpurecopy, Spurecopy, 1, 1, 0, - doc: /* Make a copy of object OBJ in pure storage. -Recursively copies contents of vectors and cons cells. -Does not copy symbols. Copies strings without text properties. */) - (register Lisp_Object obj) +static Lisp_Object +purecopy_1 (Lisp_Object obj, bool top_level) { if (NILP (Vpurify_flag)) return obj; @@ -5300,7 +5306,7 @@ size &=3D PSEUDOVECTOR_SIZE_MASK; vec =3D XVECTOR (make_pure_vector (size)); for (i =3D 0; i < size; i++) - vec->contents[i] =3D Fpurecopy (AREF (obj, i)); + vec->contents[i] =3D purecopy_1 (AREF (obj, i), false); if (COMPILEDP (obj)) { XSETPVECTYPE (vec, PVEC_COMPILED); @@ -5311,9 +5317,20 @@ } else if (MARKERP (obj)) error ("Attempt to copy a marker to pure storage"); - else + else if (top_level) /* Not purified, don't hash-cons. */ return obj; + else if (!INTEGERP (obj) && !EQ (obj, Qt) && !EQ (obj, Qnil)) + { + /* Object is reachable from a pure object, so we need remember + it as a GC root: we don't mark pure objects themselves. */ + if (NILP (Vpure_reachable) || CONSP (Vpure_reachable)) + Vpure_reachable =3D Fcons (obj, Vpure_reachable); + else + Fputhash (obj, Qnil, Vpure_reachable); + + return obj; + } if (HASH_TABLE_P (Vpurify_flag)) /* Hash consing. */ Fputhash (obj, obj, Vpurify_flag); @@ -5322,6 +5339,73 @@ } +DEFUN ("purecopy", Fpurecopy, Spurecopy, 1, 1, 0, + doc: /* Make a copy of object OBJ in pure storage. +Recursively copies contents of vectors and cons cells. +Does not copy symbols. Copies strings without text properties. */) + (register Lisp_Object obj) +{ + return purecopy_1 (obj, true); +} + +DEFUN ("finalize-pure-storage", Ffinalize_pure_storage, + Sfinalize_pure_storage, 0, 0, 0, + doc: /* Finishes building pure storage. +May be called only once, with purify-flag non-nil. */) + (void) +{ + struct Lisp_Hash_Table *h; + ptrdiff_t nr_reachable; + Lisp_Object new_pure_reachable; + Lisp_Object reachable_object; + ptrdiff_t i; + Lisp_Object reachable_objects; + + if (NILP (Vpurify_flag)) + error ("Purification not started"); + + eassert (HASH_TABLE_P (Vpure_reachable)); + h =3D XHASH_TABLE (Vpure_reachable); + + reachable_objects =3D Qnil; + nr_reachable =3D 0; + + for (i =3D 0; i < HASH_TABLE_SIZE (h); ++i) + if (!NILP (HASH_HASH (h, i))) + { + reachable_object =3D HASH_KEY (h, i); + if (SYMBOLP (reachable_object)) + { + if (SYMBOL_INTERNED_IN_INITIAL_OBARRAY_P (reachable_object))= + XSYMBOL (reachable_object)->interned =3D + SYMBOL_INTERNED_IN_INITIAL_OBARRAY_CANNOT_UNINTERN; + + if (XSYMBOL (reachable_object)->interned + =3D=3D SYMBOL_INTERNED_IN_INITIAL_OBARRAY_CANNOT_UNINTER= N) + { + /* No need to remember this object, since it's already + on the main obarray and won't be uninterned. */ + continue; + } + } + + nr_reachable +=3D 1; + reachable_objects =3D Fcons (reachable_object, reachable_objects= ); + } + + new_pure_reachable =3D make_pure_vector (nr_reachable); + for (i =3D 0; CONSP (reachable_objects); ++i) + { + XVECTOR (new_pure_reachable)->contents[i] =3D XCAR (reachable_obje= cts); + reachable_objects =3D XCDR (reachable_objects); + } + + XSYMBOL (intern_c_string ("purify-flag"))->constant =3D 1; + Vpurify_flag =3D Qnil; + Vpure_reachable =3D new_pure_reachable; + return Qnil; +} + =0C /***********************************************************************= Protection from GC @@ -5578,6 +5662,19 @@ for (i =3D 0; i < staticidx; i++) mark_object (*staticvec[i]); + if (VECTORP (Vpure_reachable)) + { + /* Vpure_reachable is a pure-allocated vector of objects + reachable from pure storage. We can't mark it, but we can + mark its contents. */ + struct Lisp_Vector* pv =3D XVECTOR (Vpure_reachable); + eassert (PURE_POINTER_P (pv)); + for (i =3D 0; i < pv->header.size; ++i) + mark_object (pv->contents[i]); + } + else + mark_object (Vpure_reachable); + mark_specpdl (); mark_terminals (); mark_kboards (); @@ -6581,12 +6678,7 @@ for (; sym < end; ++sym) { - /* Check if the symbol was created during loadup. In such a c= ase - it might be pointed to by pure bytecode which we don't trac= e, - so we conservatively assume that it is live. */ - bool pure_p =3D PURE_POINTER_P (XSTRING (sym->s.name)); - - if (!sym->s.gcmarkbit && !pure_p) + if (!sym->s.gcmarkbit) { if (sym->s.redirect =3D=3D SYMBOL_LOCALIZED) xfree (SYMBOL_BLV (&sym->s)); @@ -6600,8 +6692,6 @@ else { ++num_used; - if (!pure_p) - eassert (!STRING_MARKED_P (XSTRING (sym->s.name))); sym->s.gcmarkbit =3D 0; /* Attempt to catch bogus objects. */ eassert (valid_lisp_object_p (sym->s.function) >=3D 1); @@ -6922,6 +7012,9 @@ /* Used to do Vpurify_flag =3D Qt here, but Qt isn't set up yet! */ purebeg =3D PUREBEG; pure_size =3D PURESIZE; +#ifdef ENABLE_CHECKING + Vpure_reachable =3D make_number (-1); +#endif #if GC_MARK_STACK || defined GC_MALLOC_CHECK mem_init (); @@ -6941,6 +7034,39 @@ } void +init_alloc_once_post_obarray (void) +{ + /* This function is called after Qnil and Qt make sense. Qt is + correct even if CANNOT_DUMP. loadup.el will set to nil at end. */ + Vpurify_flag =3D Qt; + Vpure_reachable =3D Qnil; + /* We don't need to staticpro Vpure_reachable as we mark is specially + in Fgarbage_collect. */ +} + +void +init_alloc_once_post_hash_tables (void) +{ + /* This function is called after hash tables become available. Make + Vpure_reachable a hash table for more efficiency. */ + Lisp_Object reachable_list =3D Vpure_reachable; + Lisp_Object new_pure_reachable =3D + make_hash_table (hashtest_eq, + make_number (DEFAULT_HASH_SIZE), + make_float (DEFAULT_REHASH_SIZE), + make_float (DEFAULT_REHASH_THRESHOLD), + Qnil); + + while (CONSP (reachable_list)) + { + Fputhash (XCAR (reachable_list), Qnil, new_pure_reachable); + reachable_list =3D XCDR (reachable_list); + } + + Vpure_reachable =3D new_pure_reachable; +} + +void init_alloc (void) { gcprolist =3D 0; @@ -7068,6 +7194,7 @@ defsubr (&Smake_symbol); defsubr (&Smake_marker); defsubr (&Spurecopy); + defsubr (&Sfinalize_pure_storage); defsubr (&Sgarbage_collect); defsubr (&Smemory_limit); defsubr (&Smemory_use_counts); =3D=3D=3D modified file 'src/emacs.c' --- src/emacs.c 2014-04-03 07:14:02 +0000 +++ src/emacs.c 2014-04-05 20:33:09 +0000 @@ -1171,6 +1171,7 @@ { init_alloc_once (); init_obarray (); + init_alloc_once_post_obarray (); init_eval_once (); init_charset_once (); init_coding_once (); @@ -1198,6 +1199,7 @@ /* Called before syms_of_fileio, because it sets up Qerror_condition. */ syms_of_data (); syms_of_fns (); /* Before syms_of_charset which uses hashtables. */ + init_alloc_once_post_hash_tables (); syms_of_fileio (); /* Before syms_of_coding to initialize Vgc_cons_threshold. */ syms_of_alloc (); @@ -2078,7 +2080,6 @@ You must run Emacs in batch mode in order to dump it. */) (Lisp_Object filename, Lisp_Object symfile) { - Lisp_Object tem; Lisp_Object symbol; ptrdiff_t count =3D SPECPDL_INDEX (); @@ -2090,6 +2091,9 @@ if (!might_dump) error ("Emacs can be dumped only once"); + if (!NILP (Vpurify_flag)) + error ("Purification must have completed before dumping"); + #ifdef GNU_LINUX /* Warn if the gap between BSS end and heap start is larger than this. */ @@ -2127,9 +2131,6 @@ } } - tem =3D Vpurify_flag; - Vpurify_flag =3D Qnil; - #ifdef HAVE_TZSET set_time_zone_rule (dump_tz); #ifndef LOCALTIME_CACHE @@ -2173,8 +2174,6 @@ reset_image_types (); #endif - Vpurify_flag =3D tem; - return unbind_to (count, Qnil); } =3D=3D=3D modified file 'src/fns.c' --- src/fns.c 2014-04-01 20:18:12 +0000 +++ src/fns.c 2014-04-05 21:39:19 +0000 @@ -3483,8 +3483,9 @@ Low-level Functions ***********************************************************************= / -static struct hash_table_test hashtest_eq; -struct hash_table_test hashtest_eql, hashtest_equal; +struct hash_table_test hashtest_eq; +struct hash_table_test hashtest_eql; +struct hash_table_test hashtest_equal; /* Compare KEY1 which has hash code HASH1 and KEY2 with hash code HASH2 in hash table H using `eql'. Value is true if KEY1 and =3D=3D=3D modified file 'src/lisp.h' --- src/lisp.h 2014-04-03 00:18:08 +0000 +++ src/lisp.h 2014-04-05 22:13:57 +0000 @@ -1537,7 +1537,8 @@ { SYMBOL_UNINTERNED =3D 0, SYMBOL_INTERNED =3D 1, - SYMBOL_INTERNED_IN_INITIAL_OBARRAY =3D 2 + SYMBOL_INTERNED_IN_INITIAL_OBARRAY =3D 2, + SYMBOL_INTERNED_IN_INITIAL_OBARRAY_CANNOT_UNINTERN =3D 3 }; enum symbol_redirect @@ -1658,7 +1659,14 @@ INLINE bool SYMBOL_INTERNED_IN_INITIAL_OBARRAY_P (Lisp_Object sym) { - return XSYMBOL (sym)->interned =3D=3D SYMBOL_INTERNED_IN_INITIAL_OBARR= AY; + return XSYMBOL (sym)->interned >=3D SYMBOL_INTERNED_IN_INITIAL_OBARRAY= ; +} + +INLINE bool +SYMBOL_CANNOT_UNINTERN_P (Lisp_Object sym) +{ + return XSYMBOL (sym)->interned =3D=3D + SYMBOL_INTERNED_IN_INITIAL_OBARRAY_CANNOT_UNINTERN; } /* Value is non-zero if symbol is considered a constant, i.e. its @@ -3450,7 +3458,7 @@ ptrdiff_t hash_lookup (struct Lisp_Hash_Table *, Lisp_Object, EMACS_UINT *); ptrdiff_t hash_put (struct Lisp_Hash_Table *, Lisp_Object, Lisp_Object, EMACS_UINT); -extern struct hash_table_test hashtest_eql, hashtest_equal; +extern struct hash_table_test hashtest_eq, hashtest_eql, hashtest_equal;= extern Lisp_Object substring_both (Lisp_Object, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t); @@ -3741,6 +3749,8 @@ extern void free_marker (Lisp_Object); extern void free_cons (struct Lisp_Cons *); extern void init_alloc_once (void); +extern void init_alloc_once_post_obarray (void); +extern void init_alloc_once_post_hash_tables (void); extern void init_alloc (void); extern void syms_of_alloc (void); extern struct buffer * allocate_buffer (void); =3D=3D=3D modified file 'src/lread.c' --- src/lread.c 2014-02-25 22:51:34 +0000 +++ src/lread.c 2014-04-05 22:11:09 +0000 @@ -3895,10 +3895,17 @@ if (SYMBOLP (name) && !EQ (name, tem)) return Qnil; - /* There are plenty of other symbols which will screw up the Emacs - session if we unintern them, as well as even more ways to use - `setq' or `fset' or whatnot to make the Emacs session - unusable. Let's not go down this silly road. --Stef */ + if (XSYMBOL (tem)->interned + =3D=3D SYMBOL_INTERNED_IN_INITIAL_OBARRAY_CANNOT_UNINTERN) + { + /* We can't unintern this symbol because pure storage might + refer to it. If we were to allow uninterning, we'd have to + remember these symbols as GC roots elsewhere, and if the user + later re-interned them, the core functionality would refer to + symbols with a different name. */ + error ("Attempt to unintern symbol in Emacs core"); + } + /* if (EQ (tem, Qnil) || EQ (tem, Qt)) error ("Attempt to unintern t or nil"); */ @@ -4052,9 +4059,6 @@ XSYMBOL (Qnil)->declared_special =3D 1; XSYMBOL (Qt)->constant =3D 1; - /* Qt is correct even if CANNOT_DUMP. loadup.el will set to nil at end. */ - Vpurify_flag =3D Qt; - DEFSYM (Qvariable_documentation, "variable-documentation"); read_buffer =3D xmalloc (size); --52bOscr0PMTNj4eALxsMbESsfSCn58PSL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTQIWxAAoJEMAaIROpHW7IHh4QAMBMuceMwnxer6zZq3oa3KIX Nvke2lZPInqJre8QbG2Pmz4NjGGxazaH00uVR8KMpase3+XiibuF0kuOGTvy/CW8 dKBMxlNLRTEyyzzWpm5PViYBq3VGhMbVhV4oh+dx/29QD+ETEp6UXmt5/HWKUQN6 AhEqMBqnp0N8MD6IHLANS9SImnSKB+87OyhUVvReedauVceFIDFgbpO0E5db4MG2 fGf2Ju1bC+aTzeHOdRh39Z8vfI5pSJ5s3n1OdvpEUtAIMS87yiB3PJJ7xTtSZgXZ +hgX+BdJMGuDF5hHtWOtadi3zSjGJZgq9lTz0el2sCiU1hkiUp13fb8pua7bpLyJ cU2b6hToBPjr6mKYHXaFE6Tcs9kYaA10Lr0EkI9NslT1hjSCesx5BhZ6EzA2+7t6 G9+CTGIss3J8LJJYNe9opLdx1GOg/9CKqkZ3iWJneKohijcSbrzP4QyqaBRgVpbZ a2V4ov7DTN505od7raSpdtyweITjbC1ktaYHzJO5cUzt3RFN6P2pqd7J5RZJEs51 dvQu8dGu/x2BKyY956P85EdNCMdHN3aUx0YgzmzbV5WFHtADZJEhmRXplC5wzTRF o2THSr8cWIy6RiJmOVM3+2POfKfzCg3NnY5a7gONVOayytZbP/y0BNZuSGDw4ttI +lEYj2gLASjI+WyToNzZ =ihNB -----END PGP SIGNATURE----- --52bOscr0PMTNj4eALxsMbESsfSCn58PSL-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Dmitry Antipov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 05:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Daniel Colascione , Stefan Monnier Cc: 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139676074521378 (code B ref 17168); Sun, 06 Apr 2014 05:06:01 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 05:05:45 +0000 Received: from localhost ([127.0.0.1]:37317 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWfH6-0005Yj-Eu for submit@debbugs.gnu.org; Sun, 06 Apr 2014 01:05:44 -0400 Received: from forward2h.mail.yandex.net ([84.201.187.147]:34447) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWfH0-0005YJ-M1 for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 01:05:40 -0400 Received: from smtp1h.mail.yandex.net (smtp1h.mail.yandex.net [84.201.187.144]) by forward2h.mail.yandex.net (Yandex) with ESMTP id DF549700B53; Sun, 6 Apr 2014 09:05:34 +0400 (MSK) Received: from smtp1h.mail.yandex.net (localhost [127.0.0.1]) by smtp1h.mail.yandex.net (Yandex) with ESMTP id 572A21340027; Sun, 6 Apr 2014 09:05:34 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp1h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 8Yyj9RujfV-5Xt4BMuw; Sun, 6 Apr 2014 09:05:33 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 40fcaf30-a177-469d-a86a-5cb9d677b8c5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1396760733; bh=WsmwWAX9oLG33KfCrq4nq4YlHn/RogNPV3n3OaqUCDs=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=b+P92XEVYM26K76WLc/7Gu99ER/897kg8zN7UaQB/Ny4+iCQhm9K4rQ18Mu2CD5+F dnp/q7j6ObhzhDKT2G+R62gJjEJsSj3BnyZ2JXZ6nMJqqihMjnhUEZ0ck1tCrzZHWx 9JgAaDjNNl86hJx2Z2BREeWomqMtspiHODkQU0x0= Authentication-Results: smtp1h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <5340E09D.9020709@yandex.ru> Date: Sun, 06 Apr 2014 09:05:33 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> In-Reply-To: <534085B1.9070307@dancol.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (/) On 04/06/2014 02:37 AM, Daniel Colascione wrote: > The patch came out more complicated than I'd hoped. My first impression is that the patch to remove pure storage at all will have nearly the same size and complexity. I.e. the whole thing becomes grossly overengineered. Dmitry From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 05:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Dmitry Antipov , Stefan Monnier Cc: 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139676108222782 (code B ref 17168); Sun, 06 Apr 2014 05:12:01 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 05:11:22 +0000 Received: from localhost ([127.0.0.1]:37338 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWfMX-0005vM-Le for submit@debbugs.gnu.org; Sun, 06 Apr 2014 01:11:22 -0400 Received: from dancol.org ([96.126.100.184]:41144) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWfMT-0005v3-QL for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 01:11:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=DeULmWnYnSxdLdHUHgBrh7g/MEonih/2t7tFJUf2lhc=; b=grGrWauJCUaIib339Taq7D/ucmy4Pw/b2fJpMJ+id5FUR4mHDEvq+gBj1lfTjV+yIIMRpja277XombMozlFy+EY7JLgqmNk+zlnradqQXLO3iuqZSu685dsv8WWqttAXWp9fp7+K648VqTGGjMzGyyVfEUV8rjAp9CTpEQ8SkkWnfT76dBxoypCfGNyMK6h8ub+xZZIZvNs752UBR1rV6as51SsmOMfIDBgAdsvs+2W2kJUialQZiPjkDXGjoMMWcDYOHhcxVKc46CVXbCapctq37/jtWR6uP8C3ypEWhllMBR0rd+K6aIfUeJxW2SbrNL2SoVyfDTcwck5HOa32lQ==; Received: from [2601:8:b200:551::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WWfMR-0002Xd-E2; Sat, 05 Apr 2014 22:11:15 -0700 Message-ID: <5340E1F1.1050909@dancol.org> Date: Sat, 05 Apr 2014 22:11:13 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <5340E09D.9020709@yandex.ru> In-Reply-To: <5340E09D.9020709@yandex.ru> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="16R0vTCV6amX8414jNi6ggvuaqJcEkcNp" X-Spam-Score: -0.6 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.6 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --16R0vTCV6amX8414jNi6ggvuaqJcEkcNp Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/05/2014 10:05 PM, Dmitry Antipov wrote: > I.e. the whole thing becomes grossly > overengineered. Compared to what? We can't leave the bug in the code. We can't go back to precise GC. The pure symbol-name thing is a hacky workaround, and there may be other bugs lurking. It's either this or removing pure storage, and at least this code is already written and maintains resource consumption at 24.3 levels. --16R0vTCV6amX8414jNi6ggvuaqJcEkcNp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTQOHyAAoJEMAaIROpHW7ITYcP/j/Ej2pkJAeCCtyzb4p15fvR Es181ZAckJWegtqcKRJn6B1/hRaA41Zjg17NyThluIKE2skHysSLdmFcGf/NCIZL vmoifBoq5egk8C4AE3BtChALo5sJ41QERutSShy0t9Az/5iR8sQlDnMk5t0K9w4T q1fUtTPJunQCDYyLOVCpnBmViKFkLa13MNJxQfp3/ZZeixYs1fFg90aVr99dZBI+ POUHs/Yb0PHmVZyqsgCrqccQxXyH5d0WkBxM39PpQZbuVs4qoojQgNsqyc/qZkMj Gk1JL7E8dG5CAOsllKrKCcBEDvoUOMnokLMqJ5ntFuOHgG6EU9fTY8LhW2zPbndo yq4OlDmIaJ1nYhxURxv2AuQ4EFIwrTERPrusC1befgGN6PzOIObZ37r8Oad4Sy12 xdtyrXJv+ZPYD6N4xzOKTghzXhv8VKJciMjBIJz8OpO+CDiVWR4PVkllfs9FJ1vI 3LpT6UgibBZr8+lLMSNN2/Anjq9gsxyGrf5qXOKfzFDHvb/eGCQ4nd/Oegn0hlLj TjH8QY9/G9K6ccqo4JyERThXpD2wmB//kQdAFdyKDd4214tEjd7nXDP61Mfv2Yil h8eu/h786mA2bMmGSwjCox0WHDqjSWCri5b+4A8eYD4XXgGIgv/DQrquMoDoXXwx fK5N+OV7NQCvqO3ulxhj =bIbK -----END PGP SIGNATURE----- --16R0vTCV6amX8414jNi6ggvuaqJcEkcNp-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 12:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Daniel Colascione Cc: Dmitry Antipov , 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139678777116207 (code B ref 17168); Sun, 06 Apr 2014 12:37:01 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 12:36:11 +0000 Received: from localhost ([127.0.0.1]:37489 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWmJ0-0004DK-T3 for submit@debbugs.gnu.org; Sun, 06 Apr 2014 08:36:11 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:49050) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWmIx-0004D8-7f for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 08:36:08 -0400 Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s36Ca2au027984; Sun, 6 Apr 2014 08:36:02 -0400 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 1CB97AE1A3; Sun, 6 Apr 2014 08:36:02 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> Date: Sun, 06 Apr 2014 08:36:02 -0400 In-Reply-To: <534085B1.9070307@dancol.org> (Daniel Colascione's message of "Sat, 05 Apr 2014 15:37:37 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4904=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4904> : inlines <693> : streams <1152961> : uri <1722054> X-Spam-Score: -1.6 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -1.6 (-) > This scheme works and passes Dmitry's test, but the resulting > Vpure_reachable vector has over 8,000 items. Most of these items are > ordinary interned symbols. What objects are there besides symbols in Vpure_reachable? If we can reduce Vpure_reachable to only contain symbols, then we can replace it with a `pinned' bit in the Lisp_Symbol struct and then walk the list of symbols during mark, marking all those symbols with the `pinned' bit. Stefan From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 15:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Stefan Monnier Cc: 17168@debbugs.gnu.org, dancol@dancol.org, dmantipov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.1396796845924 (code B ref 17168); Sun, 06 Apr 2014 15:08:02 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 15:07:25 +0000 Received: from localhost ([127.0.0.1]:38196 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWofN-0000En-4G for submit@debbugs.gnu.org; Sun, 06 Apr 2014 11:07:25 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:45105) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWofJ-0000ET-JI for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 11:07:23 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0N3M00A00777V200@a-mtaout22.012.net.il> for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 18:07:09 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N3M009VR7BXUM90@a-mtaout22.012.net.il>; Sun, 06 Apr 2014 18:07:09 +0300 (IDT) Date: Sun, 06 Apr 2014 18:06:56 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <838uri8pkf.fsf@gnu.org> References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: 1.0 (+) > From: Stefan Monnier > Date: Sun, 06 Apr 2014 08:36:02 -0400 > Cc: Dmitry Antipov , 17168@debbugs.gnu.org > > > This scheme works and passes Dmitry's test, but the resulting > > Vpure_reachable vector has over 8,000 items. Most of these items are > > ordinary interned symbols. > > What objects are there besides symbols in Vpure_reachable? > If we can reduce Vpure_reachable to only contain symbols, then we can > replace it with a `pinned' bit in the Lisp_Symbol struct and then walk > the list of symbols during mark, marking all those symbols with the > `pinned' bit. As an alternative, would it make sense to try to understand why the problems started when they did? IOW, how come we never saw this until now? In http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15583#23, Richard provided the last good revno (113938) and the first bad one (114268); I looked at that range of revisions, and 114156 looks relevant. How about if we revert it and see if the problems go away? From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 15:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Stefan Monnier Cc: Dmitry Antipov , 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.13967992279428 (code B ref 17168); Sun, 06 Apr 2014 15:48:01 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 15:47:07 +0000 Received: from localhost ([127.0.0.1]:38223 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWpHn-0002Rz-1V for submit@debbugs.gnu.org; Sun, 06 Apr 2014 11:47:07 -0400 Received: from dancol.org ([96.126.100.184]:44998) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWpHk-0002Rq-7q for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 11:47:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=VFW+AyH/aL9TiTPcAaVV4RzDUU0BSEpkriayv9E5Cdw=; b=Wph63hKzE1erdeS6VoaCtO6ZQHmcTJV6duTM3siJiw5TBTIv8MD4plqEb7XKCpc2zrp3kTezphEgCuSCrmxAd64KWad/CG5jPs+N3xBIWSHQDrSxXcTYfpqCuPM6Lov9YXaIIPQ269leYXcUlsrSjO/MGurMYYQyJwjKXsd2qMhKUgbUyL7brzx2uW8JzsfG+Rz5OFUdHkOt5dizsuTOT/2CfAxJPRbfLla3dhDKZY7zYrlnsy0T6RkPzLh4Ur1O4Aqh3T3HHk6tFsWkT871NVyOTDAEF9Kc2ad7wKT9JK5Jtx655XV50mcY/cW3ls9i8dWieQZLTTXTVUemU5SyDw==; Received: from [2601:8:b200:551::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WWpHh-0005Iz-Gg; Sun, 06 Apr 2014 08:47:01 -0700 Message-ID: <534176F3.9090205@dancol.org> Date: Sun, 06 Apr 2014 08:46:59 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a4thcDol7nCJnAdIAxwGofuAhaQXcDHrR" X-Spam-Score: -0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.3 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --a4thcDol7nCJnAdIAxwGofuAhaQXcDHrR Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/06/2014 05:36 AM, Stefan Monnier wrote: >> This scheme works and passes Dmitry's test, but the resulting >> Vpure_reachable vector has over 8,000 items. Most of these items are >> ordinary interned symbols. >=20 > What objects are there besides symbols in Vpure_reachable? Just symbols for me. > If we can reduce Vpure_reachable to only contain symbols, then we can > replace it with a `pinned' bit in the Lisp_Symbol struct and then walk > the list of symbols during mark, marking all those symbols with the > `pinned' bit. The pinned bit approach is exactly what I implemented, except that we walk obarray, like we already do, instead of all symbols. Your approach would require that we check for non-symbols in purecopy and reject them, and it'd have a bigger performance impact, since we'd then need to walk the entire symbol list essentially twice. I'd strongly prefer the fully general approach in my patch. It isn't *that* complicated. --a4thcDol7nCJnAdIAxwGofuAhaQXcDHrR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTQXbzAAoJEMAaIROpHW7IfuAP/25MskUBoyNNJ91h94AmuTYG BbQh2ny+GhYmLJJN0ejQwL09G6qFSyqgFa5bvS+NC0UdHzLsx9Z7jy4B0YSR5KOD iNQqs2NEjKlO2z3nAkcEblvGnKecFLlAAN8UnJbD2iBtzjKImGTt5NgmTzKdHLi1 21eWtH+hisEnA9Gb9V64l4zXTplfqvIyRi3d8mRNR/t5wmvOoXqD566PNIJ58GTH ospd6fVl1pLnm7WAnSR0egNjHARVMkdOOnKF7Odkr0SdIQ32W6k+0CuAc8eNM1ap jwOJ7sZU5g9zFM3Sb7YGv7v6Gj5dAEDks/YZHjTGWlynJ9MA2EdlXWFV9z7Sb5CG T4Ni1YfD0SdrlsiOE0lr5GTgn7IlINP25x1YDV76/pR4rrpaIFqYm+0U1kP9leLN 4rqhx1PCyQgVnQn6D2ncoidJ6VmtYj1Bk3ewVptubZlqIzOCYFXXMhqP9SMceiNx Dl76kKCnJcNW5uY1HA9qjsa7NfX9p16hqJUhU54oYm1bnTWVqJwOoqhhiRp5ZlLo LUQF8Ro2VZotfoL+TekDbF+oKec3dWJwtEED+i47bogF7DHRW5bydKlRFIExhW/Z 1SJk+B5Wbe+XLdlUpv67vbUREE63w8SZvpNi8Pkte01UU1tSF6E0LVlMN8jIRBNg nw+riAVu7QgJpFzw27zO =rqC0 -----END PGP SIGNATURE----- --a4thcDol7nCJnAdIAxwGofuAhaQXcDHrR-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 16:00:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Eli Zaretskii , Stefan Monnier Cc: dmantipov@yandex.ru, 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139680000110735 (code B ref 17168); Sun, 06 Apr 2014 16:00:03 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 16:00:01 +0000 Received: from localhost ([127.0.0.1]:38238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWpUG-0002n2-Fb for submit@debbugs.gnu.org; Sun, 06 Apr 2014 12:00:00 -0400 Received: from dancol.org ([96.126.100.184]:45025) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWpUD-0002ms-SP for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 11:59:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=e0Y/iSjJ3VPNLKYfUBIONDWihh/xiL8UKAT1emVkXK4=; b=jgTSIRfGBqyGClNQWVvEpRc8MiRsgdH4D7z1Zs5siO3qStUUl77VQe40Pqx+yh0sFNb3ucypcffBr6PUFHO4FUsofucTOd82xlvWSceL649pkwYU+z8l2Ir4Qw2QuFSttfZCq12PyiEp0tVzilI5kweymD+NuOTwo1fcrji5YZ9Zu5qcaDnyiDH9djda5kAgM09gZEyz+x0P+6R8vVAEODADVJwWPeeH+Hlrx6M56L4NonZhnfOdMixBQT7XaDy7kcKQh5XknrSfsvqpUZjtQREIgD4AxfMEo9+rs0GwjcFf5xa4latqXY5u9yF8W8Tb21FlZYgqJpMz1IrD6HU2/A==; Received: from [2601:8:b200:551::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WWpUC-0005Lb-61; Sun, 06 Apr 2014 08:59:56 -0700 Message-ID: <534179FB.4090301@dancol.org> Date: Sun, 06 Apr 2014 08:59:55 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <838uri8pkf.fsf@gnu.org> In-Reply-To: <838uri8pkf.fsf@gnu.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9aVx5lEsvD49FudTnlEvVH0CcuLaco25J" X-Spam-Score: -0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.3 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9aVx5lEsvD49FudTnlEvVH0CcuLaco25J Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/06/2014 08:06 AM, Eli Zaretskii wrote: >> From: Stefan Monnier >> Date: Sun, 06 Apr 2014 08:36:02 -0400 >> Cc: Dmitry Antipov , 17168@debbugs.gnu.org >> >>> This scheme works and passes Dmitry's test, but the resulting >>> Vpure_reachable vector has over 8,000 items. Most of these items are >>> ordinary interned symbols. >> >> What objects are there besides symbols in Vpure_reachable? >> If we can reduce Vpure_reachable to only contain symbols, then we can >> replace it with a `pinned' bit in the Lisp_Symbol struct and then walk= >> the list of symbols during mark, marking all those symbols with the >> `pinned' bit. >=20 > As an alternative, would it make sense to try to understand why the > problems started when they did? IOW, how come we never saw this until > now? Who knows? The problem arises we happen to form a pointer on the stack to an undead symbol, and *any* code change could be responsible for our doing that more frequently. I don't see you can blame it on 114156. > In http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D15583#23, Richard > provided the last good revno (113938) and the first bad one (114268); > I looked at that range of revisions, and 114156 looks relevant. How > about if we revert it and see if the problems go away? The bug would still be there, and we'd have no way to tell whether your proposed change actually reduced its occurrence to a tolerable level. Why would you want to do that instead of just fixing the bug? --9aVx5lEsvD49FudTnlEvVH0CcuLaco25J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTQXn7AAoJEMAaIROpHW7IY4AP+gLBjmLYLxhaSOlVErEbL1EJ 1Qbsp6UGJ81Nvqd7fWiE5POYRSnw5kB9IBfHted0Qz/kIk5pnwo8VXyJjAZkNz60 tV4jlakyPHV/sobE0ybvwbESFu6A3CSPWIaooBt64ZKt/UMbdfKJJjgwEYBEQU2n 6QxfTQDacXN1VNnK44jSV9p0VL7qQWsdR30g/bQ3G3mnXyc1OfhVIAoGiYlsrLb4 1vcFkbVEsWWzPj4g8xOjZ26V2bCIWpsJshzQiMGhcFXhSmJleT5zqIbPuY4eHx5O j0/ocf2cNcRG72fQQJ8/chWbtntzwhgefxUMiPLV6OcTLk9P57peotQOwvshs4AC jvBSLmRtBj6jX6QXFtPUMp0wvjsIyzRFojyJlPN3/3nZInJqAvbmOvEeHUitPqOs hpKkwUvpjKevJ3txFKswEvowjJnTXDS6Vxh/gf0EEPOtjFyRmTVRg+XfBHaWdnPW va8g3oGH5+3tIR6NO94DJnHQA0ylAXvgbj5ZeSpYhpRuiwNUz2zm7TRHMg4t408J xfn9LN2ZdT5+d5lWXBSn12tBPY1LzNHLQxQjxkisXQFbek3hbWt9jXgDCLM0mYvh Wc+80PM8c3/zW9hJvVIxOm1H3rhMqNc3Y5fGi0o7OdePZGrBzgADjlPkWAuLPTkE V2wBmDvo2PtbflVM+/KM =7o8d -----END PGP SIGNATURE----- --9aVx5lEsvD49FudTnlEvVH0CcuLaco25J-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 16:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Daniel Colascione Cc: dmantipov@yandex.ru, 17168@debbugs.gnu.org, monnier@IRO.UMontreal.CA Reply-To: Eli Zaretskii Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139680117812815 (code B ref 17168); Sun, 06 Apr 2014 16:20:02 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 16:19:38 +0000 Received: from localhost ([127.0.0.1]:38242 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWpnF-0003Kd-Qx for submit@debbugs.gnu.org; Sun, 06 Apr 2014 12:19:38 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:56247) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWpnC-0003KN-L6 for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 12:19:36 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0N3M00H00ALD1500@a-mtaout23.012.net.il> for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 19:19:33 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N3M00G46AOKVQA0@a-mtaout23.012.net.il>; Sun, 06 Apr 2014 19:19:33 +0300 (IDT) Date: Sun, 06 Apr 2014 19:19:20 +0300 From: Eli Zaretskii In-reply-to: <534179FB.4090301@dancol.org> X-012-Sender: halo1@inter.net.il Message-id: <834n268m7r.fsf@gnu.org> References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <838uri8pkf.fsf@gnu.org> <534179FB.4090301@dancol.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: 1.0 (+) > Date: Sun, 06 Apr 2014 08:59:55 -0700 > From: Daniel Colascione > CC: dmantipov@yandex.ru, 17168@debbugs.gnu.org > > > As an alternative, would it make sense to try to understand why the > > problems started when they did? IOW, how come we never saw this until > > now? > > Who knows? The problem arises we happen to form a pointer on the stack > to an undead symbol, and *any* code change could be responsible for our > doing that more frequently. I don't see you can blame it on 114156. Then how do you explain that we never saw such problems, in all the years before? > > In http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15583#23, Richard > > provided the last good revno (113938) and the first bad one (114268); > > I looked at that range of revisions, and 114156 looks relevant. How > > about if we revert it and see if the problems go away? > > The bug would still be there, and we'd have no way to tell whether your > proposed change actually reduced its occurrence to a tolerable level. > Why would you want to do that instead of just fixing the bug? Because it's simpler, and because it just might be that the bug was caused by that other changeset. From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 16:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Eli Zaretskii Cc: dmantipov@yandex.ru, 17168@debbugs.gnu.org, monnier@IRO.UMontreal.CA Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139680144813319 (code B ref 17168); Sun, 06 Apr 2014 16:25:02 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 16:24:08 +0000 Received: from localhost ([127.0.0.1]:38247 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWprb-0003Sk-Ny for submit@debbugs.gnu.org; Sun, 06 Apr 2014 12:24:08 -0400 Received: from dancol.org ([96.126.100.184]:45153) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWprZ-0003Sb-3W for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 12:24:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=4RG9utyAwvT7kHGv1EnpRmFkSoOkKKQCnAMpF29wdYM=; b=mgqiElish1mkvKK2flDdT0Ox1ALo84mWZka0ZL9I06MkoYGFIiIsx8Xg9DeBky03VMXz1aDodb7pYs6LhG9Fxo3FxhhOOlkMWR3YlRZXcVtJvA3d0eBkBIjyi6nzQ6iPsAOUP0niEnDidiqajIPe/V4i3v7SkUCHRiglynP7r7YQTl1bsfK1nUn5PgqCXkjDlCHYkDQy0SPjUUaoM8fEqERA8SxvrmQRH3OBX3yaDJNbWikUUTSto0/8mrbu2IvvgzH6nsY39ifpzqM+dDAWPzh9iRGCeNw/2JoK3MfdrvaUqLpnnEHoMWgR0oLF5mNCsbo01x/wi2Z+S94OY/i5QQ==; Received: from [2601:8:b200:551::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WWprX-0005S2-2X; Sun, 06 Apr 2014 09:24:03 -0700 Message-ID: <53417FA1.1060100@dancol.org> Date: Sun, 06 Apr 2014 09:24:01 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <838uri8pkf.fsf@gnu.org> <534179FB.4090301@dancol.org> <834n268m7r.fsf@gnu.org> In-Reply-To: <834n268m7r.fsf@gnu.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="v6MHKWUoQhtLclr7A7Gfsf4phfaP0EdnG" X-Spam-Score: -0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.3 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --v6MHKWUoQhtLclr7A7Gfsf4phfaP0EdnG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/06/2014 09:19 AM, Eli Zaretskii wrote: >> Date: Sun, 06 Apr 2014 08:59:55 -0700 >> From: Daniel Colascione >> CC: dmantipov@yandex.ru, 17168@debbugs.gnu.org >> >>> As an alternative, would it make sense to try to understand why the >>> problems started when they did? IOW, how come we never saw this unti= l >>> now? >> >> Who knows? The problem arises we happen to form a pointer on the stack= >> to an undead symbol, and *any* code change could be responsible for ou= r >> doing that more frequently. I don't see you can blame it on 114156. >=20 > Then how do you explain that we never saw such problems, in all the > years before? It's probabilistic. How do you know we didn't? >>> In http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D15583#23, Richard >>> provided the last good revno (113938) and the first bad one (114268);= >>> I looked at that range of revisions, and 114156 looks relevant. How >>> about if we revert it and see if the problems go away? >> >> The bug would still be there, and we'd have no way to tell whether you= r >> proposed change actually reduced its occurrence to a tolerable level. >> Why would you want to do that instead of just fixing the bug? >=20 > Because it's simpler, It's easy to make code that's simple and wrong. > and because it just might be that the bug was > caused by that other changeset. How might that changeset in particular have caused the problem reports? --v6MHKWUoQhtLclr7A7Gfsf4phfaP0EdnG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTQX+hAAoJEMAaIROpHW7ICK4P/0LmgoG7AG/IvtoRFmgQkC1U 7UXTVaCRToUQVwwVZjYSyJuQhkI5SX4VDlf1FWdYsMy18NrE0XYG0oUUDsucI8HR Kon4PNaiwQ7FJHrpjEfqFLL+/R19xi7D35AzsgR22SPmht7nqrqEGrChqXYQeEGo +tfgvnk1QIekMvY3A+sw9wtAvyvpOtIEK+6ZHb48vgRocUcuyCWhZNug4sClRkfS APYaAabriBhYVVSbXfEiIgPCbACgQAYLvhtfnvDPLyRf8VpKncWo0PEzrdIJTL8o uqeM7FNooeK3W/Y8+6ZXr5mtbZjUn/2fpV/+eWpdaPCdQF/98JBNTdmSDVB+R9L6 LSwZHzEYHjnpMO7vMipnNgifTtLUZ+o66FpDWlhS+HukTLc3M4oxp8Cua4Rfm4jH pfzu/fwLiIahA8OKvJHDN2870N0Om5F3TjxlUr9uIaxgVmRYV72yo94+dCGRJaqs R16iJNXR9cFTFVs/mR+u38YVxipwKcIXRksachdxbO6KpNsuFBIcpzMFUd5cchSo Oy06XDFECQNVbwy/YKm2BpHfK015pL7VtO7SPU4B135QusLUEhjftQ3VzwK18Vyt 1G5f1G+aPB2G72RgR2HUUbEkO5gdR2fVnF10s/OYu0BDqYIsYh3uOkl0fyWKHxP1 BnajGORSSYFzjgiNd0kt =u3H+ -----END PGP SIGNATURE----- --v6MHKWUoQhtLclr7A7Gfsf4phfaP0EdnG-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 16:30:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Daniel Colascione Cc: dmantipov@yandex.ru, 17168@debbugs.gnu.org, monnier@IRO.UMontreal.CA Reply-To: Eli Zaretskii Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139680179913925 (code B ref 17168); Sun, 06 Apr 2014 16:30:03 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 16:29:59 +0000 Received: from localhost ([127.0.0.1]:38255 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWpxF-0003cV-Ve for submit@debbugs.gnu.org; Sun, 06 Apr 2014 12:29:58 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:47631) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWpxC-0003cK-Ho for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 12:29:55 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0N3M00D00APR9A00@mtaout29.012.net.il> for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 19:32:11 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N3M00DECB9LV020@mtaout29.012.net.il>; Sun, 06 Apr 2014 19:32:10 +0300 (IDT) Date: Sun, 06 Apr 2014 19:29:40 +0300 From: Eli Zaretskii In-reply-to: <53417FA1.1060100@dancol.org> X-012-Sender: halo1@inter.net.il Message-id: <83zjjy7763.fsf@gnu.org> References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <838uri8pkf.fsf@gnu.org> <534179FB.4090301@dancol.org> <834n268m7r.fsf@gnu.org> <53417FA1.1060100@dancol.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: 1.0 (+) > Date: Sun, 06 Apr 2014 09:24:01 -0700 > From: Daniel Colascione > CC: monnier@IRO.UMontreal.CA, dmantipov@yandex.ru, 17168@debbugs.gnu.org > > > Then how do you explain that we never saw such problems, in all the > > years before? > > It's probabilistic. How do you know we didn't? Because Richard has been using that machine for years, and I very much doubt that he changed his usage patterns lately. > >>> In http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15583#23, Richard > >>> provided the last good revno (113938) and the first bad one (114268); > >>> I looked at that range of revisions, and 114156 looks relevant. How > >>> about if we revert it and see if the problems go away? > >> > >> The bug would still be there, and we'd have no way to tell whether your > >> proposed change actually reduced its occurrence to a tolerable level. > >> Why would you want to do that instead of just fixing the bug? > > > > Because it's simpler, > > It's easy to make code that's simple and wrong. I didn't suggest any new code. > > and because it just might be that the bug was > > caused by that other changeset. > > How might that changeset in particular have caused the problem reports? It is related to calling a function, and is in the same function from which all the recent crashes started. From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 16:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Eli Zaretskii Cc: dmantipov@yandex.ru, 17168@debbugs.gnu.org, monnier@IRO.UMontreal.CA Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139680225014859 (code B ref 17168); Sun, 06 Apr 2014 16:38:01 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 16:37:30 +0000 Received: from localhost ([127.0.0.1]:38260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWq4X-0003ra-LH for submit@debbugs.gnu.org; Sun, 06 Apr 2014 12:37:30 -0400 Received: from dancol.org ([96.126.100.184]:45223) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWq4U-0003rP-If for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 12:37:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=DWTJFlPQP9zrHSd4pMHEDq/gLPO8AIOD8UIHLHzKGlg=; b=eqqw+xbIJuVyKVgmUgIgj8DbECBfCn9u2OyjXVuJCyOcgqyeYXaZ3Ohdt72NpJh/3N5Ct8FH2XNGv4ee46aEHPJASw0IWOYed2+ppAfI6bYa/aEc+3bTasulj8IMClkT+dTAVEUtmQAGA5DtzZd2owgUWRn81AT2Igo9uPL8ULM+jpABO3O9/r2sRd2oA5DyLvL1M/aDYyfon/nY0Y08XRFE20z5VRv+0N8017emHmb9H5IH0G9EDLDC/hRONMboj8oB5BOx4TqpqCDUL5kDzkKsaUOCsFROGYOwfAEemewvCEATg1N4CwCY2ka6xZ8IObGZnBno3aOFyHR+Szsx4Q==; Received: from [2601:8:b200:551::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WWq4S-0005VO-Hg; Sun, 06 Apr 2014 09:37:24 -0700 Message-ID: <534182C3.30205@dancol.org> Date: Sun, 06 Apr 2014 09:37:23 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <838uri8pkf.fsf@gnu.org> <534179FB.4090301@dancol.org> <834n268m7r.fsf@gnu.org> <53417FA1.1060100@dancol.org> <83zjjy7763.fsf@gnu.org> In-Reply-To: <83zjjy7763.fsf@gnu.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bqi9xBALaunSpQVH6jrHd7vKDnu9iHgx5" X-Spam-Score: -0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.3 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bqi9xBALaunSpQVH6jrHd7vKDnu9iHgx5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/06/2014 09:29 AM, Eli Zaretskii wrote: >> Date: Sun, 06 Apr 2014 09:24:01 -0700 >> From: Daniel Colascione >> CC: monnier@IRO.UMontreal.CA, dmantipov@yandex.ru, 17168@debbugs.gnu.o= rg >> >>> Then how do you explain that we never saw such problems, in all the >>> years before? >> >> It's probabilistic. How do you know we didn't? >=20 > Because Richard has been using that machine for years, and I very much > doubt that he changed his usage patterns lately. Richard's not the only one who has seen this crash. Drew's also reported GC crashes in odd, and different, places. >>>>> In http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D15583#23, Richard= >>>>> provided the last good revno (113938) and the first bad one (114268= ); >>>>> I looked at that range of revisions, and 114156 looks relevant. Ho= w >>>>> about if we revert it and see if the problems go away? >>>> >>>> The bug would still be there, and we'd have no way to tell whether y= our >>>> proposed change actually reduced its occurrence to a tolerable level= =2E >>>> Why would you want to do that instead of just fixing the bug? >>> >>> Because it's simpler, >> >> It's easy to make code that's simple and wrong. >=20 > I didn't suggest any new code. No: you're just suggesting leaving incorrect code in Emacs. >>> and because it just might be that the bug was >>> caused by that other changeset. >> >> How might that changeset in particular have caused the problem reports= ? >=20 > It is related to calling a function, and is in the same function from > which all the recent crashes started. You haven't identified a causal mechanism. Any recent change could have caused enough of a shift in code generation or stack layout to cause this problem, and because it manifests so seldom, it'd be hard to verify that reverting any particular change "fixed" the problem. Also, eval_sub does *everything*. It's no surprise that we saw the crashes there. That's like saying "all crashes are associated with main, this change affects main, and therefore this change is responsible." --bqi9xBALaunSpQVH6jrHd7vKDnu9iHgx5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTQYLDAAoJEMAaIROpHW7I4p0P+gN8HuQQQ9GnvEGpdOCCYj6p LuQrZ8qa2wz32eEhxDZYFUMLtbMChLdeADkuVA8iKoSYh8bVK+2bwXNXdCK+6mFH +DwzhGeLqWsqb6yvDE9O6+LB4ERm4oI6fLCyxuO6lHR0by/leJ+GtXOhVvoD/fxv Wj8em4vl7SQfRYM7JaSRmgGOJE1i8ot1sS0abZeHFNSNtEi8/M5oFrGl0Zzq/8rq UiRqHzFWJ4pYY2iZHKb+v3ZvaV2TxCNvFCvBcHHImLyAq2R1rxGUbqUgflnFEj4B O4fqEqfGr9581rWHaIwyDCxqe6isjpJ9kIQWJmKYlijFmTMh+lrCrI0hcK7A+soQ HZTi7UDxRfTMWzrOzdZZ/OpK0Ja+ZyxAvu8/Pjx+r4SZN6sw3UBGvVJPERG+z3S3 wsSwEUp9QjR8ogPgCIMXh0gIRzZdkWocxpiQtSR/rOz8R9dPyaorqK3mLNTt57X5 ijVZcaWKhnEukNT9HBs3KQkgloiAd6rSdb25dPi5bieZde36exwvDv1sl8BHGwV0 wlBG1WDGq0u8euU3sW/WV0y28ToWEuaTJhlrCKjDvDPwSuMvN8l36p2+f478MB5u 1jGLbUtgSA+jZ/PDeHMcXIaIUcaTTZPMo33QX9OJO2/PQdfSZ8aAFXPF4OPn8RMR fAGCl9JXjQp7hft7lCTm =qZt/ -----END PGP SIGNATURE----- --bqi9xBALaunSpQVH6jrHd7vKDnu9iHgx5-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 17:00:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Daniel Colascione Cc: dmantipov@yandex.ru, 17168@debbugs.gnu.org, monnier@IRO.UMontreal.CA Reply-To: Eli Zaretskii Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139680358717110 (code B ref 17168); Sun, 06 Apr 2014 17:00:03 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 16:59:47 +0000 Received: from localhost ([127.0.0.1]:38268 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWqQ6-0004Rt-Fi for submit@debbugs.gnu.org; Sun, 06 Apr 2014 12:59:46 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:36909) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWqQ3-0004Ri-SV for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 12:59:45 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0N3M00400CBGQ900@a-mtaout21.012.net.il> for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 19:59:42 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N3M0044LCJHP240@a-mtaout21.012.net.il>; Sun, 06 Apr 2014 19:59:42 +0300 (IDT) Date: Sun, 06 Apr 2014 19:59:29 +0300 From: Eli Zaretskii In-reply-to: <534182C3.30205@dancol.org> X-012-Sender: halo1@inter.net.il Message-id: <83y4zi75se.fsf@gnu.org> References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <838uri8pkf.fsf@gnu.org> <534179FB.4090301@dancol.org> <834n268m7r.fsf@gnu.org> <53417FA1.1060100@dancol.org> <83zjjy7763.fsf@gnu.org> <534182C3.30205@dancol.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: 1.0 (+) > Date: Sun, 06 Apr 2014 09:37:23 -0700 > From: Daniel Colascione > CC: monnier@IRO.UMontreal.CA, dmantipov@yandex.ru, 17168@debbugs.gnu.org > > > Because Richard has been using that machine for years, and I very much > > doubt that he changed his usage patterns lately. > > Richard's not the only one who has seen this crash. Drew's also reported > GC crashes in odd, and different, places. Which seem unrelated, and started much later than Richard reported his. > >>>>> In http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15583#23, Richard > >>>>> provided the last good revno (113938) and the first bad one (114268); > >>>>> I looked at that range of revisions, and 114156 looks relevant. How > >>>>> about if we revert it and see if the problems go away? > >>>> > >>>> The bug would still be there, and we'd have no way to tell whether your > >>>> proposed change actually reduced its occurrence to a tolerable level. > >>>> Why would you want to do that instead of just fixing the bug? > >>> > >>> Because it's simpler, > >> > >> It's easy to make code that's simple and wrong. > > > > I didn't suggest any new code. > > No: you're just suggesting leaving incorrect code in Emacs. It's not incorrect, AFAIU. It might be less optimal. > >>> and because it just might be that the bug was > >>> caused by that other changeset. > >> > >> How might that changeset in particular have caused the problem reports? > > > > It is related to calling a function, and is in the same function from > > which all the recent crashes started. > > You haven't identified a causal mechanism. Any recent change could have > caused enough of a shift in code generation or stack layout to cause > this problem, and because it manifests so seldom, it'd be hard to verify > that reverting any particular change "fixed" the problem. I thought you had a test case. If not, how did you verify that your suggested changes do fix the problem? > Also, eval_sub does *everything*. It's no surprise that we saw the > crashes there. That's like saying "all crashes are associated with main, > this change affects main, and therefore this change is responsible." The change is related to calling a function whose symbol has certain properties. That sounds related to me, not just a random change somewhere in eval_sub. Anyway, it was just an idea which I thought would be easy to try. From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 17:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Eli Zaretskii Cc: dmantipov@yandex.ru, 17168@debbugs.gnu.org, monnier@IRO.UMontreal.CA Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139680430518408 (code B ref 17168); Sun, 06 Apr 2014 17:12:02 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 17:11:45 +0000 Received: from localhost ([127.0.0.1]:38284 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWqbg-0004mn-Dv for submit@debbugs.gnu.org; Sun, 06 Apr 2014 13:11:44 -0400 Received: from dancol.org ([96.126.100.184]:45372) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWqbc-0004mV-Jd for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 13:11:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=5GnfqMt6FvDqp9oRQSljf1Z1IrF3TjSw8uMtfAWAGmY=; b=akhx5N70j2plDC97Rxhjxsps1QSRE7bLy5iktvgTK5m9QKW9KKEnAQrFnDFJo3WgvrPV9CjaGf2vEKByWKOYehpyWdMVRkLKOUGn/pEwp1phcFqGDDM9adcxDgQcn4N1l7Jdtnvm+43Au97PXBof6scz3AIqQyt0/KYir6t74VNpp2bfC+poPFTye6cgDBuPpneNpAuQWe014cYiy2Y9tfPPrLQeOPk1qH9f5m0LHvWoKIYanEv0WZJ+Fj8TbdVZ/ybRy3h8XdbHbnZMOxL4mq1ZraIc0A+yCbp/uU8kDc30A0t6AeiZ826uF9q8iwIJdkyxMXyvfpskJLAh57NqOg==; Received: from [2601:8:b200:551::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WWqbT-0005dx-55; Sun, 06 Apr 2014 10:11:31 -0700 Message-ID: <53418AC0.5010300@dancol.org> Date: Sun, 06 Apr 2014 10:11:28 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <838uri8pkf.fsf@gnu.org> <534179FB.4090301@dancol.org> <834n268m7r.fsf@gnu.org> <53417FA1.1060100@dancol.org> <83zjjy7763.fsf@gnu.org> <534182C3.30205@dancol.org> <83y4zi75se.fsf@gnu.org> In-Reply-To: <83y4zi75se.fsf@gnu.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9K8HMDGO13VVMjXVWVPeGJosrwJWpPW8P" X-Spam-Score: -0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.3 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9K8HMDGO13VVMjXVWVPeGJosrwJWpPW8P Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/06/2014 09:59 AM, Eli Zaretskii wrote: >> Date: Sun, 06 Apr 2014 09:37:23 -0700 >> From: Daniel Colascione >> CC: monnier@IRO.UMontreal.CA, dmantipov@yandex.ru, 17168@debbugs.gnu.o= rg >> >>> Because Richard has been using that machine for years, and I very muc= h >>> doubt that he changed his usage patterns lately. >> >> Richard's not the only one who has seen this crash. Drew's also report= ed >> GC crashes in odd, and different, places. >=20 > Which seem unrelated, and started much later than Richard reported > his. With a bug like this, unpredictable, usage-pattern-dependent behavior is expected. >>>>>>> In http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D15583#23, Richa= rd >>>>>>> provided the last good revno (113938) and the first bad one (1142= 68); >>>>>>> I looked at that range of revisions, and 114156 looks relevant. = How >>>>>>> about if we revert it and see if the problems go away? >>>>>> >>>>>> The bug would still be there, and we'd have no way to tell whether= your >>>>>> proposed change actually reduced its occurrence to a tolerable lev= el. >>>>>> Why would you want to do that instead of just fixing the bug? >>>>> >>>>> Because it's simpler, >>>> >>>> It's easy to make code that's simple and wrong. >>> >>> I didn't suggest any new code. >> >> No: you're just suggesting leaving incorrect code in Emacs. >=20 > It's not incorrect, AFAIU. It might be less optimal. The current code isn't just sub-optimal. It's wrong. If you get unlucky and try to mark a dead symbol, you will crash. >>>>> and because it just might be that the bug was >>>>> caused by that other changeset. >>>> >>>> How might that changeset in particular have caused the problem repor= ts? >>> >>> It is related to calling a function, and is in the same function from= >>> which all the recent crashes started. >> >> You haven't identified a causal mechanism. Any recent change could hav= e >> caused enough of a shift in code generation or stack layout to cause >> this problem, and because it manifests so seldom, it'd be hard to veri= fy >> that reverting any particular change "fixed" the problem. >=20 > I thought you had a test case. If not, how did you verify that your > suggested changes do fix the problem? There is a test. Your proposed change does not cause the test to pass. Even if it did, I would argue against substituting a real fix with your change. >> Also, eval_sub does *everything*. It's no surprise that we saw the >> crashes there. That's like saying "all crashes are associated with mai= n, >> this change affects main, and therefore this change is responsible." >=20 > The change is related to calling a function whose symbol has certain > properties. That sounds related to me, not just a random change > somewhere in eval_sub. It's a dangling pointer. Changing slightly the way we chase that dangling pointer won't change the overall result. --9K8HMDGO13VVMjXVWVPeGJosrwJWpPW8P Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTQYrAAAoJEMAaIROpHW7InBkQAMYFcyYra/ghuMh45szb+2DN SEPKcNWtWAEk+/y6elFP1f5v2WvO97rENe4Xg6WrQeohp2vIgf70sKvTUtMZnYHa QTFDhVF4TjhN7qRdVU6NzwbOpyhZmvsdPv6SOgZ0u1YRbbDKr6xuWRoKzVz1VfiI PSZ0zghomgZ5k0xBt/6CZyuxilAlrlUW1NH1i3sLlMO+KsMomX2PWUdKrggSFFE4 uBfq1HK0g1SIij9IyYZqmVuAfEmM98LDtRbyWFSYR4g+PttV8UQpliRa/AxPsn0n Zd00FTRfFnampOYL6EaXsObS52J71SAZCRZLjrid3cgELJMv4JbX8rXvN4ImEFXc LMEHvy4F7v7KiaXL52gcU0KFSZlEvKOxYV1iuZkWyGPJhEF5yosSpsMQ8RrIF42Y XI7VY/yGW9R0sKtOiJ5rLF18mxKLnpg8VnICV0u6wdPLpjHdHoL90Hwi0KwoIn+6 QEmSOmgIEulskQMe1V7GxYPmcBYJl3d2eP0/KeF+M/aoOmv/BzXquSk43Bet/OPE lFfqe4vAsJIBTd1+6s0ve9q5bEubrQ6ADjrgQYiY8wqLi0MKzbwcBpfxgqDNLy5a XFvRIKLrPU+lZM699gZLcc+WXpJPxdRZ2tQ/oTeRx+mC2qo1gUwTaL5wQMfVlJtd vxGMqhp5VUeN4eplZY1l =zqvE -----END PGP SIGNATURE----- --9K8HMDGO13VVMjXVWVPeGJosrwJWpPW8P-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Richard Stallman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 18:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Daniel Colascione Cc: dmantipov@yandex.ru, 17168@debbugs.gnu.org, monnier@iro.umontreal.ca Reply-To: rms@gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139680720723419 (code B ref 17168); Sun, 06 Apr 2014 18:01:01 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 18:00:07 +0000 Received: from localhost ([127.0.0.1]:38298 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWrMT-00064E-8C for submit@debbugs.gnu.org; Sun, 06 Apr 2014 14:00:06 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:56693) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWrMP-00063B-FK for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 14:00:02 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1WWrMO-0007A6-7y; Sun, 06 Apr 2014 14:00:00 -0400 Date: Sun, 06 Apr 2014 14:00:00 -0400 Message-Id: Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman In-reply-to: <5340E1F1.1050909@dancol.org> (message from Daniel Colascione on Sat, 05 Apr 2014 22:11:13 -0700) References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <5340E09D.9020709@yandex.ru> <5340E1F1.1050909@dancol.org> X-Spam-Score: -5.3 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -5.3 (-----) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] Thanks for writing a fix. I think it can be simpler. You accumulate a list of uninterned symbols whose names are pure. Why make this into a hash table and then a vector? A list should suffice. Or maybe some (or even all) uninterned symbols with pure string names should be freed like all other symbols when not pointed to. That would be even simpler. Is there really a need to avoid collecting some of them? As an optimization, when we build the final vector form of Fpure_reachable, we see whether each item is a symbol interned in the initial obarray. If it is, then instead of adding it to the vector, we mark the symbol as un-uninternable, Or unintern could check whether the name is pure. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call. From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Richard Stallman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 18:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Stefan Monnier Cc: 17168@debbugs.gnu.org, dancol@dancol.org, dmantipov@yandex.ru Reply-To: rms@gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139680727527670 (code B ref 17168); Sun, 06 Apr 2014 18:02:02 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 18:01:15 +0000 Received: from localhost ([127.0.0.1]:38307 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWrNa-0007Bn-E6 for submit@debbugs.gnu.org; Sun, 06 Apr 2014 14:01:14 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:56762) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWrNX-00079l-M5 for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 14:01:12 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1WWrNX-0008N4-5G; Sun, 06 Apr 2014 14:01:11 -0400 Date: Sun, 06 Apr 2014 14:01:11 -0400 Message-Id: Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman In-reply-to: (message from Stefan Monnier on Sun, 06 Apr 2014 08:36:02 -0400) References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> X-Spam-Score: -5.3 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -5.3 (-----) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] If we can reduce Vpure_reachable to only contain symbols, then we can replace it with a `pinned' bit in the Lisp_Symbol struct and then walk the list of symbols during mark, marking all those symbols with the `pinned' bit. It might be faster just to traverse a list of these symbols, since there are not very many uninterned symbols with names that are pure. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call. From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 18:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: rms@gnu.org Cc: dmantipov@yandex.ru, 17168@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139680784628788 (code B ref 17168); Sun, 06 Apr 2014 18:11:02 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 18:10:46 +0000 Received: from localhost ([127.0.0.1]:38319 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWrWn-0007UD-Nv for submit@debbugs.gnu.org; Sun, 06 Apr 2014 14:10:46 -0400 Received: from dancol.org ([96.126.100.184]:45645) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWrWk-0007U1-Qd for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 14:10:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Qk4oq+ClfBuAdla1Lt6tj3Z8YFA4y2momqrM2at8SzE=; b=d88kJiZZzbTmclFPJbRbc5fDZHZ8CZr4jWb2xMOfGwqyJISU/LwndW71YjqHBXz3UKgG5eQhKB/BL9PJU1tiNC0admxh0AbBoEp7CXzUjbR0zZWOR1JZv6vzFKS4uPe84p7f1IZ6SQHa4fqmA8JTfCnKBSuplgZYiFugHFLpEfs+AvHAGkSumuQYZZbq+GhD3E5SIPnOAcsa/jCzXMZIWM9L3OCY6Mvbgj8Dha7tlZeQFSXEedQuuZOOm/wN1E/dA3Z6ij/PEH+f14KZJ7SRQX2E3rLSrte0UUQWbPpXn7UtYO43OVT+kZAJ3tQKQpWud4/krN/svEgoO2Lh4ajtQQ==; Received: from [2601:8:b200:551::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WWrWh-0005sD-MX; Sun, 06 Apr 2014 11:10:39 -0700 Message-ID: <5341989E.7050509@dancol.org> Date: Sun, 06 Apr 2014 11:10:38 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <5340E09D.9020709@yandex.ru> <5340E1F1.1050909@dancol.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BMW5axVSggsSvTHQpMG6d7I7e4vMgsQ5U" X-Spam-Score: -0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.3 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BMW5axVSggsSvTHQpMG6d7I7e4vMgsQ5U Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 04/06/2014 11:00 AM, Richard Stallman wrote: > You accumulate a list of uninterned symbols whose names are pure. Why > make this into a hash table=20 To eliminate duplicates, of which there would otherwise be many. > and then a vector? =20 Because that's the best structure to fit in pure storage: the set of needed symbols never changes, so why *not* turn it into a vector? > A list should suffice. No, it really doesn't. > Or maybe some (or even all) uninterned symbols with pure string names > should be freed like all other symbols when not pointed to.=20 And how do you tell whether they're pointed to without marking the pointing objects? If you try to mark objects in pure storage, you defeat the whole point. This change is *exactly* what you need to decide whether something points to a given symbol. > check whether the name is pure. Absolutely not: that's what got us into this mess in the first place. The purify of a symbol's name should have no bearing on how we treat that symbol. What matters is whether pure storage refers to an object; the some of these objects are symbols with pure names is irrelevant. Please, stop talking about the problem in terms of "symbols whose names are pure". Can everyone please stop bikeshedding this? Please read and review the actual patch instead of suggesting non-solutions. The actual approach is the simplest general approach that will preserve existing performance characteristics. The only viable equally simple approach is simply removing pure storage, and if pure storage works (it amounts to a primitive kind of generational GC), we might as well keep it. --BMW5axVSggsSvTHQpMG6d7I7e4vMgsQ5U Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTQZieAAoJEMAaIROpHW7ISyUP/2x9+PUXcOOkj1sIgFMwJDW+ NLtRaikPVWNJI7Y1+urAZoIf7yd0dHNuUTEMUue29a5myM10H9Ug9Joy6Z9q5gN9 nDrcJ+ueN+0o5IojazZC4QbhI3/ZU8GPqOWAZ534nEb9+WLMaKSwXUYj+v6XO1nB lxtfXNmt3ngn07CkQh7TOqxcxGCRDXEXrilUB0v7E6CNWsWnH9yEhxGExEL54G8o hHplRHc6vpE9pkCDZU7yn/Flk2y8alPboNDgjvBVehopkslz58KcwuQhUP5Loi56 s+vRRPTwfWCroIGlzIJ93ZD4d2EsM2CHJFXvZykkgay/gOUM9+v4+mSPpH7uB4O4 unhnw4kD3AAGJ21bwKgd/iqI/xyn3/4Pu5HuPLRFBI8ZF0rcGwcadklg9SnGG3DY C11aixw0lY8XqicBdxhd+OYwVibGyMvcfDVz1S0i94lj1Wbs9eXe1SlmEGDM4i+T WMje96ihSDOwZ0VRKxxnZac1/oQjoKVnhBZJ7ERELbP2SazrzBGZIZY85oMgg90X pyOhFDMmj56WkKeQ+c/TbdsjRk6mHKMASB2of2bffJFPBb5N1KB8dr5lPI1+i6uV 4nISmbo9ZCFLc2Tbzl0zEdoGzU4rK5wNx4w3zsgQpUZrIOKnAcBGX5RLo8e4RcGw nmnO8ixRQLqz2kPrMlLS =Bjq3 -----END PGP SIGNATURE----- --BMW5axVSggsSvTHQpMG6d7I7e4vMgsQ5U-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 19:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Daniel Colascione Cc: dmantipov@yandex.ru, 17168@debbugs.gnu.org, rms@gnu.org Reply-To: Eli Zaretskii Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139681120510791 (code B ref 17168); Sun, 06 Apr 2014 19:07:02 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 19:06:45 +0000 Received: from localhost ([127.0.0.1]:38357 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWsOz-0002nz-3t for submit@debbugs.gnu.org; Sun, 06 Apr 2014 15:06:45 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:56129) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWsOv-0002nm-Tr for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 15:06:43 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N3M00E00HZ4NZ00@a-mtaout20.012.net.il> for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 22:06:40 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N3M00EL1IF37390@a-mtaout20.012.net.il>; Sun, 06 Apr 2014 22:06:40 +0300 (IDT) Date: Sun, 06 Apr 2014 22:06:28 +0300 From: Eli Zaretskii In-reply-to: <5341989E.7050509@dancol.org> X-012-Sender: halo1@inter.net.il Message-id: <83txa66zwr.fsf@gnu.org> References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <5340E09D.9020709@yandex.ru> <5340E1F1.1050909@dancol.org> <5341989E.7050509@dancol.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: 1.0 (+) > Date: Sun, 06 Apr 2014 11:10:38 -0700 > From: Daniel Colascione > Cc: dmantipov@yandex.ru, 17168@debbugs.gnu.org > > Can everyone please stop bikeshedding this? Please read and review the > actual patch instead of suggesting non-solutions. Why are you being so harsh? We are not the enemy. From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 19:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Eli Zaretskii Cc: 17168@debbugs.gnu.org, dancol@dancol.org, dmantipov@yandex.ru Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139681335214323 (code B ref 17168); Sun, 06 Apr 2014 19:43:02 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 19:42:32 +0000 Received: from localhost ([127.0.0.1]:38376 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWsxb-0003ix-8k for submit@debbugs.gnu.org; Sun, 06 Apr 2014 15:42:31 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:48186) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWsxY-0003il-6L for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 15:42:28 -0400 Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s36JgNnH016866; Sun, 6 Apr 2014 15:42:24 -0400 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 7C9E0AE27C; Sun, 6 Apr 2014 15:42:22 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <838uri8pkf.fsf@gnu.org> Date: Sun, 06 Apr 2014 15:42:22 -0400 In-Reply-To: <838uri8pkf.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 06 Apr 2014 18:06:56 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4904=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4904> : inlines <693> : streams <1153100> : uri <1722280> X-Spam-Score: -1.6 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -1.6 (-) > As an alternative, would it make sense to try to understand why the > problems started when they did? IOW, how come we never saw this > until now? I think it's just luck. I remember we added the current hack when we made dolist use an uninterned symbol, and in that case it also took us a while to bump into the problem and then to track it down. Stefan From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 19:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Eli Zaretskii Cc: 17168@debbugs.gnu.org, Daniel Colascione , dmantipov@yandex.ru Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139681345314506 (code B ref 17168); Sun, 06 Apr 2014 19:45:02 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 19:44:13 +0000 Received: from localhost ([127.0.0.1]:38380 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWszF-0003lt-4E for submit@debbugs.gnu.org; Sun, 06 Apr 2014 15:44:13 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:48298) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWszC-0003lk-Bi for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 15:44:11 -0400 Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s36Ji5p4016966; Sun, 6 Apr 2014 15:44:06 -0400 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id C19F8AE27C; Sun, 6 Apr 2014 15:44:04 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87y4zop44m.fsf@yahoo.fr> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <838uri8pkf.fsf@gnu.org> <534179FB.4090301@dancol.org> <834n268m7r.fsf@gnu.org> <53417FA1.1060100@dancol.org> <83zjjy7763.fsf@gnu.org> <534182C3.30205@dancol.org> <83y4zi75se.fsf@gnu.org> Date: Sun, 06 Apr 2014 15:44:04 -0400 In-Reply-To: <83y4zi75se.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 06 Apr 2014 19:59:29 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 2 Rules triggered GEN_SPAM_FEATRE=0.2, RV4904=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4904> : inlines <693> : streams <1153100> : uri <1722281> X-Spam-Score: -1.6 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -1.6 (-) >> No: you're just suggesting leaving incorrect code in Emacs. > It's not incorrect, AFAIU. It might be less optimal. No, it is incorrect. Stefan From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 19:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Richard Stallman Cc: 17168@debbugs.gnu.org, dancol@dancol.org, dmantipov@yandex.ru Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139681430115871 (code B ref 17168); Sun, 06 Apr 2014 19:59:01 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 19:58:21 +0000 Received: from localhost ([127.0.0.1]:38388 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWtCu-00047v-B8 for submit@debbugs.gnu.org; Sun, 06 Apr 2014 15:58:20 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:39152) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWtCr-00047j-JQ for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 15:58:18 -0400 Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s36JwBX2022016; Sun, 6 Apr 2014 15:58:11 -0400 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id EC3D4AE27C; Sun, 6 Apr 2014 15:58:10 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> Date: Sun, 06 Apr 2014 15:58:10 -0400 In-Reply-To: (Richard Stallman's message of "Sun, 06 Apr 2014 14:01:11 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 2 Rules triggered GEN_SPAM_FEATRE=0.2, RV4904=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4904> : inlines <693> : streams <1153104> : uri <1722285> X-Spam-Score: -1.6 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -1.6 (-) > It might be faster just to traverse a list of these symbols, since > there are not very many uninterned symbols with names that are pure. That will fail (i.e. core-dump) if someone later uninterns one of those symbols pointed to from pure space. Stefan From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 19:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Daniel Colascione Cc: Dmitry Antipov , 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139681431415902 (code B ref 17168); Sun, 06 Apr 2014 19:59:02 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 19:58:34 +0000 Received: from localhost ([127.0.0.1]:38391 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWtD8-00048P-1e for submit@debbugs.gnu.org; Sun, 06 Apr 2014 15:58:34 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:39164) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWtD6-00048H-4F for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 15:58:32 -0400 Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s36JwRU1022027; Sun, 6 Apr 2014 15:58:28 -0400 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id A2DCBAE27C; Sun, 6 Apr 2014 15:58:27 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <534176F3.9090205@dancol.org> Date: Sun, 06 Apr 2014 15:58:27 -0400 In-Reply-To: <534176F3.9090205@dancol.org> (Daniel Colascione's message of "Sun, 06 Apr 2014 08:46:59 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4904=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4904> : inlines <693> : streams <1153104> : uri <1722285> X-Spam-Score: -1.6 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -1.6 (-) > The pinned bit approach is exactly what I implemented, except that we > walk obarray, like we already do, instead of all symbols. We already walk obarray during the mark phase, so I don't understand what you mean here. > Your approach would require that we check for non-symbols in purecopy > and reject them, Yes. > and it'd have a bigger performance impact, since we'd > then need to walk the entire symbol list essentially twice. Indeed. I don't expect it to be significant, tho. As you point out we already walk that list once during gc_sweep, so doing it one more time should be very quick. Also, I'd expect that a significant proportion of all symbols would be marked with that bit, so scanning all symbols won't take that much longer than the alternative of only scanning a vector of pinned symbols. Also scanning all symbols like gc_sweep means that the scan is nicely sequential in memory. > I'd strongly prefer the fully general approach in my patch. It isn't > *that* complicated. But it requires more memory, whereas we already have space for an extra bit in the Lisp_Symbol struct. I guess the main difference resides in whether we want to allow uninterning pinned symbols. If we do as you suggest and disallow it, then indeed, I expect there to be rather few uninterned pinned symbols so using a small auxiliary array makes sense. But I'd rather we don't pay attention to a symbol's interned status, so we can later unintern them. Stefan From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 20:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Stefan Monnier Cc: Dmitry Antipov , 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139681522617479 (code B ref 17168); Sun, 06 Apr 2014 20:14:02 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 20:13:46 +0000 Received: from localhost ([127.0.0.1]:38401 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWtRp-0004Xr-Ne for submit@debbugs.gnu.org; Sun, 06 Apr 2014 16:13:46 -0400 Received: from dancol.org ([96.126.100.184]:46195) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWtRn-0004Xh-19 for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 16:13:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=uFdGg0yHI2dp7LNaP5uTfdYjSYjVi1+/GtCqXs5f2AU=; b=XgiTG3B9Rvxb2+XfsQjIs6dGmbf3jmt2YlqblE4f+BYZoiDef7jCY1/21qwdrOzLMae93o2NxdITAAnUn9WeHNsSreQCNLRQqUTyVGdKRXuc56/eGbgDaw/jZ/PaxnvLlZ/wpg4uZLFeN1EbtiyV5LaRvUs3BDcfTeeOXl89vKxLob6octKOhizMvjL7JlOIydo2mlGvC6iNntPBX2w0zKaN1OURsGhU5WX8JstIBA45h1s8NS0M3oU6wojoaUOK2GCHkL2mdOhlqKx324RD338zOfGWFZ18Bu1mvr+JLK4IDppU3pXu783vMw0sgiQNO0vnZ4daSFgC+OLOajAhJA==; Received: from [2601:8:b200:551::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WWtRk-0006NS-Gu; Sun, 06 Apr 2014 13:13:40 -0700 Message-ID: <5341B573.1010605@dancol.org> Date: Sun, 06 Apr 2014 13:13:39 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <534176F3.9090205@dancol.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mcgNLrsOLpMiVR2Sm3LTI8BCp5gdmCGbB" X-Spam-Score: -0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.3 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mcgNLrsOLpMiVR2Sm3LTI8BCp5gdmCGbB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/06/2014 12:58 PM, Stefan Monnier wrote: >> The pinned bit approach is exactly what I implemented, except that we >> walk obarray, like we already do, instead of all symbols. >=20 > We already walk obarray during the mark phase, so I don't understand > what you mean here. I meant that, IIUC, you mean to "pin" symbols by adding a pinned bit to Lisp_Symbol, then at sweep time, enumerating all symbols in all symbol blocks and marking those with this bit set. My approach is similar, except that instead of an explicit mark pass over the symbols, my patch just relies on obarray to keep these symbols alive, then forbids removing these symbols from obarray. This way, the existing walk over obarray does the job of the all-symbols walk we'd need otherwise. >> Your approach would require that we check for non-symbols in purecopy >> and reject them, >=20 > Yes. Well, we already do that for markers. Still, I don't like making general mechanisms less general. >> and it'd have a bigger performance impact, since we'd >> then need to walk the entire symbol list essentially twice. >=20 > Indeed. I don't expect it to be significant, tho. As you point out we= > already walk that list once during gc_sweep, so doing it one more time > should be very quick. =20 Maybe. We might have tens of thousands of symbols. We don't GC that often, sure, but the overhead isn't nothing. On the other hand, if we're walking all symbols during marking, we can avoid walking the initial obarray, since we already know which symbols are interned there from the Lisp_Symbol interned field. (We can't use the same approach for other obarrays because we want them to eventually get GCed even if they have interned symbols.) This approach still gives up generality and doesn't do much about the complexity, but it does save us 350 words of pure storage. > Also, I'd expect that a significant proportion of > all symbols would be marked with that bit, so scanning all symbols won'= t > take that much longer than the alternative of only scanning a vector of= > pinned symbols. Also scanning all symbols like gc_sweep means that the= > scan is nicely sequential in memory. >=20 >> I'd strongly prefer the fully general approach in my patch. It isn't >> *that* complicated. >=20 > But it requires more memory, ~350 machine words, all in pure storage. > whereas we already have space for an extra > bit in the Lisp_Symbol struct. I guess the main difference resides in > whether we want to allow uninterning pinned symbols. If we do as you > suggest and disallow it, then indeed, I expect there to be rather few > uninterned pinned symbols so using a small auxiliary array makes sense.= > But I'd rather we don't pay attention to a symbol's interned status, so= > we can later unintern them. Sure. But why would you ever want to unintern a symbol that pure storage references? --mcgNLrsOLpMiVR2Sm3LTI8BCp5gdmCGbB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTQbVzAAoJEMAaIROpHW7IvWEP/0Xc2efhDMmC6BnJ+7OalQg4 9Q/xVYUdVS6SG4rLWmJW1n3C9z+4+by1CB3lNtv4h/MisD89s8VZGl2qG+GrHTWO 2dy1PitjKj8DWuyLcOjYsBbkk5mBytmrPlooFQLW6pwjBLwh9IivNpIB7ge6Cmwd Dio7UST7UX+6LIZ1RY1wxxQPVjM6SrJaLF4+DCvuMZOyo/vdRcfaDKIkiQCtJ9yx El9TrIZBMHtZJaidShd0C+Fz2EeNJW3PQsqN3ThRapagwWPqYfyL2lisEHE+M/Jr 7EUvBBgBd0j081FTPjIxpM+3MltvMgTguIrauTR31wGooy0OXAvXzVijcjYWVSg2 g7/y/p05bNyInjb6X4XVPFCFT2HN27Y5W/UxFAobE2NGYWBzbaePtG4sHMkcQ7a5 F3diPQIazYxW2Apf13g2OvddUXr5uMxa4YwUgJ4Pzps2e11OiPxon1UQMe6pCQ6A Uxwc4QB9aGAlHW6QEnhm7jm61tShQPiWnowQq9LzuYapWwxv6A7o0cFop9fgKiU1 aZ4DsVJ09i/MPhiRXGkhrK0KyEGA/+B9wo1oYGw3ge2IJRujHKrcTdKt7S7CXiA5 CdWQIgG5HRqAWcCSDiMZz+qJGPmHQDkwqh0W96zSalYozoya4II9vALVHcYeBnqg SZJbX7Kf+BHhVNGt7j+I =iBVb -----END PGP SIGNATURE----- --mcgNLrsOLpMiVR2Sm3LTI8BCp5gdmCGbB-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 20:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Stefan Monnier Cc: Dmitry Antipov , 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139681762621538 (code B ref 17168); Sun, 06 Apr 2014 20:54:01 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 20:53:46 +0000 Received: from localhost ([127.0.0.1]:38411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWu4W-0005bJ-VM for submit@debbugs.gnu.org; Sun, 06 Apr 2014 16:53:45 -0400 Received: from dancol.org ([96.126.100.184]:46391) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWu4R-0005b7-QA for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 16:53:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=zgg6Z8VuJw4gtzDCz5XxtESKMfZWkN6/8QL3qSh9pVw=; b=fek9kCE5AoRcyvS3XY5af+zlW3YxdrbE9qMsEcvWKvTGf2AS5gJ4bP5StCdWABE98V5KgVUvh4FrVK4936AzrBnbIQc97GJv/eAodRNGh3K56Oi1r9MqGvX74/EzQWb/2AKZ62wIJ1jDcj+UME/4u41Q/AoIZtd8ceSRoShecwCWvH/1MxqzQoJOrYUCc3Y38RSe++XbeC2mHQAX1ffhpq/LIDTMw+P3ao9c7GBHXtbtIxjNX926nWmQH/6zU6E2dwengtiT1x0kMdE5s1W7zTfxAWyZNq8H2Uvgf1F4MiLkiX+Pg4hlWvuMHXsFTylyQu5rxO4mNkvu+WLciCBKfQ==; Received: from [2601:8:b200:551::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WWu4P-0006XP-MG; Sun, 06 Apr 2014 13:53:37 -0700 Message-ID: <5341BED0.4050705@dancol.org> Date: Sun, 06 Apr 2014 13:53:36 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <534176F3.9090205@dancol.org> <5341B573.1010605@dancol.org> In-Reply-To: <5341B573.1010605@dancol.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UVn9nsPV2Bqd1sj6Lt3RxHjI2cPcTwtH3" X-Spam-Score: -0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.3 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UVn9nsPV2Bqd1sj6Lt3RxHjI2cPcTwtH3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/06/2014 01:13 PM, Daniel Colascione wrote: > On 04/06/2014 12:58 PM, Stefan Monnier wrote: >>> The pinned bit approach is exactly what I implemented, except that we= >>> walk obarray, like we already do, instead of all symbols. >> >> We already walk obarray during the mark phase, so I don't understand >> what you mean here. >=20 > I meant that, IIUC, you mean to "pin" symbols by adding a pinned bit to= > Lisp_Symbol, then at sweep time, enumerating all symbols in all symbol Err, at mark time, of course. --UVn9nsPV2Bqd1sj6Lt3RxHjI2cPcTwtH3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTQb7QAAoJEMAaIROpHW7I2RwQAMAb/7Lrethabx9y+bXhswZJ TYCMVIjUyyqRu2kWO1CbSr1afxojHJE2MVZyeMqzCHzY1rkrNWlD1GdCh/zueLCR lIhCubDvwJ9Mdmc6m+syIBdSRAClJhX/qaWuPh6EzSFENAVUsJ1Bhkvgzcz4kJui Ab3VOZoSAzy4MGBOfEYMvlZmFOKv9I6DmeowcJ3A5ccOwHFcs+0YoFp3pzmdyOmr 4wiGtX5PW+45mlw9yJ3V+GIYaM5LmPMwuJph2EwPXv5Lt5qv4PcTSZ7dvqag47Pd MLMxkwyO8v8Ihwf/OI2mx9prx24tDcu3B52zOu/LW5A9yiGGmuIqPj2hm0d7IBjw 2LZ74wt89AqgWxGvcgqFpxfl/lgQgdffZI+fYllSaq/KxY9yBEev9FjzoYKxEc5C KECw15V2IIjTvygeG9GkrLfKtFnKe9nd3JPAhzQqYQaOND9s01ZF/4sF5xNiLVh7 ZlGI6ljQ+05sHGmDmDibDU/R42yhWK6O/o3PnPylaeNOF1uWpJF2bZ4KyuzrrIRe VKdjOmVt1x44DlSI2/XhDXZJzGDKFa6cEOaCU0IvFEh3ilarR3BA6LlQ1v17eqOI xxuppgIiSFQNEZ5GDMvIB/5sAECcphTHpbWZtCtqNGXHXaz+p9UtNzf8dnspvKlG O0ZP1J4pSZJ4/ZA+zPDs =CO9V -----END PGP SIGNATURE----- --UVn9nsPV2Bqd1sj6Lt3RxHjI2cPcTwtH3-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 21:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Daniel Colascione Cc: Dmitry Antipov , 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139681853823063 (code B ref 17168); Sun, 06 Apr 2014 21:09:02 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 21:08:58 +0000 Received: from localhost ([127.0.0.1]:38415 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWuJF-0005zu-7q for submit@debbugs.gnu.org; Sun, 06 Apr 2014 17:08:57 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:35063) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWuJC-0005zl-IJ for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 17:08:55 -0400 Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s36L8mAo022304; Sun, 6 Apr 2014 17:08:49 -0400 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id A020FAE27C; Sun, 6 Apr 2014 17:08:47 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <534176F3.9090205@dancol.org> <5341B573.1010605@dancol.org> Date: Sun, 06 Apr 2014 17:08:47 -0400 In-Reply-To: <5341B573.1010605@dancol.org> (Daniel Colascione's message of "Sun, 06 Apr 2014 13:13:39 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4904=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4904> : inlines <693> : streams <1153122> : uri <1722342> X-Spam-Score: -1.6 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -1.6 (-) > Sure. But why would you ever want to unintern a symbol that pure storage > references? That's a good question. But it cuts both ways: if we don't know why it's done, it's hard to judge if it can be disallowed. I must say I don't very much like this idea of special-casing the obarray and the symbols interned therein. Stefan From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 21:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Stefan Monnier Cc: Dmitry Antipov , 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139682027426021 (code B ref 17168); Sun, 06 Apr 2014 21:38:02 +0000 Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 21:37:54 +0000 Received: from localhost ([127.0.0.1]:38454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWulG-0006lc-0s for submit@debbugs.gnu.org; Sun, 06 Apr 2014 17:37:54 -0400 Received: from dancol.org ([96.126.100.184]:46587) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWulC-0006lS-BQ for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 17:37:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=S1d3LPewh+8FcGZE0/lG0hJO6UTXdxyzyU0Lt+6fIxs=; b=IC+WzvnAJlX+tjrSWMWAzApaOziqxBobBbDnyx3CXyj/re6ggVzPh94N3bohLvNAJyR727+M0/tvVsNSvaByv5LRAXkyz/q5mznGfcuSqOt045NLRFOyibOX8j2LjhiYWEbw6AL+rXDZ9CjTSlVrEGGtOEEpFR3QpD1T/jIn2YAW5pfZDN3VrSQipim/dQ6ReeEsSp21SNEU9QFgA5KF1YLnwoRS0pQ+IIX/8nV7vHk0z7sgSuqf+95QntJFak6+UfmgM5y0l/myrFbEbkWczctVqqkTIZxVAUxSfArcuAGeVrWQPiY69oytv0yLbglzSRm7ZPrI5mbiTnQS9Nh+Vg==; Received: from [2601:8:b200:551::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WWul9-0006hY-1C; Sun, 06 Apr 2014 14:37:47 -0700 Message-ID: <5341C928.6040308@dancol.org> Date: Sun, 06 Apr 2014 14:37:44 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <534176F3.9090205@dancol.org> <5341B573.1010605@dancol.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HISDWBu1CwJFPPogbjUxsk3lJVwSmJJKL" X-Spam-Score: -0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.3 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HISDWBu1CwJFPPogbjUxsk3lJVwSmJJKL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/06/2014 02:08 PM, Stefan Monnier wrote: >> Sure. But why would you ever want to unintern a symbol that pure stor= age >> references? >=20 > That's a good question. But it cuts both ways: if we don't know why > it's done, it's hard to judge if it can be disallowed. > I must say I don't very much like this idea of special-casing the > obarray and the symbols interned therein. I really can't think of any good reason why anyone would unintern a core symbol --- all the uses I can think of would be better served by either using advice or let-binding `obarray'. I sometimes use mass-uninterning to get rid of stale function names when I'm developing an elisp package, but this technique isn't useful for symbols referenced from pure storage, and a good alternative is just resetting value and symbol slots. (In fact, I shouldn't use unintern at all for this hack.) Since it's neither safe nor useful to unintern core symbols, I don't think it's worry about whether it's okay to forbid it. Besides: we already special-case the initial obarray for keywordp. Anyway, I'd like to get a fix into emacs-24 soon so we can make sure we've fixed the GC bug. Are you vetoing the general approach used in this patch? If so, I can look at alternatives. --HISDWBu1CwJFPPogbjUxsk3lJVwSmJJKL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTQckoAAoJEMAaIROpHW7IyjAP/A2mfW14WJO07omNRMGSkN6+ wJ/ovm2INGD8MA2KHW8dgKuWofYjUWq0UHwU0KlhcqVW3ThsvE/R4odwqB0eQ1MX rHZL7HsCEpkbqQsjKNhLg/k0hTEXh9mMsJfVWLJoICnGpoaU0k9aer40goPWlMFn VblCFy6Mta8kLLGjnItw5xHRSyGQddN21BFGi68lpWbmCttWCLdgjGcyPx9qKK8L hcuL2xZ1b/BzGr6yN72PCEXRAyieNwI9iCGej5GeP8NsYQ3i57epMQIW+B4Iu/Nh bXJa1mEl9LJz251eMC1vQfCrk7qejIa99uurLMsm9cEFdO3Ki7TZisht0sCpcX0M ifPXjx4Y8aZkOoy676tXN0SeATpbEuIJSlAyqgD5mJDhFM+RLfn+zcpwbXKQMlGL vVwaK9hlxabJA8SH/WujDX8e+OlW4HGkbBtY2J1kHfIj6tfQpMoCBS2eebe3sLtv yssF5uuIslgoEE4JkKxmemx9XSKZbjZaBisJzqgSipUb2RsdsU/Dqpzub5Wdbm/g EquEJ/xrBlX6oEOiSZ9b1ldNHwS14/PEfCOyKHyr3afpIXUbVgaSz83ZDA5YqENG ajWKRbUPG+dgST9wLZAq2eHI23a+Emmc4hvy/H68JTMm4M1eT9NmhVnxCj/3Qj3L GNC1BnJR3eiobRQ8NXga =eqxv -----END PGP SIGNATURE----- --HISDWBu1CwJFPPogbjUxsk3lJVwSmJJKL-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Apr 2014 07:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Daniel Colascione Cc: 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139685699122158 (code B ref 17168); Mon, 07 Apr 2014 07:50:02 +0000 Received: (at 17168) by debbugs.gnu.org; 7 Apr 2014 07:49:51 +0000 Received: from localhost ([127.0.0.1]:38731 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WX4JS-0005lK-FV for submit@debbugs.gnu.org; Mon, 07 Apr 2014 03:49:50 -0400 Received: from mout.gmx.net ([212.227.17.22]:50144) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WX4JP-0005l9-H0 for 17168@debbugs.gnu.org; Mon, 07 Apr 2014 03:49:48 -0400 Received: from [188.22.46.29] ([188.22.46.29]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lmvlg-1XE55y0Xs4-00h4lX; Mon, 07 Apr 2014 09:49:46 +0200 Message-ID: <53425895.1090802@gmx.at> Date: Mon, 07 Apr 2014 09:49:41 +0200 From: martin rudalics MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <5340E09D.9020709@yandex.ru> <5340E1F1.1050909@dancol.org> <5341989E.7050509@dancol.org> In-Reply-To: <5341989E.7050509@dancol.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:GYk8UMUfXs4Xv7POiRRzJIKUa9JXyqDOtFLMFIe5VxLthTl5pMY 4Jsx2EakbYLdV4c2hHyA5DCsD9TSxhgvJBnU3Qlg0uS/olXy6s7EMdoBhbGzrd2zomT8RNb gaGpTKVw9TPoqCLjPvfyLLJOx4uokzMUW6Kbk8XNhJVXZUTdzVZ3KU7FwnhVLBuiLbtndgJ eIxp8mxHrbAyht5yva7Xw== X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (/) > The only viable equally simple approach is simply > removing pure storage, and if pure storage works (it amounts to a > primitive kind of generational GC), we might as well keep it. I did not look into the order GC scans its roots so maybe this is a silly request and you'd better disregard it. Nevertheless here it is: (1) Would it be possible to tell how many objects get marked exclusively by marking from pure storage? (2) Would it be possible to tell how many objects get marked exclusively by marking from ambiguous roots, that is, due to using conservative collection? Obviously, either (1) or (2) would be incorrect wrt the other, that is, if an object gets marked from the stack and has been already marked from pure storage that object would be counted under (1). Still I think that figures we'd get here could be useful. martin From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Dmitry Antipov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Apr 2014 08:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: martin rudalics Cc: 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139685872225140 (code B ref 17168); Mon, 07 Apr 2014 08:19:02 +0000 Received: (at 17168) by debbugs.gnu.org; 7 Apr 2014 08:18:42 +0000 Received: from localhost ([127.0.0.1]:38743 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WX4lN-0006XP-JS for submit@debbugs.gnu.org; Mon, 07 Apr 2014 04:18:41 -0400 Received: from forward9l.mail.yandex.net ([84.201.143.142]:41479) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WX4lK-0006XD-J0 for 17168@debbugs.gnu.org; Mon, 07 Apr 2014 04:18:39 -0400 Received: from smtp2h.mail.yandex.net (smtp2h.mail.yandex.net [84.201.187.145]) by forward9l.mail.yandex.net (Yandex) with ESMTP id D6BEFE60F61; Mon, 7 Apr 2014 12:18:36 +0400 (MSK) Received: from smtp2h.mail.yandex.net (localhost [127.0.0.1]) by smtp2h.mail.yandex.net (Yandex) with ESMTP id 6953A1703F78; Mon, 7 Apr 2014 12:18:36 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp2h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id RBEsfngee3-IZNKoZMM; Mon, 7 Apr 2014 12:18:35 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 226cdb3d-5458-4804-acf9-69a61f5a842d DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1396858715; bh=N3thAokgf8Ski1i2Kj8zpmHiMqtdC1KpPS+YfdVm+GI=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=MVgV81fNyHT+ykE1zKnwYmuLqmSAR7gIuTH5RHzTFzF2OfXSQ9USa325j6EW79HDW 15RD4QWaFLAsF7/qoyWJpb+IXui6BM53IWn0phxP5mZRpapFjbzSB9w6XQjb60D66m sg2seo/MNJVheo88PrDMhnPJgEI3CmD22Td+vDpU= Authentication-Results: smtp2h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <53425F5B.4020007@yandex.ru> Date: Mon, 07 Apr 2014 12:18:35 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <5340E09D.9020709@yandex.ru> <5340E1F1.1050909@dancol.org> <5341989E.7050509@dancol.org> <53425895.1090802@gmx.at> In-Reply-To: <53425895.1090802@gmx.at> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 04/07/2014 11:49 AM, martin rudalics wrote: > (1) Would it be possible to tell how many objects get marked exclusively > by marking from pure storage? Pure object is never marked itself, so there are no objects that gets marked just because they're referenced from the pure object. Dmitry From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Apr 2014 09:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Dmitry Antipov Cc: 17168@debbugs.gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139686243831962 (code B ref 17168); Mon, 07 Apr 2014 09:21:01 +0000 Received: (at 17168) by debbugs.gnu.org; 7 Apr 2014 09:20:38 +0000 Received: from localhost ([127.0.0.1]:38754 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WX5jJ-0008JS-Bo for submit@debbugs.gnu.org; Mon, 07 Apr 2014 05:20:37 -0400 Received: from mout.gmx.net ([212.227.17.22]:61708) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WX5jG-0008JF-1e for 17168@debbugs.gnu.org; Mon, 07 Apr 2014 05:20:35 -0400 Received: from [188.22.46.29] ([188.22.46.29]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lugbo-1WxWVr12rA-00zpji; Mon, 07 Apr 2014 11:20:31 +0200 Message-ID: <53426DDA.7060701@gmx.at> Date: Mon, 07 Apr 2014 11:20:26 +0200 From: martin rudalics MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <5340E09D.9020709@yandex.ru> <5340E1F1.1050909@dancol.org> <5341989E.7050509@dancol.org> <53425895.1090802@gmx.at> <53425F5B.4020007@yandex.ru> In-Reply-To: <53425F5B.4020007@yandex.ru> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:/S3bUmpN/FzKgDrkqgcLRTYzc+90ajjZxi//RHAoEWJf7j8yq97 syB3xeHyZKsE3EgDr+dw01MOtINl1eziAzDm4e7rbrA71ARKIMKAc/xMWAnTMjNeteFwBRw OqH3BE1WS3YG/USWZzxxrG4KvYXQXIX0A0N1NFn/Odp7vMTBn+n6wlNP49QAH/wfSpEZRle hlmHJSNgNxoccftnpIyCQ== X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (/) > Pure object is never marked itself, so there are no objects that > gets marked just because they're referenced from the pure object. I meant the objects reachable from Vpure_reachable. martin From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Richard Stallman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Apr 2014 16:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Stefan Monnier Cc: 17168@debbugs.gnu.org, dancol@dancol.org, dmantipov@yandex.ru Reply-To: rms@gnu.org Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139688981826030 (code B ref 17168); Mon, 07 Apr 2014 16:57:02 +0000 Received: (at 17168) by debbugs.gnu.org; 7 Apr 2014 16:56:58 +0000 Received: from localhost ([127.0.0.1]:39819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXCqv-0006ll-RS for submit@debbugs.gnu.org; Mon, 07 Apr 2014 12:56:58 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:49560) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXCqt-0006lb-64 for 17168@debbugs.gnu.org; Mon, 07 Apr 2014 12:56:55 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1WXCqq-0008QZ-9E; Mon, 07 Apr 2014 12:56:52 -0400 Date: Mon, 07 Apr 2014 12:56:52 -0400 Message-Id: Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman In-reply-to: (message from Stefan Monnier on Sun, 06 Apr 2014 15:58:10 -0400) References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> X-Spam-Score: -5.3 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -5.3 (-----) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > It might be faster just to traverse a list of these symbols, since > there are not very many uninterned symbols with names that are pure. That will fail (i.e. core-dump) if someone later uninterns one of those symbols pointed to from pure space. We're talking about a list of the uninterned symbols. Do you mean, if someone uninterns an interned symbol with a pure name? The other part of the change is to stop that from happening. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call. From unknown Sat Jun 21 12:19:20 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Nicolas Richard Subject: bug#17168: closed (Re: bug#17168: 24.3.50; Segfault at mark_object) Message-ID: References: <87y4zop44m.fsf@yahoo.fr> X-Gnu-PR-Message: they-closed 17168 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: moreinfo Reply-To: 17168@debbugs.gnu.org Date: Mon, 07 Apr 2014 18:41:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1396896063-4175-1" This is a multi-part message in MIME format... ------------=_1396896063-4175-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #17168: 24.3.50; Segfault at mark_object which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 17168@debbugs.gnu.org. --=20 17168: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D17168 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1396896063-4175-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 17168-done) by debbugs.gnu.org; 7 Apr 2014 18:40:39 +0000 Received: from localhost ([127.0.0.1]:39853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXETF-00014T-3h for submit@debbugs.gnu.org; Mon, 07 Apr 2014 14:40:38 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:41342) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXET9-00014I-VI for 17168-done@debbugs.gnu.org; Mon, 07 Apr 2014 14:40:32 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s37IeP88031961; Mon, 7 Apr 2014 14:40:26 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 0E765661DF; Mon, 7 Apr 2014 12:28:20 -0400 (EDT) From: Stefan Monnier To: Daniel Colascione Subject: Re: bug#17168: 24.3.50; Segfault at mark_object Message-ID: References: <87y4zop44m.fsf@yahoo.fr> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <534176F3.9090205@dancol.org> <5341B573.1010605@dancol.org> <5341C928.6040308@dancol.org> Date: Mon, 07 Apr 2014 12:28:20 -0400 In-Reply-To: <5341C928.6040308@dancol.org> (Daniel Colascione's message of "Sun, 06 Apr 2014 14:37:44 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4905=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4905> : inlines <695> : streams <1153548> : uri <1723188> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 17168-done Cc: Dmitry Antipov , 17168-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -1.6 (-) > Anyway, I'd like to get a fix into emacs-24 soon so we can make sure > we've fixed the GC bug. I installed a fix into emacs-24, which lets all symbols be uninterned. > Are you vetoing the general approach used in this patch? No: I think disallowing unintern is a good idea, but not for emacs-24. Indeed, as it turns out, the only non-pure objects referenced from pure space are symbols and distinguishing uninterned from interned reduces the number of such "pinned" objects from about 10K to about 250. Rather than scan all symbols to find the pinned ones, the code I installed into emacs-24 keeps a pointer to the first symbol_block that contains a pinned symbol. This way we only scan about 15K symbols at the beginning of every GC cycle to mark those 10K pinned symbols. Compared to keeping a vector of 10K object, this seems like a good tradeoff. For trunk, we could disallow uninterning pinned symbols, at which point it's worth the trouble to build a vector of those 250 remaining pinned symbols. Stefan ------------=_1396896063-4175-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 2 Apr 2014 07:44:32 +0000 Received: from localhost ([127.0.0.1]:60315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVFqY-0005qV-Eg for submit@debbugs.gnu.org; Wed, 02 Apr 2014 03:44:31 -0400 Received: from eggs.gnu.org ([208.118.235.92]:56452) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVFqU-0005qM-Bb for submit@debbugs.gnu.org; Wed, 02 Apr 2014 03:44:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WVFqM-0004Uj-Ub for submit@debbugs.gnu.org; Wed, 02 Apr 2014 03:44:26 -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,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:56715) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVFqM-0004Uf-R0 for submit@debbugs.gnu.org; Wed, 02 Apr 2014 03:44:18 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58166) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVFqG-0007Wp-Gg for bug-gnu-emacs@gnu.org; Wed, 02 Apr 2014 03:44:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WVFq9-0004TK-9K for bug-gnu-emacs@gnu.org; Wed, 02 Apr 2014 03:44:12 -0400 Received: from mxin.ulb.ac.be ([164.15.128.112]:5096) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVFq8-0004T1-Oq for bug-gnu-emacs@gnu.org; Wed, 02 Apr 2014 03:44:05 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApELAEe/O1OkD4Xx/2dsb2JhbABZg0GrGAIKglgBl3F0glNqJDQBiEQBFJ4yj22ZUwGIM4doi0cEjlmJfYY4hCaHW4MyOw Received: from mathsrv4.ulb.ac.be (HELO geodiff-mac3) ([164.15.133.241]) by smtp.ulb.ac.be with ESMTP; 02 Apr 2014 09:44:03 +0200 From: Nicolas Richard To: bug-gnu-emacs@gnu.org Subject: 24.3.50; Segfault at mark_object Date: Wed, 02 Apr 2014 09:44:25 +0200 Message-ID: <87y4zop44m.fsf@yahoo.fr> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -5.0 (-----) This happened while I was away. Program received signal SIGSEGV, Segmentation fault. mark_object (arg=194) at alloc.c:6127 6127 if (ptr->gcmarkbit) #0 mark_object (arg=194) at alloc.c:6127 #1 0x081b2a14 in mark_vectorlike (ptr=0xb9b0db0) at alloc.c:5785 #2 0x081b30df in mark_object (arg=194710965) at alloc.c:6117 #3 0x081b3116 in mark_object (arg=188747058) at alloc.c:6131 #4 0x081b1434 in mark_maybe_pointer (p=0xb400d30) at alloc.c:4563 #5 0x081b1484 in mark_memory (start=0xbfffd08c, end=0xbfffebdc) at alloc.c:4638 #6 0x081b14d1 in mark_stack () at alloc.c:4872 #7 0x081b231c in Fgarbage_collect () at alloc.c:5545 #8 0x0814bbb6 in maybe_gc () at lisp.h:4518 #9 0x081cdd73 in Ffuncall (nargs=2, args=0xbfffd2d0) at eval.c:2766 #10 0x081cbb68 in internal_condition_case_n (bfun=0x81cdcbb , nargs=2, args=0xbfffd2d0, handlers=139298778, hfun=0x8073814 ) at eval.c:1436 #11 0x0807392c in safe_call (nargs=2, func=141642493) at xdisp.c:2609 #12 0x08073969 in safe_call1 (fn=141642493, arg=139298754) at xdisp.c:2625 #13 0x080875a8 in prepare_menu_bars () at xdisp.c:11512 #14 0x0808ab42 in redisplay_internal () at xdisp.c:13403 #15 0x08089e98 in redisplay () at xdisp.c:13022 #16 0x08153013 in read_char (commandflag=1, map=218382190, prev_event=139298754, used_mouse_menu=0xbfffe8a3, end_time=0x0) at keyboard.c:2567 #17 0x0815d730 in read_key_sequence (keybuf=0xbfffe9c0, bufsize=30, prompt=139298754, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9079 #18 0x08151016 in command_loop_1 () at keyboard.c:1449 #19 0x081cb7e6 in internal_condition_case (bfun=0x8150cd3 , handlers=139331834, hfun=0x81506a9 ) at eval.c:1354 #20 0x08150a6f in command_loop_2 (ignore=139298754) at keyboard.c:1174 #21 0x081cb16e in internal_catch (tag=139329882, func=0x8150a4b , arg=139298754) at eval.c:1118 #22 0x08150a29 in command_loop () at keyboard.c:1153 #23 0x08150345 in recursive_edit_1 () at keyboard.c:777 #24 0x08150481 in Frecursive_edit () at keyboard.c:845 #25 0x0814e8b1 in main (argc=2, argv=0xbfffecd4) at emacs.c:1646 Lisp Backtrace: "Automatic GC" (0x84c678c) 0x8714af8 PVEC_COMPILED "redisplay_internal (C function)" (0x84c678c) #0 mark_object (arg=194) at alloc.c:6127 ptr = 0xc0 ptrx = 0xbfffcea8 obj = 192 cdr_count = 0 #1 0x081b2a14 in mark_vectorlike (ptr=0xb9b0db0) at alloc.c:5785 size = 36 i = 14 #2 0x081b30df in mark_object (arg=194710965) at alloc.c:6117 ptr = 0xb9b0db0 pvectype = 0 obj = 194710960 cdr_count = 0 #3 0x081b3116 in mark_object (arg=188747058) at alloc.c:6131 ptr = 0xb400d30 ptrx = 0x12 obj = 188747056 cdr_count = 0 #4 0x081b1434 in mark_maybe_pointer (p=0xb400d30) at alloc.c:4563 obj = 188747058 m = 0xb709250 #5 0x081b1484 in mark_memory (start=0xbfffd08c, end=0xbfffebdc) at alloc.c:4638 p = 0xb400d30 pp = 0xbfffde90 i = 0 #6 0x081b14d1 in mark_stack () at alloc.c:4872 end = 0xbfffd08c #7 0x081b231c in Fgarbage_collect () at alloc.c:5545 nextb = 0x0 stack_top_variable = 0 '\000' i = 1617 message_p = true count = 7 start = { tv_sec = 1396375514, tv_nsec = 188980653 } retval = 139298754 tot_before = 0 #8 0x0814bbb6 in maybe_gc () at lisp.h:4518 No locals. #9 0x081cdd73 in Ffuncall (nargs=2, args=0xbfffd2d0) at eval.c:2766 fun = 139319504 original_fun = 139319297 funcar = 0 numargs = 1 lisp_numargs = -1073753480 val = 138917188 internal_args = 0x0 i = 5 #10 0x081cbb68 in internal_condition_case_n (bfun=0x81cdcbb , nargs=2, args=0xbfffd2d0, handlers=139298778, hfun=0x8073814 ) at eval.c:1436 val = 139352440 c = 0x84e6500 #11 0x0807392c in safe_call (nargs=2, func=141642493) at xdisp.c:2609 i = 2 count = 5 gcpro1 = { next = 0x8714afd, var = 0xffd340, nvars = 2 } ap = 0xbfffd33c "H\323\377\277\005\262\024\bH\230U\b\310\323\377\277\250u\b\b\375Jq\b\302\207M\b\320\330M\b" args = 0xbfffd2d0 val = 136011655 #12 0x08073969 in safe_call1 (fn=141642493, arg=139298754) at xdisp.c:2625 No locals. #13 0x080875a8 in prepare_menu_bars () at xdisp.c:11512 windows = 139298754 all_windows = false some_windows = true gcpro1 = { next = 0xa0e9c28, var = 0x1, nvars = 1 } gcpro2 = { next = 0x0, var = 0xbfffd378, nvars = 134576184 } tooltip_frame = 139298754 #14 0x0808ab42 in redisplay_internal () at xdisp.c:13403 w = 0xb75b720 sw = 0xb75b720 fr = 0x84e46d0 pending = 0 must_finish = false match_p = false tlbufpos = { charpos = 136133708, bytepos = 139298754 } tlendpos = { charpos = 141207980, bytepos = -1073748696 } number_of_visible_frames = 1 count = 2 sf = 0x84e46d0 polling_stopped_here = 0 tail = 139298754 frame = 139347669 consider_all_windows_p = 8 update_miniwindow_p = false #15 0x08089e98 in redisplay () at xdisp.c:13022 No locals. #16 0x08153013 in read_char (commandflag=1, map=218382190, prev_event=139298754, used_mouse_menu=0xbfffe8a3, end_time=0x0) at keyboard.c:2567 echo_current = false c = 139298754 jmpcount = -1073748040 local_getcjmp = {{ __jmpbuf = {-1073748232, 136044005, 139319504, 0, -1073748264, 136011529}, __mask_was_saved = 141081056, __saved_mask = { __val = {141081056, 3221219032, 136133786, 139298754, 139319504, 141081056, 141431720, 139360971, 0, 3221219128, 135679500, 141431722, 139298778, 3221218816, 4294967295, 192, 0, 139298754, 3221219080, 135571235, 218382182, 3221219128, 135982083, 218382182, 218382174, 141431722, 141503502, 139298754, 139298754, 2, 139298754, 222500864} } }} save_jump = {{ __jmpbuf = {56, 139360971, 162623043, 169126963, 177160939, 206411387}, __mask_was_saved = 216942387, __saved_mask = { __val = {3067047979, 3068297204, 3068298304, 0, 28, 3067056153, 198911504, 178059944, 28, 4, 211656168, 3221214072, 3221218920, 135574114, 139319504, 6, 3067056073, 0, 0, 139319504, 3221218952, 135574114, 139319504, 6, 3221218984, 136011027, 139319509, 139319504, 3221218968, 135574303, 139319509, 139321778} } }} tem = 139298754 save = 142664326 previous_echo_area_message = 139298754 also_record = 139298754 reread = false gcpro1 = { next = 0x84de1b2, var = 0xbfffe6f8, nvars = 136044861 } gcpro2 = { next = 0x2fc, var = 0x1000006, nvars = 0 } polling_stopped_here = false orig_kboard = 0x889e340 #17 0x0815d730 in read_key_sequence (keybuf=0xbfffe9c0, bufsize=30, prompt=139298754, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9079 interrupted_kboard = 0x889e340 interrupted_frame = 0x84e46d0 key = 139319509 used_mouse_menu = false echo_local_start = 0 last_real_key_start = 0 keys_local_start = 0 new_binding = 139347669 count = 2 t = 0 echo_start = 0 keys_start = 0 current_binding = 218382190 first_event = 139298754 first_unbound = 31 mock_input = 0 fkey = { parent = 140966150, map = 140966150, start = 0, end = 0 } keytran = { parent = 139286286, map = 139286286, start = 0, end = 0 } indec = { parent = 140966158, map = 140966158, start = 0, end = 0 } shift_translated = false delayed_switch_frame = 139298754 original_uppercase = 134622171 original_uppercase_position = -1 dummyflag = false starting_buffer = 0x84dd8d0 fake_prefixed_keys = 139298754 gcpro1 = { next = 0x84d87c2, var = 0xbfffe8c8, nvars = 136011655 } #18 0x08151016 in command_loop_1 () at keyboard.c:1449 cmd = 141463658 keybuf = {96, 12, 137180145, 139298754, 139370802, 139298754, 4, 139298754, 141445706, 0, -1073747448, 135596160, 139329858, 210791238, 137180145, 139298754, 197184288, 0, -1073747352, 135595989, 210791238, -1073747409, -1073747384, 136104088, 2, 193733073, -1227911223, 0, 1919251558, 1797271584} i = 2 prev_modiff = 11 prev_buffer = 0x84dd8d0 already_adjusted = false #19 0x081cb7e6 in internal_condition_case (bfun=0x8150cd3 , handlers=139331834, hfun=0x81506a9 ) at eval.c:1354 val = 193733073 c = 0x84e6428 #20 0x08150a6f in command_loop_2 (ignore=139298754) at keyboard.c:1174 val = 0 #21 0x081cb16e in internal_catch (tag=139329882, func=0x8150a4b , arg=139298754) at eval.c:1118 val = 139298754 c = 0x88a0570 #22 0x08150a29 in command_loop () at keyboard.c:1153 No locals. #23 0x08150345 in recursive_edit_1 () at keyboard.c:777 count = 1 val = -1073747128 #24 0x08150481 in Frecursive_edit () at keyboard.c:845 count = 0 buffer = 139298754 #25 0x0814e8b1 in main (argc=2, argv=0xbfffecd4) at emacs.c:1646 dummy = 2 stack_bottom_variable = 0 '\000' do_initial_setlocale = true dumping = false skip_args = 1 rlim = { rlim_cur = 8388608, rlim_max = 18446744073709551615 } no_loadup = false junk = 0x0 dname_arg = 0x0 ch_to_dir = 0x0 original_pwd = 0x0 Lisp Backtrace: "Automatic GC" (0x84c678c) 0x8714af8 PVEC_COMPILED "redisplay_internal (C function)" (0x84c678c) #0 mark_object (arg=194) at alloc.c:6127 #1 0x081b2a14 in mark_vectorlike (ptr=0xb9b0db0) at alloc.c:5785 #2 0x081b30df in mark_object (arg=194710965) at alloc.c:6117 #3 0x081b3116 in mark_object (arg=188747058) at alloc.c:6131 #4 0x081b1434 in mark_maybe_pointer (p=0xb400d30) at alloc.c:4563 #5 0x081b1484 in mark_memory (start=0xbfffd08c, end=0xbfffebdc) at alloc.c:4638 #6 0x081b14d1 in mark_stack () at alloc.c:4872 #7 0x081b231c in Fgarbage_collect () at alloc.c:5545 #8 0x0814bbb6 in maybe_gc () at lisp.h:4518 #9 0x081cdd73 in Ffuncall (nargs=2, args=0xbfffd2d0) at eval.c:2766 #10 0x081cbb68 in internal_condition_case_n (bfun=0x81cdcbb , nargs=2, args=0xbfffd2d0, handlers=139298778, hfun=0x8073814 ) at eval.c:1436 #11 0x0807392c in safe_call (nargs=2, func=141642493) at xdisp.c:2609 #12 0x08073969 in safe_call1 (fn=141642493, arg=139298754) at xdisp.c:2625 #13 0x080875a8 in prepare_menu_bars () at xdisp.c:11512 #14 0x0808ab42 in redisplay_internal () at xdisp.c:13403 #15 0x08089e98 in redisplay () at xdisp.c:13022 #16 0x08153013 in read_char (commandflag=1, map=218382190, prev_event=139298754, used_mouse_menu=0xbfffe8a3, end_time=0x0) at keyboard.c:2567 #17 0x0815d730 in read_key_sequence (keybuf=0xbfffe9c0, bufsize=30, prompt=139298754, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9079 #18 0x08151016 in command_loop_1 () at keyboard.c:1449 #19 0x081cb7e6 in internal_condition_case (bfun=0x8150cd3 , handlers=139331834, hfun=0x81506a9 ) at eval.c:1354 #20 0x08150a6f in command_loop_2 (ignore=139298754) at keyboard.c:1174 #21 0x081cb16e in internal_catch (tag=139329882, func=0x8150a4b , arg=139298754) at eval.c:1118 #22 0x08150a29 in command_loop () at keyboard.c:1153 #23 0x08150345 in recursive_edit_1 () at keyboard.c:777 #24 0x08150481 in Frecursive_edit () at keyboard.c:845 #25 0x0814e8b1 in main (argc=2, argv=0xbfffecd4) at emacs.c:1646 Lisp Backtrace: "Automatic GC" (0x84c678c) 0x8714af8 PVEC_COMPILED "redisplay_internal (C function)" (0x84c678c) In GNU Emacs 24.3.50.7 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2014-03-27 on geodiff-mac3 Windowing system distributor `The X.Org Foundation', version 11.0.11304000 System Description: Gentoo Base System release 2.2 Configured using: `configure --with-x-toolkit=lucid 'CFLAGS= -O0 -g3'' Important settings: value of $LANG: fr_FR.UTF-8 locale-coding-system: utf-8-unix -- Nico. ------------=_1396896063-4175-1-- From unknown Sat Jun 21 12:19:20 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: rms@gnu.org Subject: bug#15583: closed (Re: bug#17168: 24.3.50; Segfault at mark_object) Message-ID: References: X-Gnu-PR-Message: they-closed 15583 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: moreinfo Reply-To: 15583@debbugs.gnu.org Date: Mon, 07 Apr 2014 18:41:04 +0000 Content-Type: multipart/mixed; boundary="----------=_1396896064-4175-3" This is a multi-part message in MIME format... ------------=_1396896064-4175-3 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #17168: 24.3.50; GC crashes which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 15583@debbugs.gnu.org. --=20 17168: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D17168 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1396896064-4175-3 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 17168-done) by debbugs.gnu.org; 7 Apr 2014 18:40:39 +0000 Received: from localhost ([127.0.0.1]:39853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXETF-00014T-3h for submit@debbugs.gnu.org; Mon, 07 Apr 2014 14:40:38 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:41342) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXET9-00014I-VI for 17168-done@debbugs.gnu.org; Mon, 07 Apr 2014 14:40:32 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s37IeP88031961; Mon, 7 Apr 2014 14:40:26 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 0E765661DF; Mon, 7 Apr 2014 12:28:20 -0400 (EDT) From: Stefan Monnier To: Daniel Colascione Subject: Re: bug#17168: 24.3.50; Segfault at mark_object Message-ID: References: <87y4zop44m.fsf@yahoo.fr> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <534176F3.9090205@dancol.org> <5341B573.1010605@dancol.org> <5341C928.6040308@dancol.org> Date: Mon, 07 Apr 2014 12:28:20 -0400 In-Reply-To: <5341C928.6040308@dancol.org> (Daniel Colascione's message of "Sun, 06 Apr 2014 14:37:44 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4905=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4905> : inlines <695> : streams <1153548> : uri <1723188> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 17168-done Cc: Dmitry Antipov , 17168-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -1.6 (-) > Anyway, I'd like to get a fix into emacs-24 soon so we can make sure > we've fixed the GC bug. I installed a fix into emacs-24, which lets all symbols be uninterned. > Are you vetoing the general approach used in this patch? No: I think disallowing unintern is a good idea, but not for emacs-24. Indeed, as it turns out, the only non-pure objects referenced from pure space are symbols and distinguishing uninterned from interned reduces the number of such "pinned" objects from about 10K to about 250. Rather than scan all symbols to find the pinned ones, the code I installed into emacs-24 keeps a pointer to the first symbol_block that contains a pinned symbol. This way we only scan about 15K symbols at the beginning of every GC cycle to mark those 10K pinned symbols. Compared to keeping a vector of 10K object, this seems like a good tradeoff. For trunk, we could disallow uninterning pinned symbols, at which point it's worth the trouble to build a vector of those 250 remaining pinned symbols. Stefan ------------=_1396896064-4175-3 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 10 Oct 2013 16:28:27 +0000 Received: from localhost ([127.0.0.1]:41057 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VUJ6A-00021C-Jo for submit@debbugs.gnu.org; Thu, 10 Oct 2013 12:28:27 -0400 Received: from eggs.gnu.org ([208.118.235.92]:52033) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VUJ68-000211-NZ for submit@debbugs.gnu.org; Thu, 10 Oct 2013 12:28:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VUJ67-0003ai-0P for submit@debbugs.gnu.org; Thu, 10 Oct 2013 12:28:24 -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.6 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:46467) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VUJ66-0003ae-TD for submit@debbugs.gnu.org; Thu, 10 Oct 2013 12:28:22 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53753) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VUJ65-0001by-Cp for bug-gnu-emacs@gnu.org; Thu, 10 Oct 2013 12:28:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VUJ63-0003aC-QO for bug-gnu-emacs@gnu.org; Thu, 10 Oct 2013 12:28:21 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49312) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VUJ63-0003a8-ND for bug-gnu-emacs@gnu.org; Thu, 10 Oct 2013 12:28:19 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1VUJ63-00021Q-1p; Thu, 10 Oct 2013 12:28:19 -0400 Date: Thu, 10 Oct 2013 12:28:19 -0400 Message-Id: Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman To: bug-gnu-emacs@gnu.org Subject: 24.3.50; GC crashes X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.2 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: rms@gnu.org 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: -5.2 (-----) Over the past few weeks, since updating, I have had several crashes in mark_object. The crashes started when I updated somewhere between Sep 17 and Sep 22. (I don't know how to tell more precisely when that was.) I did another update a week ago, hoping the problem would go away, but yesterday I got another crash of the same sort. My previous update had been around Aug 18; the crashes did not happen in that version. mark_object is reached about 3 levels down from mark_memory. Thus, I could not easily tell much about what data structure it was. If it is useful, I will try harder to get more info. In GNU Emacs 24.3.50.11 (mips64el-unknown-linux-gnu, GTK+ Version 2.20.1) of 2013-10-03 on chiefs-gnewsense Bzr revision: 114502 monnier@iro.umontreal.ca-20131002233348-j245zww7t0dfmeng System Description: gNewSense GNU/Linux 3.0 (parkes) Configured using: `configure 'CFLAGS=-g -O0'' Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix default enable-multibyte-characters: t Major mode: RMAIL Minor modes in effect: gpm-mouse-mode: t tooltip-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: t line-number-mode: t transient-mark-mode: t abbrev-mode: t Recent input: m e , SPC o r SPC s o m e SPC o t h e r SPC v 4 r DEL DEL e r s i o n SPC o f SPC i t . RET ESC ; C-c C-c n d x d u d d x n d u x C-u C-u C-n C-u C-n C-n C-@ C-n C-n C-n C-n r ESC , C-p C-p C-p C-p C-u C-n C-n C-o C-o C o u l d SPC s o m e o n e SPC t r y SPC t h a t ? C-c C-c ESC v C-x b o u t g TAB RET g C-p C-p C-p C-p C-o C-x o C-x b R TAB RET 1 r C-x o C-u C-p C-@ C-n ESC , C-p ESC f ESC f ESC f ESC f C-k RET RET T h e SPC w o r d SPC i s SPC " p i q u e d " . SPC SPC ( I t SPC c o m e ESC DEL i s SPC a SPC r c DEL e c e n t SPC b o r r o w i n g SPC f r o m SPC F r n e c h DEL DEL DEL DEL e n c . DEL h . ) C-n C-c C-c d d u d d d u x o g i t h TAB ESC DEL x m a i l / g i t h TAB RET d d ESC x r e s e n d SPC m a i l SPC a d d DEL DEL DEL SPC a d d r ESC DEL ESC DEL r e p o r t SPC e m a TAB RET Recent messages: Wrote /home/rms/outgoing/out-59 Sending...done Mark activated Mark set Auto-saving...done Sending... Wrote /home/rms/outgoing/out-60 Sending...done Expunging deleted messages...done Added to /home/rms/xmail/github.xmail Load-path shadows: /home/rms/emacs-bzr/trunk/lisp/net/shr-color hides /home/rms/emacs-bzr/trunk/lisp/gnus/shr-color /home/rms/emacs-bzr/trunk/lisp/net/shr hides /home/rms/emacs-bzr/trunk/lisp/gnus/shr Features: (shadow emacsbug rmailout mailalias qp quail help-mode misearch multi-isearch rmailmm message sendmail format-spec rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader mail-parse rfc2231 dired t-mouse finder-inf package rmailedit rmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date paren cus-start cus-load advice help-fns tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process dbusbind gfilenotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs) [ To any NSA and FBI agents reading my email: please consider [ whether defending the US Constitution against all enemies, [ foreign or domestic, requires you to follow Snowden's example. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call. ------------=_1396896064-4175-3-- From unknown Sat Jun 21 12:19:20 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: rms@gnu.org Subject: bug#15688: closed (Re: bug#17168: 24.3.50; Segfault at mark_object) Message-ID: References: X-Gnu-PR-Message: they-closed 15688 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: moreinfo Reply-To: 15688@debbugs.gnu.org Date: Mon, 07 Apr 2014 18:41:06 +0000 Content-Type: multipart/mixed; boundary="----------=_1396896066-4175-5" This is a multi-part message in MIME format... ------------=_1396896066-4175-5 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #17168: 24.3.50; clear-temporary-overlay-map which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 15688@debbugs.gnu.org. --=20 17168: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D17168 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1396896066-4175-5 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 17168-done) by debbugs.gnu.org; 7 Apr 2014 18:40:39 +0000 Received: from localhost ([127.0.0.1]:39853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXETF-00014T-3h for submit@debbugs.gnu.org; Mon, 07 Apr 2014 14:40:38 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:41342) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXET9-00014I-VI for 17168-done@debbugs.gnu.org; Mon, 07 Apr 2014 14:40:32 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s37IeP88031961; Mon, 7 Apr 2014 14:40:26 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 0E765661DF; Mon, 7 Apr 2014 12:28:20 -0400 (EDT) From: Stefan Monnier To: Daniel Colascione Subject: Re: bug#17168: 24.3.50; Segfault at mark_object Message-ID: References: <87y4zop44m.fsf@yahoo.fr> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <534176F3.9090205@dancol.org> <5341B573.1010605@dancol.org> <5341C928.6040308@dancol.org> Date: Mon, 07 Apr 2014 12:28:20 -0400 In-Reply-To: <5341C928.6040308@dancol.org> (Daniel Colascione's message of "Sun, 06 Apr 2014 14:37:44 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4905=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4905> : inlines <695> : streams <1153548> : uri <1723188> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 17168-done Cc: Dmitry Antipov , 17168-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -1.6 (-) > Anyway, I'd like to get a fix into emacs-24 soon so we can make sure > we've fixed the GC bug. I installed a fix into emacs-24, which lets all symbols be uninterned. > Are you vetoing the general approach used in this patch? No: I think disallowing unintern is a good idea, but not for emacs-24. Indeed, as it turns out, the only non-pure objects referenced from pure space are symbols and distinguishing uninterned from interned reduces the number of such "pinned" objects from about 10K to about 250. Rather than scan all symbols to find the pinned ones, the code I installed into emacs-24 keeps a pointer to the first symbol_block that contains a pinned symbol. This way we only scan about 15K symbols at the beginning of every GC cycle to mark those 10K pinned symbols. Compared to keeping a vector of 10K object, this seems like a good tradeoff. For trunk, we could disallow uninterning pinned symbols, at which point it's worth the trouble to build a vector of those 250 remaining pinned symbols. Stefan ------------=_1396896066-4175-5 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 23 Oct 2013 00:09:29 +0000 Received: from localhost ([127.0.0.1]:36250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VYm0t-0007h5-S1 for submit@debbugs.gnu.org; Tue, 22 Oct 2013 20:09:28 -0400 Received: from eggs.gnu.org ([208.118.235.92]:38323) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VYm0r-0007gp-BA for submit@debbugs.gnu.org; Tue, 22 Oct 2013 20:09:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VYm0k-00007W-LT for submit@debbugs.gnu.org; Tue, 22 Oct 2013 20:09:20 -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.9 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:49359) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYm0k-00007L-IJ for submit@debbugs.gnu.org; Tue, 22 Oct 2013 20:09:18 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40033) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYm0j-0005qS-1O for bug-gnu-emacs@gnu.org; Tue, 22 Oct 2013 20:09:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VYm0h-000064-RA for bug-gnu-emacs@gnu.org; Tue, 22 Oct 2013 20:09:16 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48749) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYm0h-00005y-Ng for bug-gnu-emacs@gnu.org; Tue, 22 Oct 2013 20:09:15 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1VYm0f-00052m-R0; Tue, 22 Oct 2013 20:09:14 -0400 Date: Tue, 22 Oct 2013 20:09:13 -0400 Message-Id: Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman To: bug-gnu-emacs@gnu.org Subject: 24.3.50; clear-temporary-overlay-map X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.4 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: rms@gnu.org 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: -5.4 (-----) I found that the crashes in GC result from trying to mark clear-temporary-overlay-map. Its function cell is a vectorlike which pr reports as #. The presence of such an object in the function cell is a bug, and it seems to me that for GC to try to mark the contents of a vectorlike with such a type is a second bug. In GNU Emacs 24.3.50.11 (mips64el-unknown-linux-gnu, GTK+ Version 2.20.1) of 2013-10-03 on chiefs-gnewsense Bzr revision: 114502 monnier@iro.umontreal.ca-20131002233348-j245zww7t0dfmeng System Description: gNewSense GNU/Linux 3.0 (parkes) Configured using: `configure 'CFLAGS=-g -O0'' Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix default enable-multibyte-characters: t Major mode: RMAIL Minor modes in effect: shell-dirtrack-mode: t gpm-mouse-mode: t tooltip-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: t line-number-mode: t transient-mark-mode: t abbrev-mode: t Recent input: r a . x TAB RET d d d u x 1 r C-u C-p C-u C-p C-p C-p C-p ESC f C-f C-f C-k C-x o C-u C-n C-n ESC f C-f C-f C-@ C-e ESC w C-x o C-y C-a C-u C-n C-u C-n C-n C-n C-n C-o W h a t SPC f o r m a t SPC d o SPC t h e y SPC ESC DEL ESC DEL w i l l SPC b e SPC u s e d SPC f o r SPC t h e SPC s t r e a m i n g ? C-c C-c d d d d x SPC C-s [ 2 3 ] C-s C-a C-n W C-c C-c ESC v d d d x T C-c C-c d d d d d d d d d d x C-x b i n o u t RET ESC x g r e p RET C-g C-x b TAB RET i x m a i l / l a p t o p TAB RET C-l ESC - ESC s b u n n i e RET ESC - ESC s RET C-@ C-e ESC w C-x b R TAB 1 RET C-x k RET C-x b 1 r DEL DEL C-g 1 r L a SPC d i r e c c C-\ i o ' n SPC q u e SPC t e n g o SPC e s SPC C-y . RET C-c C-c C-x k RET RET y e s RET r C-_ C-@ C-p ESC w C-x o r C-y C-c C-c d d d ESC x r e p o r t SPC e m a s SPC DEL DEL c DEL a c s SPC b u g RE T Recent messages: Mark set Sending... Wrote /home/rms/outgoing/out-92 Sending...done Please answer yes or no. Undo! Mark set [2 times] Sending... Wrote /home/rms/outgoing/out-93 Sending...done Load-path shadows: /home/rms/emacs-bzr/trunk/lisp/net/shr-color hides /home/rms/emacs-bzr/trunk/lisp/gnus/shr-color /home/rms/emacs-bzr/trunk/lisp/net/shr hides /home/rms/emacs-bzr/trunk/lisp/gnus/shr Features: -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call. ------------=_1396896066-4175-5-- From unknown Sat Jun 21 12:19:20 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: rms@gnu.org Subject: bug#15719: closed (Re: bug#17168: 24.3.50; Segfault at mark_object) Message-ID: References: X-Gnu-PR-Message: they-closed 15719 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: moreinfo Reply-To: 15719@debbugs.gnu.org Date: Mon, 07 Apr 2014 18:41:06 +0000 Content-Type: multipart/mixed; boundary="----------=_1396896066-4175-7" This is a multi-part message in MIME format... ------------=_1396896066-4175-7 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #17168: 24.3.50; crash in GC (again) which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 15719@debbugs.gnu.org. --=20 17168: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D17168 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1396896066-4175-7 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 17168-done) by debbugs.gnu.org; 7 Apr 2014 18:40:39 +0000 Received: from localhost ([127.0.0.1]:39853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXETF-00014T-3h for submit@debbugs.gnu.org; Mon, 07 Apr 2014 14:40:38 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:41342) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXET9-00014I-VI for 17168-done@debbugs.gnu.org; Mon, 07 Apr 2014 14:40:32 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s37IeP88031961; Mon, 7 Apr 2014 14:40:26 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 0E765661DF; Mon, 7 Apr 2014 12:28:20 -0400 (EDT) From: Stefan Monnier To: Daniel Colascione Subject: Re: bug#17168: 24.3.50; Segfault at mark_object Message-ID: References: <87y4zop44m.fsf@yahoo.fr> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <534176F3.9090205@dancol.org> <5341B573.1010605@dancol.org> <5341C928.6040308@dancol.org> Date: Mon, 07 Apr 2014 12:28:20 -0400 In-Reply-To: <5341C928.6040308@dancol.org> (Daniel Colascione's message of "Sun, 06 Apr 2014 14:37:44 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4905=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4905> : inlines <695> : streams <1153548> : uri <1723188> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 17168-done Cc: Dmitry Antipov , 17168-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -1.6 (-) > Anyway, I'd like to get a fix into emacs-24 soon so we can make sure > we've fixed the GC bug. I installed a fix into emacs-24, which lets all symbols be uninterned. > Are you vetoing the general approach used in this patch? No: I think disallowing unintern is a good idea, but not for emacs-24. Indeed, as it turns out, the only non-pure objects referenced from pure space are symbols and distinguishing uninterned from interned reduces the number of such "pinned" objects from about 10K to about 250. Rather than scan all symbols to find the pinned ones, the code I installed into emacs-24 keeps a pointer to the first symbol_block that contains a pinned symbol. This way we only scan about 15K symbols at the beginning of every GC cycle to mark those 10K pinned symbols. Compared to keeping a vector of 10K object, this seems like a good tradeoff. For trunk, we could disallow uninterning pinned symbols, at which point it's worth the trouble to build a vector of those 250 remaining pinned symbols. Stefan ------------=_1396896066-4175-7 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 25 Oct 2013 19:50:21 +0000 Received: from localhost ([127.0.0.1]:43987 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZnOm-0000uP-C6 for submit@debbugs.gnu.org; Fri, 25 Oct 2013 15:50:20 -0400 Received: from eggs.gnu.org ([208.118.235.92]:43712) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZnOj-0000uA-Jh for submit@debbugs.gnu.org; Fri, 25 Oct 2013 15:50:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZnOd-0000Db-AQ for submit@debbugs.gnu.org; Fri, 25 Oct 2013 15:50:12 -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.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:55992) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZnOd-0000DQ-7n for submit@debbugs.gnu.org; Fri, 25 Oct 2013 15:50:11 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45425) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZnOc-0000tS-8i for bug-gnu-emacs@gnu.org; Fri, 25 Oct 2013 15:50:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZnOb-0000B5-Bt for bug-gnu-emacs@gnu.org; Fri, 25 Oct 2013 15:50:10 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:32823) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZnOb-0000Ap-8w for bug-gnu-emacs@gnu.org; Fri, 25 Oct 2013 15:50:09 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1VZnOY-0007dE-6c; Fri, 25 Oct 2013 15:50:06 -0400 Date: Fri, 25 Oct 2013 15:50:06 -0400 Message-Id: Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman To: bug-gnu-emacs@gnu.org Subject: 24.3.50; crash in GC (again) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.4 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: rms@gnu.org 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: -5.4 (-----) I got another crash in GC, and it was from the same symbol, clear-temporary-overlay-map. In GNU Emacs 24.3.50.11 (mips64el-unknown-linux-gnu, GTK+ Version 2.20.1) of 2013-10-03 on chiefs-gnewsense Bzr revision: 114502 monnier@iro.umontreal.ca-20131002233348-j245zww7t0dfmeng System Description: gNewSense GNU/Linux 3.0 (parkes) Configured using: `configure 'CFLAGS=-g -O0'' Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix default enable-multibyte-characters: t Major mode: RMAIL Minor modes in effect: shell-dirtrack-mode: t gpm-mouse-mode: t tooltip-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: t line-number-mode: t transient-mark-mode: t abbrev-mode: t Recent messages: Expunging deleted messages...done Sending... Wrote /home/rms/outgoing/out-52 Sending...done Expunging deleted messages...done Mark set [2 times] Sending... Wrote /home/rms/outgoing/out-53 Sending...done Expunging deleted messages...done Load-path shadows: /home/rms/emacs-bzr/trunk/lisp/net/shr-color hides /home/rms/emacs-bzr/trunk/lisp/gnus/shr-color /home/rms/emacs-bzr/trunk/lisp/net/shr hides /home/rms/emacs-bzr/trunk/lisp/gnus/shr -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call. ------------=_1396896066-4175-7-- From unknown Sat Jun 21 12:19:20 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: rms@gnu.org Subject: bug#15972: closed (Re: bug#17168: 24.3.50; Segfault at mark_object) Message-ID: References: X-Gnu-PR-Message: they-closed 15972 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: moreinfo Reply-To: 15972@debbugs.gnu.org Date: Mon, 07 Apr 2014 18:41:07 +0000 Content-Type: multipart/mixed; boundary="----------=_1396896067-4175-9" This is a multi-part message in MIME format... ------------=_1396896067-4175-9 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #17168: 24.3.50; GC still crashes which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 15972@debbugs.gnu.org. --=20 17168: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D17168 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1396896067-4175-9 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 17168-done) by debbugs.gnu.org; 7 Apr 2014 18:40:39 +0000 Received: from localhost ([127.0.0.1]:39853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXETF-00014T-3h for submit@debbugs.gnu.org; Mon, 07 Apr 2014 14:40:38 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:41342) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXET9-00014I-VI for 17168-done@debbugs.gnu.org; Mon, 07 Apr 2014 14:40:32 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s37IeP88031961; Mon, 7 Apr 2014 14:40:26 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 0E765661DF; Mon, 7 Apr 2014 12:28:20 -0400 (EDT) From: Stefan Monnier To: Daniel Colascione Subject: Re: bug#17168: 24.3.50; Segfault at mark_object Message-ID: References: <87y4zop44m.fsf@yahoo.fr> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <534176F3.9090205@dancol.org> <5341B573.1010605@dancol.org> <5341C928.6040308@dancol.org> Date: Mon, 07 Apr 2014 12:28:20 -0400 In-Reply-To: <5341C928.6040308@dancol.org> (Daniel Colascione's message of "Sun, 06 Apr 2014 14:37:44 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4905=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4905> : inlines <695> : streams <1153548> : uri <1723188> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 17168-done Cc: Dmitry Antipov , 17168-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -1.6 (-) > Anyway, I'd like to get a fix into emacs-24 soon so we can make sure > we've fixed the GC bug. I installed a fix into emacs-24, which lets all symbols be uninterned. > Are you vetoing the general approach used in this patch? No: I think disallowing unintern is a good idea, but not for emacs-24. Indeed, as it turns out, the only non-pure objects referenced from pure space are symbols and distinguishing uninterned from interned reduces the number of such "pinned" objects from about 10K to about 250. Rather than scan all symbols to find the pinned ones, the code I installed into emacs-24 keeps a pointer to the first symbol_block that contains a pinned symbol. This way we only scan about 15K symbols at the beginning of every GC cycle to mark those 10K pinned symbols. Compared to keeping a vector of 10K object, this seems like a good tradeoff. For trunk, we could disallow uninterning pinned symbols, at which point it's worth the trouble to build a vector of those 250 remaining pinned symbols. Stefan ------------=_1396896067-4175-9 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 25 Nov 2013 12:26:58 +0000 Received: from localhost ([127.0.0.1]:43816 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VkvFg-0002Ue-SM for submit@debbugs.gnu.org; Mon, 25 Nov 2013 07:26:57 -0500 Received: from eggs.gnu.org ([208.118.235.92]:60163) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VkvFd-0002UM-90 for submit@debbugs.gnu.org; Mon, 25 Nov 2013 07:26:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VkvFS-00043i-MW for submit@debbugs.gnu.org; Mon, 25 Nov 2013 07:26:47 -0500 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,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:48412) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VkvFS-00043e-Jm for submit@debbugs.gnu.org; Mon, 25 Nov 2013 07:26:42 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33594) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VkvFN-0005Wy-Hz for bug-gnu-emacs@gnu.org; Mon, 25 Nov 2013 07:26:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VkvFI-00040g-9z for bug-gnu-emacs@gnu.org; Mon, 25 Nov 2013 07:26:37 -0500 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36873) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VkvFI-00040X-6H for bug-gnu-emacs@gnu.org; Mon, 25 Nov 2013 07:26:32 -0500 Received: from rms by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1VkvFH-0006Hm-IE; Mon, 25 Nov 2013 07:26:31 -0500 Date: Mon, 25 Nov 2013 07:26:31 -0500 Message-Id: Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman To: bug-gnu-emacs@gnu.org Subject: 24.3.50; GC still crashes X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: rms@gnu.org 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: -5.0 (-----) I am still getting the crashes in GC that I reported, where a symbol clear-overlay- points to an invalid vectorlike. In GNU Emacs 24.3.50.15 (mips64el-unknown-linux-gnu, GTK+ Version 2.20.1) of 2013-11-22 on chiefs-gnewsense Bzr revision: 115176 eliz@gnu.org-20131121192242-jqvypz42rz31z87q System Description: gNewSense GNU/Linux 3.0 (parkes) Configured using: `configure 'CFLAGS=-g -O0'' Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix default enable-multibyte-characters: t Major mode: Dired by date Minor modes in effect: shell-dirtrack-mode: t gpm-mouse-mode: t tooltip-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: t line-number-mode: t transient-mark-mode: t abbrev-mode: t Recent input: c ESC f ESC f ESC f C-k C-o , SPC b u t SPC t h e SPC q u e s t i o n SPC i s , SPC h o w SPC b i g SPC i s SPC ESC DEL ESC DEL i m p o r t a n t SPC i s SPC i t RET a n d SPC h o w SPC ESC DEL w h a t SPC C-a C-k DEL DEL t ? RET W h a t SPC d o SPC C-d C-d ESC q C-x C-s C-x b RET C-n C-o ESC C-v C-n C-o ESC C-v C-n C-o C-x 4 m v e r l DEL n a l e o C-n N e w SPC h o m e SPC p a g e C-a C-n C-n C-n C-u C-k C-o W o u d l SPC i t SPC m a k e SPC s e n s e C-a ESC f C-b C-t C-e SPC t o SPC a s k SPC L o g i n e r SPC v o n SPC W e b SPC t o SPC u p d a t e SPC h i s SPC n e w SPC h o m e SPC p a g e RET s o SPC y o u SPC d o n ' t SPC h a v e SPC t o ? C-c C-g ESC ; C-d 3 d C-c C-c C-x o C-n C-o ESC C-v C-n C-o ESC C-v C-n C-o ESC C-v C-n C-o C-n C-o C-n C-o C-l ESC x r e p o r t SPC e m a c v s SPC b DEL DEL DEL s SPC SPC u DEL RET Recent messages: Wrote /home/rms/outgoing/out-54 Quit Saving file /home/rms/outgoing/out-54... Wrote /home/rms/outgoing/out-54 Auto-saving...done C-c C-g is undefined Mark set Sending... Wrote /home/rms/outgoing/out-84 Sending...done Load-path shadows: /home/rms/emacs-bzr/trunk/lisp/net/shr-color hides /home/rms/emacs-bzr/trunk/lisp/gnus/shr-color /home/rms/emacs-bzr/trunk/lisp/net/shr hides /home/rms/emacs-bzr/trunk/lisp/gnus/shr /home/rms/emacs-bzr/trunk/lisp/net/rcompile hides /home/rms/emacs-bzr/trunk/lisp/obsolete/rcompile Features: (shadow emacsbug rmailkwd vc-arch vc-mtn vc-hg vc-git vc-bzr vc-sccs vc-svn vc-rcs vc vc-dispatcher view jka-compr ispell rect unrmail parse-time vc-cvs sgml-mode etags epa-mail org-element org-rmail org-mhe org-irc org-info org-gnus gnus-util org-docview org-bibtex bibtex org-bbdb org-w3m org byte-opt bytecomp byte-compile cconv org-macro org-footnote org-pcomplete org-list org-faces org-entities noutline outline easy-mmode org-version ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob ob-table ob-keys ob-exp ob-comint ob-core cl-macs gv cl cl-loaddefs cl-lib ob-eval org-compat org-macs org-loaddefs find-func epa derived epg epg-config quail help-mode shell pcomplete grep compile comint ansi-color ring mule-util cal-move cal-menu calendar cal-loaddefs dabbrev rmailsum misearch multi-isearch dired-aux rmailout mailalias qp rmailmm message sendmail format-spec rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader mail-parse rfc2231 dired t-mouse finder-inf package rmailedit rmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date paren cus-start cus-load advice help-fns tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process dbusbind gfilenotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs) [ To any NSA and FBI agents reading my email: please consider [ whether defending the US Constitution against all enemies, [ foreign or domestic, requires you to follow Snowden's example. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call. ------------=_1396896067-4175-9-- From unknown Sat Jun 21 12:19:20 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: rms@gnu.org Subject: bug#16278: closed (Re: bug#17168: 24.3.50; Segfault at mark_object) Message-ID: References: X-Gnu-PR-Message: they-closed 16278 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: moreinfo Reply-To: 16278@debbugs.gnu.org Date: Mon, 07 Apr 2014 18:41:09 +0000 Content-Type: multipart/mixed; boundary="----------=_1396896069-4175-11" This is a multi-part message in MIME format... ------------=_1396896069-4175-11 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #17168: 24.3.50; Crashes in GC continue which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 16278@debbugs.gnu.org. --=20 17168: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D17168 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1396896069-4175-11 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 17168-done) by debbugs.gnu.org; 7 Apr 2014 18:40:39 +0000 Received: from localhost ([127.0.0.1]:39853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXETF-00014T-3h for submit@debbugs.gnu.org; Mon, 07 Apr 2014 14:40:38 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:41342) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXET9-00014I-VI for 17168-done@debbugs.gnu.org; Mon, 07 Apr 2014 14:40:32 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s37IeP88031961; Mon, 7 Apr 2014 14:40:26 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 0E765661DF; Mon, 7 Apr 2014 12:28:20 -0400 (EDT) From: Stefan Monnier To: Daniel Colascione Subject: Re: bug#17168: 24.3.50; Segfault at mark_object Message-ID: References: <87y4zop44m.fsf@yahoo.fr> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <534176F3.9090205@dancol.org> <5341B573.1010605@dancol.org> <5341C928.6040308@dancol.org> Date: Mon, 07 Apr 2014 12:28:20 -0400 In-Reply-To: <5341C928.6040308@dancol.org> (Daniel Colascione's message of "Sun, 06 Apr 2014 14:37:44 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4905=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4905> : inlines <695> : streams <1153548> : uri <1723188> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 17168-done Cc: Dmitry Antipov , 17168-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -1.6 (-) > Anyway, I'd like to get a fix into emacs-24 soon so we can make sure > we've fixed the GC bug. I installed a fix into emacs-24, which lets all symbols be uninterned. > Are you vetoing the general approach used in this patch? No: I think disallowing unintern is a good idea, but not for emacs-24. Indeed, as it turns out, the only non-pure objects referenced from pure space are symbols and distinguishing uninterned from interned reduces the number of such "pinned" objects from about 10K to about 250. Rather than scan all symbols to find the pinned ones, the code I installed into emacs-24 keeps a pointer to the first symbol_block that contains a pinned symbol. This way we only scan about 15K symbols at the beginning of every GC cycle to mark those 10K pinned symbols. Compared to keeping a vector of 10K object, this seems like a good tradeoff. For trunk, we could disallow uninterning pinned symbols, at which point it's worth the trouble to build a vector of those 250 remaining pinned symbols. Stefan ------------=_1396896069-4175-11 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 28 Dec 2013 12:27:37 +0000 Received: from localhost ([127.0.0.1]:48020 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VwszQ-0000Z9-Ah for submit@debbugs.gnu.org; Sat, 28 Dec 2013 07:27:37 -0500 Received: from eggs.gnu.org ([208.118.235.92]:38538) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VwszN-0000Yx-Cs for submit@debbugs.gnu.org; Sat, 28 Dec 2013 07:27:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VwszL-0006e6-Ia for submit@debbugs.gnu.org; Sat, 28 Dec 2013 07:27:33 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:52605) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VwszL-0006e2-Fu for submit@debbugs.gnu.org; Sat, 28 Dec 2013 07:27:31 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40248) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VwszK-0004VP-0E for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2013 07:27:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VwszI-0006cN-3X for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2013 07:27:29 -0500 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55192) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VwszH-0006cJ-Vv for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2013 07:27:28 -0500 Received: from rms by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1VwszH-0003Ig-EZ; Sat, 28 Dec 2013 07:27:27 -0500 Date: Sat, 28 Dec 2013 07:27:27 -0500 Message-Id: Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman To: bug-gnu-emacs@gnu.org Subject: 24.3.50; Crashes in GC continue X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.6 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: rms@gnu.org 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: -5.6 (-----) I still get crashes in GC from trying to mark clear-temporary-overlay-map. Why create that symbol? Why not use an interned symbol? A comment says that nested temporary maps don't work anyway. But nested maps could be supported by using clear-temporary-overlay-map-1, clear-temporary-overlay-map-2, and so on, all interned. Of course, the real bug is in GC. The Lisp code is correct and it ought to work. But I don't understand the GC bug, and no one else is fixing it. So I propose to install this change. === modified file 'lisp/subr.el' *** lisp/subr.el 2013-12-20 19:55:56 +0000 --- lisp/subr.el 2013-12-27 21:19:34 +0000 *************** *** 4280,4286 **** Optional ON-EXIT argument is a function that is called after the deactivation of MAP." ! (let ((clearfun (make-symbol "clear-temporary-overlay-map"))) ;; Don't use letrec, because equal (in add/remove-hook) would get trapped ;; in a cycle. (fset clearfun --- 4280,4286 ---- Optional ON-EXIT argument is a function that is called after the deactivation of MAP." ! (let ((clearfun 'clear-temporary-overlay-map)) ;; Don't use letrec, because equal (in add/remove-hook) would get trapped ;; in a cycle. (fset clearfun In GNU Emacs 24.3.50.18 (mips64el-unknown-linux-gnu, GTK+ Version 2.20.1) of 2013-12-14 on chiefs-gnewsense Bzr revision: 115526 tzz@lifelogs.com-20131214180409-n2o5017gxsjvz8as System Description: gNewSense GNU/Linux 3.0 (parkes) Configured using: `configure 'CFLAGS=-g -O0'' Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix default enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes in effect: diff-auto-refine-mode: t shell-dirtrack-mode: t gpm-mouse-mode: t tooltip-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t abbrev-mode: t Recent input: l l SPC m e SPC t h e SPC n a m e SPC o f SPC O N E SPC s p e c i f i c SPC s o u r c e SPC f i l e SPC t h a t SPC h a s RET t h i s SPC k i n d SPC f SPC DEL DEL o f SPC n o t c i e ? C-b C-b C-b C-t C-e RET C-c C-c C-x b c a l l s RET C-p C-p C-@ C-n C-n C-n C-n C-w C-x C-s C-p C-p C-p C-@ C-e ESC w C-x 4 m C-x o C-p C-@ C-n C-n C-w C-x C-s C-x b R TAB RET C-x 1 n n n n n n n n C-l C-x C-s C-x d e m a c s - b z r / t r u n k / l s p DEL DEL i s p RET ESC x g r e p RET c l e a r - y e k p DEL DEL DEL DEL t e m p o r a r y - o v e r l a y - m a p SPC * / e l SPC * / * . e l RET ESC x g r e p RET ESC p ESC b ESC b DEL . ESC f C-k RET C-x o C-u C-n RET C-x 1 ESC v C-a C-u C-v C-u C-v C-u C-v C-u C-v C-a C-u C-v C-u C-v C-u C-v C-u C-v C-u C-p C-u C-v C-u C-v C-u C-v C-u C-v C-u C-v C-u C-v ESC x r e p o r t SPC e m a c s SPC b u g RET Recent messages: Mark set Auto-saving...done Mark set Saving file /home/rms/calls... Wrote /home/rms/calls Saving file /home/rms/RMAIL... Wrote /home/rms/RMAIL [2 times] Grep exited abnormally with code 2 Grep finished (matches found) Mark set Load-path shadows: /home/rms/emacs-bzr/trunk/lisp/leim/quail/lao hides /home/rms/emacs-bzr/trunk/lisp/language/lao /home/rms/emacs-bzr/trunk/lisp/leim/quail/georgian hides /home/rms/emacs-bzr/trunk/lisp/language/georgian /home/rms/emacs-bzr/trunk/lisp/leim/quail/thai hides /home/rms/emacs-bzr/trunk/lisp/language/thai /home/rms/emacs-bzr/trunk/lisp/leim/quail/ethiopic hides /home/rms/emacs-bzr/trunk/lisp/language/ethiopic /home/rms/emacs-bzr/trunk/lisp/leim/quail/japanese hides /home/rms/emacs-bzr/trunk/lisp/language/japanese /home/rms/emacs-bzr/trunk/lisp/leim/quail/cyrillic hides /home/rms/emacs-bzr/trunk/lisp/language/cyrillic /home/rms/emacs-bzr/trunk/lisp/leim/quail/indian hides /home/rms/emacs-bzr/trunk/lisp/language/indian /home/rms/emacs-bzr/trunk/lisp/leim/quail/hebrew hides /home/rms/emacs-bzr/trunk/lisp/language/hebrew /home/rms/emacs-bzr/trunk/lisp/leim/quail/greek hides /home/rms/emacs-bzr/trunk/lisp/language/greek /home/rms/emacs-bzr/trunk/lisp/leim/quail/czech hides /home/rms/emacs-bzr/trunk/lisp/language/czech /home/rms/emacs-bzr/trunk/lisp/leim/quail/slovak hides /home/rms/emacs-bzr/trunk/lisp/language/slovak /home/rms/emacs-bzr/trunk/lisp/leim/quail/tibetan hides /home/rms/emacs-bzr/trunk/lisp/language/tibetan Features: (tabify man goto-addr sh-script smie executable apropos smerge-mode cl-macs gv vc-sccs vc-svn vc-dir ewoc bug-reference whitespace vc-rcs js json imenu cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs arc-mode archive-mode tex-mode latexenc ox-latex ox-icalendar ox-html ox-ascii ox-publish ox novice view wid-edit etags log-edit diff-mode org-element org-rmail org-mhe org-irc org-info org-gnus org-docview doc-view image-mode cl-loaddefs cl-lib org-bibtex bibtex org-bbdb org-w3m org org-macro org-footnote org-pcomplete org-list org-faces org-entities noutline outline org-version ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob ob-table ob-keys ob-exp ob-comint ob-core ob-eval org-compat org-macs org-loaddefs ispell ffap thingatpt url-parse auth-source eieio byte-opt bytecomp byte-compile cconv eieio-core password-cache url-vars parse-time vc-cvs jka-compr gnus-util mailcap cal-move cal-menu calendar cal-loaddefs dired-aux mule-util quail rmailout sgml-mode dabbrev rmailsum pp compare-w add-log log-view easy-mmode pcvs-util vc vc-dispatcher vc-bzr find-func mail-extr shadow emacsbug help-mode misearch multi-isearch epa-mail epa derived epg epg-config shell pcomplete grep compile comint ansi-color ring mailalias qp rmailmm message sendmail format-spec rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader mail-parse rfc2231 dired t-mouse package rmailedit rmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date paren cus-start cus-load advice help-fns tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process dbusbind gfilenotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call. ------------=_1396896069-4175-11-- From unknown Sat Jun 21 12:19:20 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: rms@gnu.org Subject: bug#16521: closed (Re: bug#17168: 24.3.50; Segfault at mark_object) Message-ID: References: X-Gnu-PR-Message: they-closed 16521 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: moreinfo Reply-To: 16521@debbugs.gnu.org Date: Mon, 07 Apr 2014 18:41:10 +0000 Content-Type: multipart/mixed; boundary="----------=_1396896070-4175-13" This is a multi-part message in MIME format... ------------=_1396896070-4175-13 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #17168: 24.3.50; Same GC crash which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 16521@debbugs.gnu.org. --=20 17168: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D17168 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1396896070-4175-13 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 17168-done) by debbugs.gnu.org; 7 Apr 2014 18:40:39 +0000 Received: from localhost ([127.0.0.1]:39853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXETF-00014T-3h for submit@debbugs.gnu.org; Mon, 07 Apr 2014 14:40:38 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:41342) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXET9-00014I-VI for 17168-done@debbugs.gnu.org; Mon, 07 Apr 2014 14:40:32 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s37IeP88031961; Mon, 7 Apr 2014 14:40:26 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 0E765661DF; Mon, 7 Apr 2014 12:28:20 -0400 (EDT) From: Stefan Monnier To: Daniel Colascione Subject: Re: bug#17168: 24.3.50; Segfault at mark_object Message-ID: References: <87y4zop44m.fsf@yahoo.fr> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <534176F3.9090205@dancol.org> <5341B573.1010605@dancol.org> <5341C928.6040308@dancol.org> Date: Mon, 07 Apr 2014 12:28:20 -0400 In-Reply-To: <5341C928.6040308@dancol.org> (Daniel Colascione's message of "Sun, 06 Apr 2014 14:37:44 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4905=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4905> : inlines <695> : streams <1153548> : uri <1723188> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 17168-done Cc: Dmitry Antipov , 17168-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -1.6 (-) > Anyway, I'd like to get a fix into emacs-24 soon so we can make sure > we've fixed the GC bug. I installed a fix into emacs-24, which lets all symbols be uninterned. > Are you vetoing the general approach used in this patch? No: I think disallowing unintern is a good idea, but not for emacs-24. Indeed, as it turns out, the only non-pure objects referenced from pure space are symbols and distinguishing uninterned from interned reduces the number of such "pinned" objects from about 10K to about 250. Rather than scan all symbols to find the pinned ones, the code I installed into emacs-24 keeps a pointer to the first symbol_block that contains a pinned symbol. This way we only scan about 15K symbols at the beginning of every GC cycle to mark those 10K pinned symbols. Compared to keeping a vector of 10K object, this seems like a good tradeoff. For trunk, we could disallow uninterning pinned symbols, at which point it's worth the trouble to build a vector of those 250 remaining pinned symbols. Stefan ------------=_1396896070-4175-13 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 22 Jan 2014 15:31:57 +0000 Received: from localhost ([127.0.0.1]:60786 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W5zmV-0006wl-HG for submit@debbugs.gnu.org; Wed, 22 Jan 2014 10:31:55 -0500 Received: from eggs.gnu.org ([208.118.235.92]:34733) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W5zmQ-0006wa-0i for submit@debbugs.gnu.org; Wed, 22 Jan 2014 10:31:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5zmO-00062i-F0 for submit@debbugs.gnu.org; Wed, 22 Jan 2014 10:31:49 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:58897) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5zmO-00062e-C8 for submit@debbugs.gnu.org; Wed, 22 Jan 2014 10:31:48 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5zmM-0004vx-RW for bug-gnu-emacs@gnu.org; Wed, 22 Jan 2014 10:31:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5zmI-0005v2-C3 for bug-gnu-emacs@gnu.org; Wed, 22 Jan 2014 10:31:46 -0500 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52248) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5zmI-0005uw-8M for bug-gnu-emacs@gnu.org; Wed, 22 Jan 2014 10:31:42 -0500 Received: from rms by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1W5zmH-0000v4-N6; Wed, 22 Jan 2014 10:31:41 -0500 Date: Wed, 22 Jan 2014 10:31:41 -0500 Message-Id: Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman To: bug-gnu-emacs@gnu.org Subject: 24.3.50; Same GC crash X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.6 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: rms@gnu.org 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: -5.6 (-----) The same sort of GC crash related to the symbol clear-temporary-overlay-map has happened again. The symbol name is different but the crash looked the same. In GNU Emacs 24.3.50.19 (mips64el-unknown-linux-gnu, GTK+ Version 2.20.1) of 2014-01-20 on chiefs-gnewsense Repository revision: 116080 juri@jurta.org-20140120085244-we8lcz34pybgqzvj System Description: gNewSense GNU/Linux 3.0 (parkes) Configured using: `configure 'CFLAGS=-g -O0'' Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: RMAIL Minor modes in effect: shell-dirtrack-mode: t gpm-mouse-mode: t tooltip-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: t line-number-mode: t transient-mark-mode: t abbrev-mode: t Recent messages: Wrote /home/rms/foo.html Mark set [2 times] Auto-saving...done Mark set Beginning of buffer Mark set Auto-saving...done Sending... Wrote /home/rms/outgoing/out-33 Sending...done Load-path shadows: /home/rms/emacs-bzr/trunk/lisp/leim/quail/lao hides /home/rms/emacs-bzr/trunk/lisp/language/lao /home/rms/emacs-bzr/trunk/lisp/leim/quail/georgian hides /home/rms/emacs-bzr/trunk/lisp/language/georgian /home/rms/emacs-bzr/trunk/lisp/leim/quail/thai hides /home/rms/emacs-bzr/trunk/lisp/language/thai /home/rms/emacs-bzr/trunk/lisp/leim/quail/ethiopic hides /home/rms/emacs-bzr/trunk/lisp/language/ethiopic /home/rms/emacs-bzr/trunk/lisp/leim/quail/japanese hides /home/rms/emacs-bzr/trunk/lisp/language/japanese /home/rms/emacs-bzr/trunk/lisp/leim/quail/cyrillic hides /home/rms/emacs-bzr/trunk/lisp/language/cyrillic /home/rms/emacs-bzr/trunk/lisp/leim/quail/indian hides /home/rms/emacs-bzr/trunk/lisp/language/indian /home/rms/emacs-bzr/trunk/lisp/leim/quail/hebrew hides /home/rms/emacs-bzr/trunk/lisp/language/hebrew /home/rms/emacs-bzr/trunk/lisp/leim/quail/greek hides /home/rms/emacs-bzr/trunk/lisp/language/greek /home/rms/emacs-bzr/trunk/lisp/leim/quail/czech hides /home/rms/emacs-bzr/trunk/lisp/language/czech /home/rms/emacs-bzr/trunk/lisp/leim/quail/slovak hides /home/rms/emacs-bzr/trunk/lisp/language/slovak /home/rms/emacs-bzr/trunk/lisp/leim/quail/tibetan hides /home/rms/emacs-bzr/trunk/lisp/language/tibetan Features: (shadow emacsbug ispell mule-util find-func debug dired-aux jka-compr epa-mail epa derived epg epg-config dabbrev rmailsum quail help-mode rmailout shell pcomplete grep mailalias qp warnings dframe cl-macs gv cl-loaddefs cl-lib byte-opt compile comint ansi-color ring bytecomp byte-compile cconv misearch multi-isearch vc-bzr rmailmm message sendmail format-spec rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader mail-parse rfc2231 dired t-mouse package rmailedit rmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date paren cus-start cus-load advice help-fns tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process dbusbind gfilenotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call. ------------=_1396896070-4175-13-- From unknown Sat Jun 21 12:19:20 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Nicolas Richard Subject: bug#17167: closed (Re: bug#17168: 24.3.50; Segfault at mark_object) Message-ID: References: <871txgqipo.fsf@yahoo.fr> X-Gnu-PR-Message: they-closed 17167 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: moreinfo Reply-To: 17167@debbugs.gnu.org Date: Mon, 07 Apr 2014 18:41:11 +0000 Content-Type: multipart/mixed; boundary="----------=_1396896071-4175-15" This is a multi-part message in MIME format... ------------=_1396896071-4175-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #17168: 24.3.50; Segfault at mark_object which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 17167@debbugs.gnu.org. --=20 17168: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D17168 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1396896071-4175-15 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 17168-done) by debbugs.gnu.org; 7 Apr 2014 18:40:39 +0000 Received: from localhost ([127.0.0.1]:39853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXETF-00014T-3h for submit@debbugs.gnu.org; Mon, 07 Apr 2014 14:40:38 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:41342) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXET9-00014I-VI for 17168-done@debbugs.gnu.org; Mon, 07 Apr 2014 14:40:32 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s37IeP88031961; Mon, 7 Apr 2014 14:40:26 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 0E765661DF; Mon, 7 Apr 2014 12:28:20 -0400 (EDT) From: Stefan Monnier To: Daniel Colascione Subject: Re: bug#17168: 24.3.50; Segfault at mark_object Message-ID: References: <87y4zop44m.fsf@yahoo.fr> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <534176F3.9090205@dancol.org> <5341B573.1010605@dancol.org> <5341C928.6040308@dancol.org> Date: Mon, 07 Apr 2014 12:28:20 -0400 In-Reply-To: <5341C928.6040308@dancol.org> (Daniel Colascione's message of "Sun, 06 Apr 2014 14:37:44 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4905=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4905> : inlines <695> : streams <1153548> : uri <1723188> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 17168-done Cc: Dmitry Antipov , 17168-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -1.6 (-) > Anyway, I'd like to get a fix into emacs-24 soon so we can make sure > we've fixed the GC bug. I installed a fix into emacs-24, which lets all symbols be uninterned. > Are you vetoing the general approach used in this patch? No: I think disallowing unintern is a good idea, but not for emacs-24. Indeed, as it turns out, the only non-pure objects referenced from pure space are symbols and distinguishing uninterned from interned reduces the number of such "pinned" objects from about 10K to about 250. Rather than scan all symbols to find the pinned ones, the code I installed into emacs-24 keeps a pointer to the first symbol_block that contains a pinned symbol. This way we only scan about 15K symbols at the beginning of every GC cycle to mark those 10K pinned symbols. Compared to keeping a vector of 10K object, this seems like a good tradeoff. For trunk, we could disallow uninterning pinned symbols, at which point it's worth the trouble to build a vector of those 250 remaining pinned symbols. Stefan ------------=_1396896071-4175-15 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 2 Apr 2014 07:44:18 +0000 Received: from localhost ([127.0.0.1]:60312 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVFqK-0005q3-EI for submit@debbugs.gnu.org; Wed, 02 Apr 2014 03:44:17 -0400 Received: from eggs.gnu.org ([208.118.235.92]:56426) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WVFqF-0005ps-Fa for submit@debbugs.gnu.org; Wed, 02 Apr 2014 03:44:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WVFq8-0004Sx-4Q for submit@debbugs.gnu.org; Wed, 02 Apr 2014 03:44: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.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:39136) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVFq8-0004Ss-0g for submit@debbugs.gnu.org; Wed, 02 Apr 2014 03:44:04 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58094) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVFq1-0007W9-LN for bug-gnu-emacs@gnu.org; Wed, 02 Apr 2014 03:44:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WVFpv-0004Qi-Ay for bug-gnu-emacs@gnu.org; Wed, 02 Apr 2014 03:43:57 -0400 Received: from mxin.ulb.ac.be ([164.15.128.112]:5061) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVFpu-0004QS-Qd for bug-gnu-emacs@gnu.org; Wed, 02 Apr 2014 03:43:51 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApELAEe/O1OkD4Xx/2dsb2JhbABZg0GrGAIKglgBl3F0glNqJDQBiEQBFJ4yj22ZUwGIM4doi0cEjlmJfYY4hCaHW4MyOw Received: from mathsrv4.ulb.ac.be (HELO geodiff-mac3) ([164.15.133.241]) by smtp.ulb.ac.be with ESMTP; 02 Apr 2014 09:43:41 +0200 From: Nicolas Richard To: bug-gnu-emacs@gnu.org Subject: 24.3.50; Segfault at mark_object Date: Wed, 02 Apr 2014 09:44:03 +0200 Message-ID: <871txgqipo.fsf@yahoo.fr> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -5.0 (-----) This happened while I was away. Program received signal SIGSEGV, Segmentation fault. mark_object (arg=194) at alloc.c:6127 6127 if (ptr->gcmarkbit) #0 mark_object (arg=194) at alloc.c:6127 #1 0x081b2a14 in mark_vectorlike (ptr=0xb9b0db0) at alloc.c:5785 #2 0x081b30df in mark_object (arg=194710965) at alloc.c:6117 #3 0x081b3116 in mark_object (arg=188747058) at alloc.c:6131 #4 0x081b1434 in mark_maybe_pointer (p=0xb400d30) at alloc.c:4563 #5 0x081b1484 in mark_memory (start=0xbfffd08c, end=0xbfffebdc) at alloc.c:4638 #6 0x081b14d1 in mark_stack () at alloc.c:4872 #7 0x081b231c in Fgarbage_collect () at alloc.c:5545 #8 0x0814bbb6 in maybe_gc () at lisp.h:4518 #9 0x081cdd73 in Ffuncall (nargs=2, args=0xbfffd2d0) at eval.c:2766 #10 0x081cbb68 in internal_condition_case_n (bfun=0x81cdcbb , nargs=2, args=0xbfffd2d0, handlers=139298778, hfun=0x8073814 ) at eval.c:1436 #11 0x0807392c in safe_call (nargs=2, func=141642493) at xdisp.c:2609 #12 0x08073969 in safe_call1 (fn=141642493, arg=139298754) at xdisp.c:2625 #13 0x080875a8 in prepare_menu_bars () at xdisp.c:11512 #14 0x0808ab42 in redisplay_internal () at xdisp.c:13403 #15 0x08089e98 in redisplay () at xdisp.c:13022 #16 0x08153013 in read_char (commandflag=1, map=218382190, prev_event=139298754, used_mouse_menu=0xbfffe8a3, end_time=0x0) at keyboard.c:2567 #17 0x0815d730 in read_key_sequence (keybuf=0xbfffe9c0, bufsize=30, prompt=139298754, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9079 #18 0x08151016 in command_loop_1 () at keyboard.c:1449 #19 0x081cb7e6 in internal_condition_case (bfun=0x8150cd3 , handlers=139331834, hfun=0x81506a9 ) at eval.c:1354 #20 0x08150a6f in command_loop_2 (ignore=139298754) at keyboard.c:1174 #21 0x081cb16e in internal_catch (tag=139329882, func=0x8150a4b , arg=139298754) at eval.c:1118 #22 0x08150a29 in command_loop () at keyboard.c:1153 #23 0x08150345 in recursive_edit_1 () at keyboard.c:777 #24 0x08150481 in Frecursive_edit () at keyboard.c:845 #25 0x0814e8b1 in main (argc=2, argv=0xbfffecd4) at emacs.c:1646 Lisp Backtrace: "Automatic GC" (0x84c678c) 0x8714af8 PVEC_COMPILED "redisplay_internal (C function)" (0x84c678c) #0 mark_object (arg=194) at alloc.c:6127 ptr = 0xc0 ptrx = 0xbfffcea8 obj = 192 cdr_count = 0 #1 0x081b2a14 in mark_vectorlike (ptr=0xb9b0db0) at alloc.c:5785 size = 36 i = 14 #2 0x081b30df in mark_object (arg=194710965) at alloc.c:6117 ptr = 0xb9b0db0 pvectype = 0 obj = 194710960 cdr_count = 0 #3 0x081b3116 in mark_object (arg=188747058) at alloc.c:6131 ptr = 0xb400d30 ptrx = 0x12 obj = 188747056 cdr_count = 0 #4 0x081b1434 in mark_maybe_pointer (p=0xb400d30) at alloc.c:4563 obj = 188747058 m = 0xb709250 #5 0x081b1484 in mark_memory (start=0xbfffd08c, end=0xbfffebdc) at alloc.c:4638 p = 0xb400d30 pp = 0xbfffde90 i = 0 #6 0x081b14d1 in mark_stack () at alloc.c:4872 end = 0xbfffd08c #7 0x081b231c in Fgarbage_collect () at alloc.c:5545 nextb = 0x0 stack_top_variable = 0 '\000' i = 1617 message_p = true count = 7 start = { tv_sec = 1396375514, tv_nsec = 188980653 } retval = 139298754 tot_before = 0 #8 0x0814bbb6 in maybe_gc () at lisp.h:4518 No locals. #9 0x081cdd73 in Ffuncall (nargs=2, args=0xbfffd2d0) at eval.c:2766 fun = 139319504 original_fun = 139319297 funcar = 0 numargs = 1 lisp_numargs = -1073753480 val = 138917188 internal_args = 0x0 i = 5 #10 0x081cbb68 in internal_condition_case_n (bfun=0x81cdcbb , nargs=2, args=0xbfffd2d0, handlers=139298778, hfun=0x8073814 ) at eval.c:1436 val = 139352440 c = 0x84e6500 #11 0x0807392c in safe_call (nargs=2, func=141642493) at xdisp.c:2609 i = 2 count = 5 gcpro1 = { next = 0x8714afd, var = 0xffd340, nvars = 2 } ap = 0xbfffd33c "H\323\377\277\005\262\024\bH\230U\b\310\323\377\277\250u\b\b\375Jq\b\302\207M\b\320\330M\b" args = 0xbfffd2d0 val = 136011655 #12 0x08073969 in safe_call1 (fn=141642493, arg=139298754) at xdisp.c:2625 No locals. #13 0x080875a8 in prepare_menu_bars () at xdisp.c:11512 windows = 139298754 all_windows = false some_windows = true gcpro1 = { next = 0xa0e9c28, var = 0x1, nvars = 1 } gcpro2 = { next = 0x0, var = 0xbfffd378, nvars = 134576184 } tooltip_frame = 139298754 #14 0x0808ab42 in redisplay_internal () at xdisp.c:13403 w = 0xb75b720 sw = 0xb75b720 fr = 0x84e46d0 pending = 0 must_finish = false match_p = false tlbufpos = { charpos = 136133708, bytepos = 139298754 } tlendpos = { charpos = 141207980, bytepos = -1073748696 } number_of_visible_frames = 1 count = 2 sf = 0x84e46d0 polling_stopped_here = 0 tail = 139298754 frame = 139347669 consider_all_windows_p = 8 update_miniwindow_p = false #15 0x08089e98 in redisplay () at xdisp.c:13022 No locals. #16 0x08153013 in read_char (commandflag=1, map=218382190, prev_event=139298754, used_mouse_menu=0xbfffe8a3, end_time=0x0) at keyboard.c:2567 echo_current = false c = 139298754 jmpcount = -1073748040 local_getcjmp = {{ __jmpbuf = {-1073748232, 136044005, 139319504, 0, -1073748264, 136011529}, __mask_was_saved = 141081056, __saved_mask = { __val = {141081056, 3221219032, 136133786, 139298754, 139319504, 141081056, 141431720, 139360971, 0, 3221219128, 135679500, 141431722, 139298778, 3221218816, 4294967295, 192, 0, 139298754, 3221219080, 135571235, 218382182, 3221219128, 135982083, 218382182, 218382174, 141431722, 141503502, 139298754, 139298754, 2, 139298754, 222500864} } }} save_jump = {{ __jmpbuf = {56, 139360971, 162623043, 169126963, 177160939, 206411387}, __mask_was_saved = 216942387, __saved_mask = { __val = {3067047979, 3068297204, 3068298304, 0, 28, 3067056153, 198911504, 178059944, 28, 4, 211656168, 3221214072, 3221218920, 135574114, 139319504, 6, 3067056073, 0, 0, 139319504, 3221218952, 135574114, 139319504, 6, 3221218984, 136011027, 139319509, 139319504, 3221218968, 135574303, 139319509, 139321778} } }} tem = 139298754 save = 142664326 previous_echo_area_message = 139298754 also_record = 139298754 reread = false gcpro1 = { next = 0x84de1b2, var = 0xbfffe6f8, nvars = 136044861 } gcpro2 = { next = 0x2fc, var = 0x1000006, nvars = 0 } polling_stopped_here = false orig_kboard = 0x889e340 #17 0x0815d730 in read_key_sequence (keybuf=0xbfffe9c0, bufsize=30, prompt=139298754, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9079 interrupted_kboard = 0x889e340 interrupted_frame = 0x84e46d0 key = 139319509 used_mouse_menu = false echo_local_start = 0 last_real_key_start = 0 keys_local_start = 0 new_binding = 139347669 count = 2 t = 0 echo_start = 0 keys_start = 0 current_binding = 218382190 first_event = 139298754 first_unbound = 31 mock_input = 0 fkey = { parent = 140966150, map = 140966150, start = 0, end = 0 } keytran = { parent = 139286286, map = 139286286, start = 0, end = 0 } indec = { parent = 140966158, map = 140966158, start = 0, end = 0 } shift_translated = false delayed_switch_frame = 139298754 original_uppercase = 134622171 original_uppercase_position = -1 dummyflag = false starting_buffer = 0x84dd8d0 fake_prefixed_keys = 139298754 gcpro1 = { next = 0x84d87c2, var = 0xbfffe8c8, nvars = 136011655 } #18 0x08151016 in command_loop_1 () at keyboard.c:1449 cmd = 141463658 keybuf = {96, 12, 137180145, 139298754, 139370802, 139298754, 4, 139298754, 141445706, 0, -1073747448, 135596160, 139329858, 210791238, 137180145, 139298754, 197184288, 0, -1073747352, 135595989, 210791238, -1073747409, -1073747384, 136104088, 2, 193733073, -1227911223, 0, 1919251558, 1797271584} i = 2 prev_modiff = 11 prev_buffer = 0x84dd8d0 already_adjusted = false #19 0x081cb7e6 in internal_condition_case (bfun=0x8150cd3 , handlers=139331834, hfun=0x81506a9 ) at eval.c:1354 val = 193733073 c = 0x84e6428 #20 0x08150a6f in command_loop_2 (ignore=139298754) at keyboard.c:1174 val = 0 #21 0x081cb16e in internal_catch (tag=139329882, func=0x8150a4b , arg=139298754) at eval.c:1118 val = 139298754 c = 0x88a0570 #22 0x08150a29 in command_loop () at keyboard.c:1153 No locals. #23 0x08150345 in recursive_edit_1 () at keyboard.c:777 count = 1 val = -1073747128 #24 0x08150481 in Frecursive_edit () at keyboard.c:845 count = 0 buffer = 139298754 #25 0x0814e8b1 in main (argc=2, argv=0xbfffecd4) at emacs.c:1646 dummy = 2 stack_bottom_variable = 0 '\000' do_initial_setlocale = true dumping = false skip_args = 1 rlim = { rlim_cur = 8388608, rlim_max = 18446744073709551615 } no_loadup = false junk = 0x0 dname_arg = 0x0 ch_to_dir = 0x0 original_pwd = 0x0 Lisp Backtrace: "Automatic GC" (0x84c678c) 0x8714af8 PVEC_COMPILED "redisplay_internal (C function)" (0x84c678c) #0 mark_object (arg=194) at alloc.c:6127 #1 0x081b2a14 in mark_vectorlike (ptr=0xb9b0db0) at alloc.c:5785 #2 0x081b30df in mark_object (arg=194710965) at alloc.c:6117 #3 0x081b3116 in mark_object (arg=188747058) at alloc.c:6131 #4 0x081b1434 in mark_maybe_pointer (p=0xb400d30) at alloc.c:4563 #5 0x081b1484 in mark_memory (start=0xbfffd08c, end=0xbfffebdc) at alloc.c:4638 #6 0x081b14d1 in mark_stack () at alloc.c:4872 #7 0x081b231c in Fgarbage_collect () at alloc.c:5545 #8 0x0814bbb6 in maybe_gc () at lisp.h:4518 #9 0x081cdd73 in Ffuncall (nargs=2, args=0xbfffd2d0) at eval.c:2766 #10 0x081cbb68 in internal_condition_case_n (bfun=0x81cdcbb , nargs=2, args=0xbfffd2d0, handlers=139298778, hfun=0x8073814 ) at eval.c:1436 #11 0x0807392c in safe_call (nargs=2, func=141642493) at xdisp.c:2609 #12 0x08073969 in safe_call1 (fn=141642493, arg=139298754) at xdisp.c:2625 #13 0x080875a8 in prepare_menu_bars () at xdisp.c:11512 #14 0x0808ab42 in redisplay_internal () at xdisp.c:13403 #15 0x08089e98 in redisplay () at xdisp.c:13022 #16 0x08153013 in read_char (commandflag=1, map=218382190, prev_event=139298754, used_mouse_menu=0xbfffe8a3, end_time=0x0) at keyboard.c:2567 #17 0x0815d730 in read_key_sequence (keybuf=0xbfffe9c0, bufsize=30, prompt=139298754, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9079 #18 0x08151016 in command_loop_1 () at keyboard.c:1449 #19 0x081cb7e6 in internal_condition_case (bfun=0x8150cd3 , handlers=139331834, hfun=0x81506a9 ) at eval.c:1354 #20 0x08150a6f in command_loop_2 (ignore=139298754) at keyboard.c:1174 #21 0x081cb16e in internal_catch (tag=139329882, func=0x8150a4b , arg=139298754) at eval.c:1118 #22 0x08150a29 in command_loop () at keyboard.c:1153 #23 0x08150345 in recursive_edit_1 () at keyboard.c:777 #24 0x08150481 in Frecursive_edit () at keyboard.c:845 #25 0x0814e8b1 in main (argc=2, argv=0xbfffecd4) at emacs.c:1646 Lisp Backtrace: "Automatic GC" (0x84c678c) 0x8714af8 PVEC_COMPILED "redisplay_internal (C function)" (0x84c678c) In GNU Emacs 24.3.50.7 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2014-03-27 on geodiff-mac3 Windowing system distributor `The X.Org Foundation', version 11.0.11304000 System Description: Gentoo Base System release 2.2 Configured using: `configure --with-x-toolkit=lucid 'CFLAGS= -O0 -g3'' Important settings: value of $LANG: fr_FR.UTF-8 locale-coding-system: utf-8-unix -- Nico. ------------=_1396896071-4175-15-- From unknown Sat Jun 21 12:19:20 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Nicolas Richard Subject: bug#17184: closed (Re: bug#17168: 24.3.50; Segfault at mark_object) Message-ID: References: <8738htf74j.fsf@yahoo.fr> X-Gnu-PR-Message: they-closed 17184 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: moreinfo Reply-To: 17184@debbugs.gnu.org Date: Mon, 07 Apr 2014 18:41:12 +0000 Content-Type: multipart/mixed; boundary="----------=_1396896072-4175-17" This is a multi-part message in MIME format... ------------=_1396896072-4175-17 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #17168: 24.3.50; crash while bootstrapping current trunk which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 17184@debbugs.gnu.org. --=20 17168: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D17168 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1396896072-4175-17 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 17168-done) by debbugs.gnu.org; 7 Apr 2014 18:40:39 +0000 Received: from localhost ([127.0.0.1]:39853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXETF-00014T-3h for submit@debbugs.gnu.org; Mon, 07 Apr 2014 14:40:38 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:41342) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXET9-00014I-VI for 17168-done@debbugs.gnu.org; Mon, 07 Apr 2014 14:40:32 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s37IeP88031961; Mon, 7 Apr 2014 14:40:26 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 0E765661DF; Mon, 7 Apr 2014 12:28:20 -0400 (EDT) From: Stefan Monnier To: Daniel Colascione Subject: Re: bug#17168: 24.3.50; Segfault at mark_object Message-ID: References: <87y4zop44m.fsf@yahoo.fr> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <534176F3.9090205@dancol.org> <5341B573.1010605@dancol.org> <5341C928.6040308@dancol.org> Date: Mon, 07 Apr 2014 12:28:20 -0400 In-Reply-To: <5341C928.6040308@dancol.org> (Daniel Colascione's message of "Sun, 06 Apr 2014 14:37:44 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4905=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4905> : inlines <695> : streams <1153548> : uri <1723188> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 17168-done Cc: Dmitry Antipov , 17168-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -1.6 (-) > Anyway, I'd like to get a fix into emacs-24 soon so we can make sure > we've fixed the GC bug. I installed a fix into emacs-24, which lets all symbols be uninterned. > Are you vetoing the general approach used in this patch? No: I think disallowing unintern is a good idea, but not for emacs-24. Indeed, as it turns out, the only non-pure objects referenced from pure space are symbols and distinguishing uninterned from interned reduces the number of such "pinned" objects from about 10K to about 250. Rather than scan all symbols to find the pinned ones, the code I installed into emacs-24 keeps a pointer to the first symbol_block that contains a pinned symbol. This way we only scan about 15K symbols at the beginning of every GC cycle to mark those 10K pinned symbols. Compared to keeping a vector of 10K object, this seems like a good tradeoff. For trunk, we could disallow uninterning pinned symbols, at which point it's worth the trouble to build a vector of those 250 remaining pinned symbols. Stefan ------------=_1396896072-4175-17 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 4 Apr 2014 15:26:41 +0000 Received: from localhost ([127.0.0.1]:35556 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WW60t-0003pC-S1 for submit@debbugs.gnu.org; Fri, 04 Apr 2014 11:26:40 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49159) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WW60r-0003p4-Fo for submit@debbugs.gnu.org; Fri, 04 Apr 2014 11:26:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WW60j-00021T-Ta for submit@debbugs.gnu.org; Fri, 04 Apr 2014 11:26:37 -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,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:42058) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WW60j-00021P-RO for submit@debbugs.gnu.org; Fri, 04 Apr 2014 11:26:29 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50755) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WW60d-0000KB-Ax for bug-gnu-emacs@gnu.org; Fri, 04 Apr 2014 11:26:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WW60T-0001rx-Jy for bug-gnu-emacs@gnu.org; Fri, 04 Apr 2014 11:26:23 -0400 Received: from mxin.ulb.ac.be ([164.15.128.112]:27296) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WW60T-0001rh-71 for bug-gnu-emacs@gnu.org; Fri, 04 Apr 2014 11:26:13 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIOAJ/HPlOkD4Xx/2dsb2JhbABXg0GDYadNAQMMgliYA3SCJQEBBCRbEwEcAgUhAhEBiEQBDAiQWIx8jxxRmiIBiBOBKYY/iX+BSQSOXYl+hjqMBYMyOw Received: from mathsrv4.ulb.ac.be (HELO geodiff-mac3) ([164.15.133.241]) by smtp.ulb.ac.be with ESMTP; 04 Apr 2014 17:26:12 +0200 From: Nicolas Richard To: bug-gnu-emacs@gnu.org Subject: 24.3.50; crash while bootstrapping current trunk Date: Fri, 04 Apr 2014 17:26:36 +0200 Message-ID: <8738htf74j.fsf@yahoo.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -5.0 (-----) I tried making trunk and it crashes while bootstrapping. I guess it's "normal" (because of bug#17168 and bug#17178) so please feel free to close it. It crashes while byte compiling lisp/tcover-ses.el: > Wrote /home/youngfrog/sources/emacs-from-git/lisp/emacs-lisp/subr-x.elc > Compiling emacs-lisp/tcover-ses.el >=20 > Backtrace: > ../src/emacs[0x816ba30] > ../src/emacs[0x814d236] > ../src/emacs[0x816baaf] > ../src/emacs[0x81b58cf] > ../src/emacs[0x81b5a0e] > ../src/emacs[0x81ce514] > ../src/emacs[0x8205ad9] > ../src/emacs[0x82051e0] > ../src/emacs[0x81cd435] > ../src/emacs[0x81f1f25] > ../src/emacs[0x81f0f13] > ../src/emacs[0x81d6ede] > ../src/emacs[0x81cd435] > ../src/emacs[0x81f1f25] > ../src/emacs[0x81f219d] > ../src/emacs[0x81ce591] > ../src/emacs[0x8205ad9] > ../src/emacs[0x81cee0c] > ../src/emacs[0x81ce6f3] > ../src/emacs[0x81ce0a2] > ../src/emacs[0x81f0cf2] > ../src/emacs[0x81d6ede] > ../src/emacs[0x81ce514] > ../src/emacs[0x81cd87d] > ../src/emacs[0x81ce3b3] > ../src/emacs[0x8205ad9] > ../src/emacs[0x81ceb55] > ../src/emacs[0x81ce6f3] > ../src/emacs[0x8205ad9] > ../src/emacs[0x81ceb55] > ../src/emacs[0x81ce6f3] > ../src/emacs[0x8205ad9] > ../src/emacs[0x81ceb55] > ../src/emacs[0x81ce6f3] > ../src/emacs[0x8205ad9] > ../src/emacs[0x81ceb55] > ../src/emacs[0x81ce6f3] > ../src/emacs[0x8205ad9] > ../src/emacs[0x81ceb55] > ../src/emacs[0x81ce6f3] > ../src/emacs[0x81cd2d7] > ... > make[3]: *** [emacs-lisp/tcover-ses.elc] Abandon (core dump cr=C3=A9=C3= =A9) > make[3] : on quitte le r=C3=A9pertoire =C2=AB /home/youngfrog/sources/ema= cs-from-git/lisp =C2=BB So I tried this: $ gdb --args emacs --batch -f batch-byte-compile ../lisp/emacs-lisp/tcover= -ses.el and here's what happens: Breakpoint 1, terminate_due_to_signal (sig=3D6, backtrace_limit=3D40) at em= acs.c:355 355 signal (sig, SIG_DFL); it aborts because of this in data.c: /* Convert to eassert or remove after GC bug is found. In the meantime, check unconditionally, at a slight perf hit. */ if (valid_lisp_object_p (definition) < 1) emacs_abort (); Here's the backtrace: (gdb) bt #0 terminate_due_to_signal (sig=3D6, backtrace_limit=3D40) at emacs.c:355 #1 0x0816baaf in emacs_abort () at sysdep.c:2130 #2 0x081b58cf in Ffset (symbol=3D144231458, definition=3D137959093) at dat= a.c:733 #3 0x081b5a0e in Fdefalias (symbol=3D144231458, definition=3D137959093, do= cstring=3D139331522) at data.c:777 #4 0x081ce514 in Ffuncall (nargs=3D3, args=3D0xbfffac84) at eval.c:2822 #5 0x08205ad9 in exec_byte_code (bytestr=3D144102825, vector=3D142800693, = maxdepth=3D12, args_template=3D139331522, nargs=3D0, args=3D0x0) at bytecod= e.c:919 #6 0x082051e0 in Fbyte_code (bytestr=3D144102825, vector=3D142800693, maxd= epth=3D12) at bytecode.c:482 #7 0x081cd435 in eval_sub (form=3D144101550) at eval.c:2191 #8 0x081f1f25 in readevalloop (readcharfun=3D139400210, stream=3D0x8946b18= , sourcename=3D143974441, printflag=3Dfalse, unibyte=3D139331522, readfun= =3D139331522, start=3D139331522, end=3D139331522) at lread.c:1934 #9 0x081f0f13 in Fload (file=3D137504521, noerror=3D139331522, nomessage= =3D139331546, nosuffix=3D139331522, must_suffix=3D139331546) at lread.c:1363 #10 0x081d6ede in Frequire (feature=3D143167186, filename=3D139331522, noer= ror=3D139331522) at fns.c:2671 #11 0x081cd435 in eval_sub (form=3D142889614) at eval.c:2191 #12 0x081f1f25 in readevalloop (readcharfun=3D143919141, stream=3D0x0, sour= cename=3D143946105, printflag=3Dfalse, unibyte=3D139331522, readfun=3D13933= 1522, start=3D139331522, end=3D139331522) at lread.c:1934 #13 0x081f219d in Feval_buffer (buffer=3D143919141, printflag=3D139331522, = filename=3D143909873, unibyte=3D139331522, do_allow_print=3D139331546) at l= read.c:1995 #14 0x081ce591 in Ffuncall (nargs=3D6, args=3D0xbfffb474) at eval.c:2831 #15 0x08205ad9 in exec_byte_code (bytestr=3D137274913, vector=3D137274933, = maxdepth=3D24, args_template=3D139331522, nargs=3D0, args=3D0x0) at bytecod= e.c:919 #16 0x081cee0c in funcall_lambda (fun=3D137274853, nargs=3D4, arg_vector=3D= 0x82ea635 ) at eval.c:3049 #17 0x081ce6f3 in Ffuncall (nargs=3D5, args=3D0xbfffb7ac) at eval.c:2864 #18 0x081ce0a2 in call4 (fn=3D141003746, arg1=3D143909873, arg2=3D143909873= , arg3=3D139331522, arg4=3D139331546) at eval.c:2663 #19 0x081f0cf2 in Fload (file=3D143904913, noerror=3D139331522, nomessage= =3D139331546, nosuffix=3D139331522, must_suffix=3D139331546) at lread.c:1305 #20 0x081d6ede in Frequire (feature=3D143907898, filename=3D139331522, noer= ror=3D139331522) at fns.c:2671 #21 0x081ce514 in Ffuncall (nargs=3D2, args=3D0xbfffbba8) at eval.c:2822 #22 0x081cd87d in Fapply (nargs=3D2, args=3D0xbfffbba8) at eval.c:2301 #23 0x081ce3b3 in Ffuncall (nargs=3D3, args=3D0xbfffbba4) at eval.c:2796 #24 0x08205ad9 in exec_byte_code (bytestr=3D143527569, vector=3D142390349, = maxdepth=3D28, args_template=3D1028, nargs=3D1, args=3D0xbfffbed4) at bytec= ode.c:919 #25 0x081ceb55 in funcall_lambda (fun=3D142390421, nargs=3D1, arg_vector=3D= 0xbfffbed0) at eval.c:2983 #26 0x081ce6f3 in Ffuncall (nargs=3D2, args=3D0xbfffbecc) at eval.c:2864 #27 0x08205ad9 in exec_byte_code (bytestr=3D143526009, vector=3D142386277, = maxdepth=3D16, args_template=3D1028, nargs=3D1, args=3D0xbfffc200) at bytec= ode.c:919 #28 0x081ceb55 in funcall_lambda (fun=3D142386301, nargs=3D1, arg_vector=3D= 0xbfffc1fc) at eval.c:2983 #29 0x081ce6f3 in Ffuncall (nargs=3D2, args=3D0xbfffc1f8) at eval.c:2864 #30 0x08205ad9 in exec_byte_code (bytestr=3D143524777, vector=3D142386229, = maxdepth=3D20, args_template=3D1028, nargs=3D1, args=3D0xbfffc530) at bytec= ode.c:919 #31 0x081ceb55 in funcall_lambda (fun=3D142386253, nargs=3D1, arg_vector=3D= 0xbfffc52c) at eval.c:2983 #32 0x081ce6f3 in Ffuncall (nargs=3D2, args=3D0xbfffc528) at eval.c:2864 #33 0x08205ad9 in exec_byte_code (bytestr=3D143512849, vector=3D142949461, = maxdepth=3D16, args_template=3D0, nargs=3D0, args=3D0xbfffc858) at bytecode= .c:919 #34 0x081ceb55 in funcall_lambda (fun=3D142949549, nargs=3D0, arg_vector=3D= 0xbfffc858) at eval.c:2983 #35 0x081ce6f3 in Ffuncall (nargs=3D1, args=3D0xbfffc854) at eval.c:2864 #36 0x08205ad9 in exec_byte_code (bytestr=3D143513329, vector=3D141028941, = maxdepth=3D4, args_template=3D0, nargs=3D0, args=3D0xbfffcb84) at bytecode.= c:919 #37 0x081ceb55 in funcall_lambda (fun=3D142949573, nargs=3D0, arg_vector=3D= 0xbfffcb84) at eval.c:2983 #38 0x081ce6f3 in Ffuncall (nargs=3D1, args=3D0xbfffcb80) at eval.c:2864 #39 0x081cd2d7 in eval_sub (form=3D142890566) at eval.c:2157 #40 0x081cbbd4 in internal_lisp_condition_case (var=3D143495690, bodyform= =3D142890566, handlers=3D142890614) at eval.c:1323 #41 0x08206a1b in exec_byte_code (bytestr=3D143512577, vector=3D142345157, = maxdepth=3D64, args_template=3D1028, nargs=3D1, args=3D0xbfffd08c) at bytec= ode.c:1169 #42 0x081ceb55 in funcall_lambda (fun=3D142558517, nargs=3D1, arg_vector=3D= 0xbfffd088) at eval.c:2983 #43 0x081ce6f3 in Ffuncall (nargs=3D2, args=3D0xbfffd084) at eval.c:2864 #44 0x08205ad9 in exec_byte_code (bytestr=3D143509785, vector=3D142287813, = maxdepth=3D68, args_template=3D2052, nargs=3D1, args=3D0xbfffd3cc) at bytec= ode.c:919 #45 0x081ceb55 in funcall_lambda (fun=3D142554317, nargs=3D1, arg_vector=3D= 0xbfffd3c8) at eval.c:2983 #46 0x081ce6f3 in Ffuncall (nargs=3D2, args=3D0xbfffd3c4) at eval.c:2864 #47 0x08205ad9 in exec_byte_code (bytestr=3D143628761, vector=3D142937357, = maxdepth=3D8, args_template=3D0, nargs=3D0, args=3D0xbfffd6f4) at bytecode.= c:919 #48 0x081ceb55 in funcall_lambda (fun=3D142937373, nargs=3D0, arg_vector=3D= 0xbfffd6f4) at eval.c:2983 #49 0x081ce6f3 in Ffuncall (nargs=3D1, args=3D0xbfffd6f0) at eval.c:2864 #50 0x081cd2d7 in eval_sub (form=3D142898206) at eval.c:2157 #51 0x081cbbd4 in internal_lisp_condition_case (var=3D143603770, bodyform= =3D142898206, handlers=3D142902174) at eval.c:1323 #52 0x08206a1b in exec_byte_code (bytestr=3D143628633, vector=3D142933037, = maxdepth=3D48, args_template=3D1028, nargs=3D1, args=3D0xbfffdbd4) at bytec= ode.c:1169 #53 0x081ceb55 in funcall_lambda (fun=3D142933133, nargs=3D1, arg_vector=3D= 0xbfffdbd0) at eval.c:2983 #54 0x081ce6f3 in Ffuncall (nargs=3D2, args=3D0xbfffdbcc) at eval.c:2864 #55 0x08205ad9 in exec_byte_code (bytestr=3D143628313, vector=3D142925061, = maxdepth=3D40, args_template=3D1024, nargs=3D0, args=3D0xbfffdf40) at bytec= ode.c:919 #56 0x081ceb55 in funcall_lambda (fun=3D142932941, nargs=3D0, arg_vector=3D= 0xbfffdf40) at eval.c:2983 #57 0x081ce6f3 in Ffuncall (nargs=3D1, args=3D0xbfffdf3c) at eval.c:2864 #58 0x08205ad9 in exec_byte_code (bytestr=3D137480961, vector=3D137480981, = maxdepth=3D92, args_template=3D1028, nargs=3D1, args=3D0xbfffe27c) at bytec= ode.c:919 #59 0x081ceb55 in funcall_lambda (fun=3D137480941, nargs=3D1, arg_vector=3D= 0xbfffe278) at eval.c:2983 #60 0x081ce6f3 in Ffuncall (nargs=3D2, args=3D0xbfffe274) at eval.c:2864 #61 0x08205ad9 in exec_byte_code (bytestr=3D137468033, vector=3D137468053, = maxdepth=3D68, args_template=3D0, nargs=3D0, args=3D0xbfffe5dc) at bytecode= .c:919 #62 0x081ceb55 in funcall_lambda (fun=3D137468013, nargs=3D0, arg_vector=3D= 0xbfffe5dc) at eval.c:2983 #63 0x081ce6f3 in Ffuncall (nargs=3D1, args=3D0xbfffe5d8) at eval.c:2864 #64 0x08205ad9 in exec_byte_code (bytestr=3D137466281, vector=3D137466301, = maxdepth=3D48, args_template=3D0, nargs=3D0, args=3D0xbfffe890) at bytecode= .c:919 #65 0x081ceb55 in funcall_lambda (fun=3D137466261, nargs=3D0, arg_vector=3D= 0xbfffe890) at eval.c:2983 #66 0x081ce97c in apply_lambda (fun=3D137466261, args=3D139331522) at eval.= c:2924 #67 0x081cd63c in eval_sub (form=3D140992662) at eval.c:2230 #68 0x081ccd91 in Feval (form=3D140992662, lexical=3D139331522) at eval.c:2= 003 #69 0x08150d62 in top_level_2 () at keyboard.c:1183 #70 0x081cbcee in internal_condition_case (bfun=3D0x8150d45 , = handlers=3D139364602, hfun=3D0x8150969 ) at eval.c:1354 #71 0x08150d96 in top_level_1 (ignore=3D139331522) at keyboard.c:1191 #72 0x081cb676 in internal_catch (tag=3D139362650, func=3D0x8150d64 , arg=3D139331522) at eval.c:1118 #73 0x08150cca in command_loop () at keyboard.c:1152 #74 0x08150605 in recursive_edit_1 () at keyboard.c:777 #75 0x08150741 in Frecursive_edit () at keyboard.c:845 #76 0x0814eaff in main (argc=3D5, argv=3D0xbfffec94) at emacs.c:1654 Lisp Backtrace: "defalias" (0xbfffac88) "byte-code" (0xbfffaf10) "require" (0xbfffb270) "eval-buffer" (0xbfffb478) "load-with-code-conversion" (0xbfffb7b0) "require" (0xbfffbbac) "apply" (0xbfffbba8) "byte-compile-file-form-require" (0xbfffbed0) "byte-compile-file-form" (0xbfffc1fc) "byte-compile-toplevel-file-form" (0xbfffc52c) 0x8853ca8 PVEC_COMPILED 0x8853cc0 PVEC_COMPILED "funcall" (0xbfffcb80) "byte-compile-from-buffer" (0xbfffd088) "byte-compile-file" (0xbfffd3c8) 0x8850d18 PVEC_COMPILED "funcall" (0xbfffd6f0) "batch-byte-compile-file" (0xbfffdbd0) "batch-byte-compile" (0xbfffdf40) "command-line-1" (0xbfffe278) "command-line" (0xbfffe5dc) "normal-top-level" (0xbfffe890) (gdb) p definition No symbol "definition" in current context. (gdb) f 3 #3 0x081b5a0e in Fdefalias (symbol=3D144231458, definition=3D137959093, do= cstring=3D139331522) at data.c:777 777 Ffset (symbol, definition); (gdb) p definition $1 =3D 137959093 (gdb) x Argument required (starting display address). (gdb) x $1 0x83916b5 : 0xd1000004 (gdb)=20 In GNU Emacs 24.3.50.8 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2014-04-03 on geodiff-mac3 Windowing system distributor `The X.Org Foundation', version 11.0.11304000 System Description: Gentoo Base System release 2.2 Configured using: `configure --with-x-toolkit=3Dlucid 'CFLAGS=3D -O0 -g3'' Important settings: value of $LANG: fr_FR.UTF-8 locale-coding-system: utf-8-unix --=20 Nico. ------------=_1396896072-4175-17-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Apr 2014 19:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Stefan Monnier Cc: Dmitry Antipov , 17168-done@debbugs.gnu.org Received: via spool by 17168-done@debbugs.gnu.org id=D17168.13968976066889 (code D ref 17168); Mon, 07 Apr 2014 19:07:02 +0000 Received: (at 17168-done) by debbugs.gnu.org; 7 Apr 2014 19:06:46 +0000 Received: from localhost ([127.0.0.1]:39894 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXEsX-0001n2-Ly for submit@debbugs.gnu.org; Mon, 07 Apr 2014 15:06:46 -0400 Received: from dancol.org ([96.126.100.184]:52359) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXEsT-0001ms-Ku for 17168-done@debbugs.gnu.org; Mon, 07 Apr 2014 15:06:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=dI+MbGOv7fam/GuDJJkRzfc0MC0pL256M6nLj2DwJsA=; b=IvjP8dALxcfnYUs8ESxzbzLRLhEwYXOtTRvMbf06Yq0R71+FA5PJAr0mweFHRjVE8pRGyVWuhWG4pJMZ6Ekp15cQkvrn5juOMRC0yY3tvYZ5iLemcYc+38x1ye5rJLBvZHuhlVMhAF4pIYl5KLB8sdLqDKe3Qy2VOvmESdnWrmJOmX7PVJ7q5KzWwalfqraSae35dvTZWz5ovfJIPheLhop5jGsevBhMp78SS6ThHuYWB4/ftsvFAsyR2JIsoruCfeJwHWyEVhlcCPJHuvkR+38YBfoSAOj+rK/aXi4R6quas1ZJ32G4LGBi4G1btSLAwfGJLaSSQNWLAKoOi7QXpg==; Received: from [2601:8:b200:551::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WXEsR-0004c9-38; Mon, 07 Apr 2014 12:06:39 -0700 Message-ID: <5342F73C.5020404@dancol.org> Date: Mon, 07 Apr 2014 12:06:36 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <534176F3.9090205@dancol.org> <5341B573.1010605@dancol.org> <5341C928.6040308@dancol.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q0IkkJ69NLfSn9vgIJfxuQcLPKwUpNa7w" X-Spam-Score: -0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.3 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Q0IkkJ69NLfSn9vgIJfxuQcLPKwUpNa7w Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/07/2014 09:28 AM, Stefan Monnier wrote: >> Anyway, I'd like to get a fix into emacs-24 soon so we can make sure >> we've fixed the GC bug. >=20 > I installed a fix into emacs-24, which lets all symbols be uninterned. >=20 >> Are you vetoing the general approach used in this patch? >=20 > No: I think disallowing unintern is a good idea, but not for emacs-24. Thanks. I'll install my change in trunk. How should we prevent your change merging into trunk? > Indeed, as it turns out, the only non-pure objects referenced from pure= > space are symbols and distinguishing uninterned from interned reduces > the number of such "pinned" objects from about 10K to about 250. >=20 > Rather than scan all symbols to find the pinned ones, the code > I installed into emacs-24 keeps a pointer to the first symbol_block > that contains a pinned symbol. This way we only scan about 15K symbols= > at the beginning of every GC cycle to mark those 10K pinned symbols. > Compared to keeping a vector of 10K object, this seems like > a good tradeoff. It's unfortunate that we still have to mark Vobarray even though we're separately marking most of the symbols it contains, but I suppose it doesn't matter all that much: because we've already marked most of the symbols in the interned symbol chains, we'll short-circuit in mark_object anyway. --Q0IkkJ69NLfSn9vgIJfxuQcLPKwUpNa7w Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTQvc8AAoJEMAaIROpHW7I8NoQAJ+elsXYeG1NlJIoULy1lVbu uQKmbi7Csmz5jSsrZZBWNqtvPKN6qmpD62TB2GU5hEf18+yWkaFnj3IDpUNsy7q5 VGzSTPCg5VQ6ruejWrGSwHdwuQscTz9wP4n64giVTHjUSaGJWCD+cIgrJeAsXaf3 po2W1sjvoa3I962M7LREZ3Ek6kQUh3UJHbtl2I6JM8bWW/2qL8wt93d8HjNjPoV+ 5N3zCVR3Vstj0NmUf5AiFvlYisQP1JnEWw/ziPFaKzPAiMpxT+vYOHKiBpObMWQl dOJbwJm3X61ci4kO+QQieQOg8D/6XZRUx/gF7FQHv2sNv8CNY7p7puMc6E0oVIAC s6t7Fn330klEuoAOw7UMo7z6MsFMyavDxAjNVP+0hS15PUm3OziXbG3AYoJ42HiV GtPc+c25rv6d0NOY8s7WNw10lCdHy7/0CDG9ZwRgkYzEvjnLoYZOeoD8VGHutXSm 6eqxCmutGDgcfuip3FUSTUtWXeI+VR2T0/cHXUNfIi1I09677P0WvwnBjeaqsIUl 0Z+mNAjRtljD1y8JmwLYjJiXPzbXiH81Z7DAQJe8VGHaAIslyXmG5wc0YeZwKveR n+Uh+beewg/yVhUGI5iih7CxH/d+T1Pq16uukwitfgKWcYxJv8GGOVaCCGXmD0Yg NjJ65rWByAAqg4D9+IN3 =2mA3 -----END PGP SIGNATURE----- --Q0IkkJ69NLfSn9vgIJfxuQcLPKwUpNa7w-- From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Apr 2014 21:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Daniel Colascione Cc: Dmitry Antipov , 17168-done@debbugs.gnu.org Received: via spool by 17168-done@debbugs.gnu.org id=D17168.139690599225091 (code D ref 17168); Mon, 07 Apr 2014 21:27:02 +0000 Received: (at 17168-done) by debbugs.gnu.org; 7 Apr 2014 21:26:32 +0000 Received: from localhost ([127.0.0.1]:39956 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXH3n-0006Wd-VM for submit@debbugs.gnu.org; Mon, 07 Apr 2014 17:26:32 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:56721) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXH3k-0006WS-Hh for 17168-done@debbugs.gnu.org; Mon, 07 Apr 2014 17:26:29 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s37LPjG8009834; Mon, 7 Apr 2014 17:25:49 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 115DD66106; Mon, 7 Apr 2014 16:42:40 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87y4zop44m.fsf@yahoo.fr> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <534176F3.9090205@dancol.org> <5341B573.1010605@dancol.org> <5341C928.6040308@dancol.org> <5342F73C.5020404@dancol.org> Date: Mon, 07 Apr 2014 16:42:40 -0400 In-Reply-To: <5342F73C.5020404@dancol.org> (Daniel Colascione's message of "Mon, 07 Apr 2014 12:06:36 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 2 Rules triggered GEN_SPAM_FEATRE=0.2, RV4905=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4905> : inlines <696> : streams <1153639> : uri <1723269> X-Spam-Score: -1.6 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -1.6 (-) > Thanks. I'll install my change in trunk. How should we prevent your > change merging into trunk? Don't prevent it. Merge it (or wait for someone else to do it) first and then install your change as a patch on top of it. Stefan From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Apr 2014 07:15:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Daniel Colascione , Stefan Monnier Cc: Dmitry Antipov , 17168-done@debbugs.gnu.org Received: via spool by 17168-done@debbugs.gnu.org id=D17168.139694126420388 (code D ref 17168); Tue, 08 Apr 2014 07:15:04 +0000 Received: (at 17168-done) by debbugs.gnu.org; 8 Apr 2014 07:14:24 +0000 Received: from localhost ([127.0.0.1]:40231 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXQEg-0005If-AV for submit@debbugs.gnu.org; Tue, 08 Apr 2014 03:14:22 -0400 Received: from mout.gmx.net ([212.227.17.20]:60992) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXQEc-0005IS-Tq for 17168-done@debbugs.gnu.org; Tue, 08 Apr 2014 03:14:19 -0400 Received: from [188.22.104.13] ([188.22.104.13]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MGSgq-1WkbWr1jQu-00DDLB; Tue, 08 Apr 2014 09:14:17 +0200 Message-ID: <5343A1C2.6080803@gmx.at> Date: Tue, 08 Apr 2014 09:14:10 +0200 From: martin rudalics MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <534176F3.9090205@dancol.org> <5341B573.1010605@dancol.org> <5341C928.6040308@dancol.org> <5342F73C.5020404@dancol.org> In-Reply-To: <5342F73C.5020404@dancol.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:rnrBcRtzCn8GN6+XyINytEmYbF4vDgUYbrA3QkrgxqVmwiMYlJM SVfywwrJ4i6wkhqMr4qpk1C9piQTcZPSfbLWnTHt3AjxnwxZuUx5WkmFqpU65zF1jmYYy2V zEdHK8BOGFcG8Q9/l7wjl3fkJM+sRs0cxUkMN5YEHBBs2+EIpOvrawSylHY3xeuRclqTd7+ G8ALqFGgDd0XKemHtOAMg== X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (/) > I'll install my change in trunk. Please wait at least a couple of weeks. Otherwise, Stefan's change will hardly receive any testing and we are going to release a version with a largely untested fix. martin From unknown Sat Jun 21 12:19:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17168: 24.3.50; Segfault at mark_object Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Apr 2014 08:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: martin rudalics , Stefan Monnier Cc: Dmitry Antipov , 17168-done@debbugs.gnu.org Received: via spool by 17168-done@debbugs.gnu.org id=D17168.139694685230064 (code D ref 17168); Tue, 08 Apr 2014 08:48:02 +0000 Received: (at 17168-done) by debbugs.gnu.org; 8 Apr 2014 08:47:32 +0000 Received: from localhost ([127.0.0.1]:40279 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXRgq-0007oq-7z for submit@debbugs.gnu.org; Tue, 08 Apr 2014 04:47:32 -0400 Received: from dancol.org ([96.126.100.184]:57184) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXRgn-0007oe-I0 for 17168-done@debbugs.gnu.org; Tue, 08 Apr 2014 04:47:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=QNSZA5pSCkxR0LE5sTeOXKnrzgKHJa1gfMs/h+SL/H8=; b=LGgDhVga6R8Sx0oRAv4fwOz2l3Z9PDY1GcHVm7D3xonnx2rE6VPdN/01LJJ+au6jFQ0ziPXdj+XbeU3LzYzbf+uiD+mVALRaxHtJhxraS+2Fj8kZrppGLfsqezFrBm2HZtGiIlFuv7uQoPyEGTFOBjkjIZze9hPiGCpTPqSegD50QiU/qBkO/6CFdxiRNbFADomRTbW/jcvrdc7Xh7hPmUfoHeAH9w1XCv0M9ZTx6PQUa40Lp6oW05j5wlNXim2mXueov+l9SY0MJrSl20ALgfaSSNVxQq+Ge7j1/NPQ8oavy5er0i9fu0xiwVEna2bubgxIaMSCC3P5VduWYxj3rw==; Received: from [2601:8:b200:551::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WXRgi-00084X-12; Tue, 08 Apr 2014 01:47:24 -0700 Message-ID: <5343B79A.1050809@dancol.org> Date: Tue, 08 Apr 2014 01:47:22 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <87y4zop44m.fsf@yahoo.fr> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <534176F3.9090205@dancol.org> <5341B573.1010605@dancol.org> <5341C928.6040308@dancol.org> <5342F73C.5020404@dancol.org> <5343A1C2.6080803@gmx.at> In-Reply-To: <5343A1C2.6080803@gmx.at> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="q9ulgiLnt5xxTupuFmjHTTFgxjatab1gF" X-Spam-Score: -0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.3 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --q9ulgiLnt5xxTupuFmjHTTFgxjatab1gF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/08/2014 12:14 AM, martin rudalics wrote: >> I'll install my change in trunk. >=20 > Please wait at least a couple of weeks. Otherwise, Stefan's change wil= l > hardly receive any testing and we are going to release a version with a= > largely untested fix. >=20 Good point. Sure. --q9ulgiLnt5xxTupuFmjHTTFgxjatab1gF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTQ7eaAAoJEMAaIROpHW7IWQoP/1a4aot8Cf4yQzNVzgQkq1+D YsUA2SSKqbWaef7TZZf4tx2lfStD8du1vpFEZO6AobuE6qztAmjSiKHA809VoG0P 1nakqPRPExfuSEjvImvLtgmeppoMaiBW3hxeycHYZQLfs59OqY7LVOwTOTN6AkTI 50nXX1KX4g0jttSRd721TvIREjpkb05w5cx5KhMJ9pPUEu+a+cxE668zGIHysc9A ZfBN5o00eg7c1jaS0uJxGJil/R2Dpm6wSWERr+5BjGvX2GtRd92xeWSvVI1PbjnF W8giLSAAicgE0Z0tU24PQzuiTwJ9D7393qIZrJe53P/YtuDsGfEXMjpgZtE164kb H3eEdJ6Jd8/cPN7qU+2sqF7MzYwxfISs6o7J+8gL7W5kpkXesh3T5Gupok7kXmv9 X8udDPwzn17/2kxudWZKJCs3LG8sOZibFjpv100H1fuefLKmspVK8tPtKf0KokUm McF8NAK0/KyKuhWSbMe4nmRvgIKQNib2V6h+Swi1JlZ7VT9fA0rMR/7oYY5lbUXl DJ1CJdfrAFy9cX5iS+qbBkO7ISQ7z+6ISkfoh/U2EaJ8e0x8eq1punhjWu71j5h7 5M812daDy4uhOivBdYnJvtXw8kEpWbnXKgwCmHwYE544PXuUssfguVjgI/h8H5Hl hIXo9JlsLQ0t3Kl9jXcY =q3RU -----END PGP SIGNATURE----- --q9ulgiLnt5xxTupuFmjHTTFgxjatab1gF--