From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 25 16:01:44 2019 Received: (at submit) by debbugs.gnu.org; 25 Feb 2019 21:01:44 +0000 Received: from localhost ([127.0.0.1]:51788 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyNNe-0004jY-Bz for submit@debbugs.gnu.org; Mon, 25 Feb 2019 16:01:44 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47692) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyNNb-0004j1-8V for submit@debbugs.gnu.org; Mon, 25 Feb 2019 16:01:41 -0500 Received: from lists.gnu.org ([209.51.188.17]:40900) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gyNNL-0004Ny-EL for submit@debbugs.gnu.org; Mon, 25 Feb 2019 16:01:26 -0500 Received: from eggs.gnu.org ([209.51.188.92]:33821) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gyNNF-0000V4-GA for bug-gnu-emacs@gnu.org; Mon, 25 Feb 2019 16:01:23 -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,URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gyNN5-00042B-Tn for bug-gnu-emacs@gnu.org; Mon, 25 Feb 2019 16:01:17 -0500 Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]:33216) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gyNN5-0003pU-03 for bug-gnu-emacs@gnu.org; Mon, 25 Feb 2019 16:01:07 -0500 Received: by mail-ed1-x536.google.com with SMTP id c55so8836513edb.0 for ; Mon, 25 Feb 2019 13:00:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:user-agent:mime-version; bh=H94YxN9vPs5exxcHcGMqb/sXx87sA9KL1xnLzAB0xaI=; b=KTMl2gFGAB6Z+WpF32RpppQ/i/K+0MlnPqfsVwzrVkOwOdLvgD4xraGDOPzfL6yNIh lDuKWX3oDCGrIOThkoGS5ejlJLBtXt8jeCJu8fjRwidXTZKtoRCnUGgq0obUztVG+4lO 3rL5Mc8aJuoeIc04zcOUHpw741g8Pq5j2ZgMcWc3lqxqpSqkWJiAPPKS3GezrS93Xp6u +1lWi0y0E1Ep6FD+rhpCl6lgBS8bpKD/6FccEBfJ24mKZ7doyQ0W3+5W8QP2YXkaKfvr Gc4icwJGTVbyR7HpVS5q3Gdo8Zr2Lq7J6R/kQzs0m9bV2ZdXvVjzSfCymCYq2pely+Bk cGIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :mime-version; bh=H94YxN9vPs5exxcHcGMqb/sXx87sA9KL1xnLzAB0xaI=; b=GVHhbTSMLEhDtWfTgPNRFt7s3P45V3WoUcHfY/erifmrLPKjEyKNVdDZPgk+JBDYjq yH/NZdjnKz27l0cjedDVbPAjV6y8lxVleH9tOMCgW7ChktboITu0lAu5aRhAMLlz+IXL Z/hZB1w0aJEu+g1LjFeWNsCvG7mZfZg7NuviM+ZsGfO4a0fG69LiOCTIE2ejwHGxbLi2 Ez6QtqZ+6atJeR7ZRfeMuzOUh9YjYD41gO5J65+AP3umPQL5aLMODPQehPM+BnyvhrWz eO5EQ/U8KuXGPj8guEgwwCM2OFXU0MvzcqsgFRKgLEAGuYoTmv247iLfwUuUd37EqtBC Ci2Q== X-Gm-Message-State: AHQUAubPrM3gtB7JN9Lo1VzCQ1Z8IUYBO8vTSvJN6KviwJHpTRccrhGA Db4beHW6NqeOddzVFQElb0pcgpvq/T4= X-Google-Smtp-Source: AHgI3IanjKbAG/hzSrRO0FylMvHFx+oEs8tmpAre7hAgBOkq4oTI7EcdBHg6MGK2lQr4V3e6dOzUQA== X-Received: by 2002:a17:906:e91:: with SMTP id p17mr14394021ejf.225.1551128448495; Mon, 25 Feb 2019 13:00:48 -0800 (PST) Received: from localhost ([2a02:8084:20e2:c380:f786:805d:f4ab:1006]) by smtp.gmail.com with ESMTPSA id k8sm2919112ede.65.2019.02.25.13.00.47 for (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Mon, 25 Feb 2019 13:00:47 -0800 (PST) From: "Basil L. Contovounesios" To: bug-gnu-emacs@gnu.org Subject: 26.1.92; Segfault in module with --module-assertions Date: Mon, 25 Feb 2019 21:00:41 +0000 Message-ID: <874l8r1t3a.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::536 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=gdb.txt Content-Transfer-Encoding: quoted-printable Content-Description: GDB log Starting program: /home/blc/.local/src/emacs26/src/emacs -Q --module-assert= ions [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff01cb700 (LWP 8299)] [New Thread 0x7fffef9ac700 (LWP 8300)] [New Thread 0x7fffef1ab700 (LWP 8301)] Thread 1 "emacs" received signal SIGSEGV, Segmentation fault. re_search_2 (bufp=3D0xbf5d00 , str1=3D0x0, size1=3D0, str2= =3D0x0, size2=3D18, startpos=3D0,=20 range=3D18, regs=3D0x0, stop=3D18) at regex.c:4354 4354 buf_ch =3D STRING_CHAR_AND_LENGTH (d, buf_charlen); #0 0x0000000000608594 in re_search_2 (bufp=3D0xbf5d00 , str1=3D0x0, size1=3D0, str2=3D0x0, s= ize2=3D18, startpos=3D0, range=3D18, regs=3D0x0, stop=3D18) at regex.c:4354 buf_charlen =3D 0 irange =3D 18 lim =3D 0 d =3D 0x0 buf_ch =3D 18 val =3D 691541629 string1 =3D 0x0 string2 =3D 0x0 fastmap =3D 0xbf5d38 "" translate =3D make_number(0) total_size =3D 18 endpos =3D 18 anchored_start =3D 0 '\000' multibyte =3D 1 '\001' #1 0x0000000000607f91 in re_search (bufp=3D0xbf5d00 , string=3D0x0, size=3D18, startpos=3D= 0, range=3D18, regs=3D0x0) at regex.c:4181 #2 0x00000000005f3fd0 in fast_string_match_internal (regexp=3DXIL(0x8c761c), string=3DXIL(0x3036ec4), table=3DXIL(0)) at se= arch.c:485 val =3D 140737488336288 bufp =3D 0xbf5d00 #3 0x0000000000581b5e in fast_string_match (regexp=3DXIL(0x8c761c), string= =3DXIL(0x3036ec4)) at lisp.h:4061 #4 0x00000000005d7b2d in Ffind_file_name_handler (filename=3DXIL(0x3036ec4= ), operation=3DXIL(0x5af0)) at fileio.c:313 string =3D XIL(0x8c761c) match_pos =3D 140737488336448 handler =3D XIL(0x4e1380) operations =3D XIL(0x10b5c83) elt =3D XIL(0x10ae193) chain =3D XIL(0x15749e3) inhibited_handlers =3D XIL(0) result =3D XIL(0) pos =3D -1 #5 0x00000000005d8002 in Ffile_name_as_directory (file=3DXIL(0x3036ec4)) a= t fileio.c:547 buf =3D 0x7fffffffb6b0 "P\267\377\377\377\177" length =3D 4458226606852 handler =3D make_number(4) val =3D XIL(0x57e6cb) sa_avail =3D 16384 sa_count =3D 24 sa_must_free =3D false #6 0x0000000000644443 in funcall_subr (subr=3D0x7e7d00 , numargs=3D1, args=3D0x7ffff= fffb7c8) at eval.c:2851 internal_argbuf =3D=20 {XIL(0x7e7d00), XIL(0x7fffffffb718), make_number(1440909), XIL(0x= a00c0b080), XIL(0x7e7d05), XIL(0x7fffffffb738), XIL(0x7e7d00), XIL(0x7fffff= ffb730)} internal_args =3D 0x7fffffffb7c8 #7 0x0000000000643f75 in Ffuncall (nargs=3D2, args=3D0x7fffffffb7c0) at ev= al.c:2776 fun =3D XIL(0x7e7d05) original_fun =3D XIL(0x5af0) funcar =3D XIL(0x57e6cb) numargs =3D 1 val =3D XIL(0x3031c43) count =3D 23 #8 0x0000000000682ae1 in module_funcall (env=3D0x3036810, fun=3D0x2e4d680,= nargs=3D1, args=3D0x7fffffffb8f0) at emacs-module.c:478 internal_handler_CONDITION_CASE =3D 0x2c803a0 internal_cleanup_CONDITION_CASE =3D 0x2c803a0 internal_handler_CATCHER_ALL =3D 0x2c818d0 internal_cleanup_CATCHER_ALL =3D 0x2c818d0 newargs =3D 0x7fffffffb7c0 sa_avail =3D 16368 sa_count =3D 23 sa_must_free =3D false nargs1 =3D 2 result =3D 0x7fffffffb880 #9 0x00007fffee6d21e4 in () at /tmp/tmp.wcwAarLF0X/realpath/realpath.so #10 0x00007fffee6d2407 in () at /tmp/tmp.wcwAarLF0X/realpath/realpath.so #11 0x0000000000684e4b in funcall_module (function=3DXIL(0x1436cd5), nargs= =3D1, arglist=3D0x7fffffffbb70) at emacs-module.c:783 func =3D 0x1436cd0 pub =3D { size =3D 210453397508,=20 private_members =3D 0x0,=20 make_global_ref =3D 0x0,=20 free_global_ref =3D 0x770000005b,=20 non_local_exit_check =3D 0x0,=20 non_local_exit_clear =3D 0x0,=20 non_local_exit_get =3D 0x13,=20 non_local_exit_signal =3D 0x0,=20 non_local_exit_throw =3D 0x7fffffffb9e0,=20 make_function =3D 0xc17f20 ,=20 funcall =3D 0xfffffffffffffc48,=20 intern =3D 0xcea0,=20 type_of =3D 0x7fffffffba00,=20 is_not_nil =3D 0x57e6cb ,=20 eq =3D 0x0,=20 extract_integer =3D 0x44e01043390,=20 make_integer =3D 0x7fffffffba40,=20 extract_float =3D 0x61f56e ,=20 make_float =3D 0x57f236 ,=20 copy_string_contents =3D 0x438310 ,=20 make_string =3D 0x7fffffffba40,=20 make_user_ptr =3D 0x8096c4 ,=20 get_user_ptr =3D 0xb8f000 ,=20 set_user_ptr =3D 0x0,=20 get_user_finalizer =3D 0x7fffffffbb60,=20 set_user_finalizer =3D 0x642070 ,=20 vec_get =3D 0x7fffffffba70,=20 vec_set =3D 0x438310 ,=20 vec_size =3D 0x7fffffffbad0,=20 should_quit =3D 0x1105398 } priv =3D { pending_non_local_exit =3D emacs_funcall_exit_return,=20 non_local_exit_symbol =3D XIL(0),=20 non_local_exit_data =3D XIL(0),=20 values =3D XIL(0xc9a023) } env =3D 0x3036810 count =3D 22 sa_avail =3D 16376 sa_count =3D 23 sa_must_free =3D false args =3D 0x7fffffffb930 ret =3D 0x1100642c1e #12 0x0000000000644baa in funcall_lambda (fun=3DXIL(0x1436cd5), nargs=3D1, = arg_vector=3D0x7fffffffbb70) at eval.c:2987 val =3D XIL(0x648c9c) syms_left =3D XIL(0x7fffffffbb70) next =3D XIL(0x20b9830) lexenv =3D XIL(0x580de9) count =3D 22 i =3D 34314288 optional =3D false rest =3D false previous_optional_or_rest =3D false #13 0x00000000006447f1 in apply_lambda (fun=3DXIL(0x1436cd5), args=3DXIL(0x= 2fc8cb3), count=3D21) at eval.c:2913 args_left =3D XIL(0) i =3D 1 numargs =3D 1 arg_vector =3D 0x7fffffffbb70 tem =3D XIL(0x8096c4) sa_avail =3D 16376 sa_count =3D 22 sa_must_free =3D false #14 0x00000000006429c9 in eval_sub (form=3DXIL(0x2fc8ca3)) at eval.c:2286 fun =3D XIL(0x1436cd5) val =3D make_number(230) original_fun =3D XIL(0x20b9830) original_args =3D XIL(0x2fc8cb3) funcar =3D XIL(0x2fab7e9) count =3D 21 argvals =3D=20 {XIL(0x2fc8833), XIL(0x2fc8db3), XIL(0x2fc8873), XIL(0x2fb2868), = XIL(0x41f2b0), XIL(0x685581), XIL(0x10), make_number(2)} #15 0x000000000063cef2 in Fprogn (body=3DXIL(0x2fc8e13)) at eval.c:459 form =3D XIL(0x2fc8ca3) val =3D XIL(0) #16 0x000000000063cf24 in prog_ignore (body=3DXIL(0x2fc8e23)) at eval.c:470 #17 0x000000000063f11c in Fwhile (args=3DXIL(0x2fc8e33)) at eval.c:992 test =3D XIL(0x2fc8db3) body =3D XIL(0x2fc8e23) #18 0x0000000000642382 in eval_sub (form=3DXIL(0x2fc8e43)) at eval.c:2193 args_left =3D XIL(0x2fc8e33) numargs =3D make_number(3) fun =3D XIL(0xb90f45) val =3D XIL(0x7fffffffbe80) original_fun =3D XIL(0xae0a0) original_args =3D XIL(0x2fc8e33) funcar =3D XIL(0xc0b080) count =3D 20 argvals =3D=20 {XIL(0), XIL(0), XIL(0x2fb4ad0), XIL(0), XIL(0x7fffffffbfc0), XIL= (0x684bff), XIL(0x7fffffffbe60), XIL(0x2d788b4)} #19 0x000000000063cef2 in Fprogn (body=3DXIL(0)) at eval.c:459 form =3D XIL(0x2fc8e43) val =3D XIL(0) #20 0x000000000063f03c in Flet (args=3DXIL(0x2fc8e63)) at eval.c:973 temps =3D 0x7fffffffbf00 tem =3D make_number(0) lexenv =3D XIL(0) elt =3D XIL(0x2fc8d63) varlist =3D XIL(0) count =3D 18 argnum =3D 2 sa_avail =3D 16368 sa_count =3D 18 sa_must_free =3D false varlist_len =3D 2 nvars =3D 2 #21 0x0000000000642382 in eval_sub (form=3DXIL(0x2fc8e73)) at eval.c:2193 args_left =3D XIL(0x2fc8e63) numargs =3D make_number(2) fun =3D XIL(0xb90f05) val =3D XIL(0xc2a0) original_fun =3D XIL(0x83a0) original_args =3D XIL(0x2fc8e63) funcar =3D XIL(0x57e6cb) count =3D 17 argvals =3D=20 {XIL(0x2d788b4), XIL(0), make_number(0), XIL(0xc0a7a0), XIL(0x7ff= fffffc060), XIL(0xc0b080), XIL(0x2fc9323), XIL(0)} #22 0x000000000063cef2 in Fprogn (body=3DXIL(0)) at eval.c:459 form =3D XIL(0x2fc8e73) val =3D XIL(0xc2a0) #23 0x0000000000642382 in eval_sub (form=3DXIL(0x2fc8f43)) at eval.c:2193 args_left =3D XIL(0x2fc8f53) numargs =3D make_number(2) fun =3D XIL(0xb90bc5) val =3D XIL(0x1105280) original_fun =3D XIL(0xa920) original_args =3D XIL(0x2fc8f53) funcar =3D make_number(1644217) count =3D 16 argvals =3D=20 {XIL(0x7fffffffc190), XIL(0xc0a7a0), XIL(0xc9e400), XIL(0), XIL(0= x7fffffffc1b0), XIL(0xc12a90), XIL(0x580b87), XIL(0)} #24 0x0000000000641d39 in Feval (form=3DXIL(0x2fc8f43), lexical=3DXIL(0)) a= t eval.c:2061 count =3D 15 #25 0x0000000000644464 in funcall_subr (subr=3D0xb911c0 , numargs=3D= 2, args=3D0x7fffffffc3f0) at eval.c:2853 internal_argbuf =3D=20 {XIL(0xb911c0), XIL(0x7fffffffc2d8), make_number(1440909), XIL(0x= a00c0b080), XIL(0xb911c5), XIL(0x7fffffffc2f8), XIL(0xb911c0), XIL(0x7fffff= ffc2f0)} internal_args =3D 0x7fffffffc3f0 #26 0x0000000000643f75 in Ffuncall (nargs=3D3, args=3D0x7fffffffc3e8) at ev= al.c:2776 fun =3D XIL(0xb911c5) original_fun =3D XIL(0x53a0) funcar =3D make_number(1604955) numargs =3D 2 val =3D XIL(0x7fffffffc370) count =3D 14 #27 0x00000000006996f0 in exec_byte_code (bytestr=3DXIL(0x94685c), vector=3DXIL(0x94687d), maxdepth=3Dmake_numbe= r(16), args_template=3Dmake_number(257), nargs=3D1, args=3D0x7fffffffc890) = at bytecode.c:630 op =3D 2 type =3D (unknown: 2218598600) targets =3D=20 {0x69c65f , 0x69c684 = , 0x69c686 , 0x69c688 , 0x69c68= a , 0x69c68a , 0x69c6ef , 0x69c763 , 0x698e2a , 0x698e2c , 0x698e2e , 0x69= 8e30 , 0x698e32 , 0x698e32 , 0x698e38 , 0x698df9 , 0x6992fe , 0x699300 , 0x699= 302 , 0x699304 , 0x699306 , 0x699306 , 0x69933b , 0x69930c , 0x69960d , 0x6996= 0f , 0x699611 , 0x699613 , 0x699615 , 0x699615 , 0x6995c7 , 0x6995de , 0x6996b= d , 0x6996bf , 0x6996c1 , 0x6996c3 , 0x6996c5 , 0x6996c5 , 0x699677 , 0x69968e= , 0x699772 , 0x699774 , 0x699776 , 0x699778 = , 0x69977a , 0x69977a , 0x69972c = , 0x699743 , 0x699fd1 , 0x699eb7 , 0x699eae ,= 0x69c65f , 0x69c65f , 0x69c65f= , 0x69c65f , 0x69c65f , 0x69a202 , 0x69a321 , 0x69a38b , 0x69a3f6 , 0x69a4= 62 , 0x699151 , 0x6991d6 , 0x69a4e3 , 0x699092 , 0x69923e , 0x69a555 , 0x69a5b= d , 0x69a605 , 0x69a66d , 0x69a6bf , 0x69a790 , 0x69a7d8 , 0x69a840 , 0x69a8c5= , 0x69a90d , 0x69a955 , 0x69a9bd , 0x69aa25 = , 0x69aa8d , 0x69ab12 , 0x69ab64 = , 0x69abb6 , 0x69ac87 , 0x69ad01 , 0x69ad7b ,= 0x69af47 , 0x69afb4 , 0x69b021 <= exec_byte_code+9995>, 0x69b08e , 0x69b0fb , 0x69b14d , 0x69b1cb , 0x69b21d , 0x69b26f , 0x69b= 2c1 , 0x69b3cd , 0x699d31 , 0x69b42b , 0x69b473 , 0x69b53f , 0x69b5a8 , = 0x69b606 , 0x69b64e , 0x69b694 = , 0x69b6da , 0x69b728 , 0x69c65f , 0x69b780 , 0x69b7c6 , 0x69b80c , 0x6= 9b852 , 0x69b898 , 0x69b8de , 0x699d31 , 0x69c65f , 0x69b926 , 0x69b97b = , 0x69b9c3 , 0x69ba0b , 0x69ba7= 3 , 0x69badb , 0x69bb23 , 0x69bc3d , 0x69bca5 , 0x69bd0d , 0x69bd75 , 0= x69bdbb , 0x69c65f , 0x699c65 <= exec_byte_code+4943>, 0x699829 , 0x699003 , 0x6998d5 , 0x699956 , = 0x6999d4 , 0x699c19 , 0x699c2e , 0x699574 , 0x699ce8 , 0x699d68 , 0x699df6 , 0= x699e3f , 0x69a01d , 0x69a09a , 0x69a11f , 0x69a17f , 0x6997db , 0x69be03 , 0= x69be88 , 0x69bed0 , 0x69bf18 <= exec_byte_code+13826>, 0x69bf60 , 0x69bfa8 , 0x69c010 , 0x69c078 , 0x69c0e0 , 0x69c148 , 0x69= c2be , 0x69c326 , 0x69c38e , 0x69c3d6 , 0x69c43e , 0x69c4a6 , 0x69c4ee = , 0x69c536 , 0x69b313 , 0x69b36= 5 , 0x69c588 , 0x69c5f4 , 0x69c65f , 0x699a52 , 0x699a6f , 0x699adb , 0x69= 9b47 , 0x699bb0 , 0x69a711 , 0x69ac08 , 0x69b4c0 , 0x69c7f6 , 0x69c86b , 0x= 69c65f , 0x69c65f , 0x69c901 , 0x69c988 , 0x69c65f , 0x69c65f , 0x69c65f , 0x69c65f , 0x69c65f , 0x69c= 65f , 0x69c65f , 0x69c65f , 0x69cb9c } const_length =3D 7 bytestr_length =3D 43 vectorp =3D 0x946880 quitcounter =3D 1 '\001' stack_items =3D 17 sa_avail =3D 16205 sa_count =3D 14 sa_must_free =3D false stack_base =3D 0x7fffffffc380 stack_lim =3D 0x7fffffffc408 top =3D 0x7fffffffc3e8 void_stack_lim =3D 0x7fffffffc408 bytestr_data =3D 0x7fffffffc408 "\301\001!\211@\001A\211@\001A\211@= \001A\001\004\006\a\302\303\304\305 !\b\"\002\203#" pc =3D 0x7fffffffc423 "\002\203#" count =3D 14 result =3D XIL(0) #28 0x0000000000644b6f in funcall_lambda (fun=3DXIL(0x94682d), nargs=3D1, a= rg_vector=3D0x7fffffffc888) at eval.c:2977 size =3D 5 val =3D XIL(0x7fffffffc7e8) syms_left =3D make_number(257) next =3D XIL(0x1200c0b080) lexenv =3D XIL(0x7fffffffc7c0) count =3D 14 i =3D 0 optional =3D false rest =3D false previous_optional_or_rest =3D false #29 0x0000000000643fb9 in Ffuncall (nargs=3D2, args=3D0x7fffffffc880) at ev= al.c:2778 fun =3D XIL(0x94682d) original_fun =3D XIL(0xa39960) funcar =3D XIL(0x645e21) numargs =3D 1 val =3D XIL(0x7fffffffc860) count =3D 13 #30 0x00000000006996f0 in exec_byte_code (bytestr=3DXIL(0x946afc), vector=3DXIL(0x946b1d), maxdepth=3Dmake_numbe= r(4), args_template=3Dmake_number(257), nargs=3D1, args=3D0x7fffffffcd10) a= t bytecode.c:630 op =3D 1 type =3D (unknown: 12114688) targets =3D=20 {0x69c65f , 0x69c684 = , 0x69c686 , 0x69c688 , 0x69c68= a , 0x69c68a , 0x69c6ef , 0x69c763 , 0x698e2a , 0x698e2c , 0x698e2e , 0x69= 8e30 , 0x698e32 , 0x698e32 , 0x698e38 , 0x698df9 , 0x6992fe , 0x699300 , 0x699= 302 , 0x699304 , 0x699306 , 0x699306 , 0x69933b , 0x69930c , 0x69960d , 0x6996= 0f , 0x699611 , 0x699613 , 0x699615 , 0x699615 , 0x6995c7 , 0x6995de , 0x6996b= d , 0x6996bf , 0x6996c1 , 0x6996c3 , 0x6996c5 , 0x6996c5 , 0x699677 , 0x69968e= , 0x699772 , 0x699774 , 0x699776 , 0x699778 = , 0x69977a , 0x69977a , 0x69972c = , 0x699743 , 0x699fd1 , 0x699eb7 , 0x699eae ,= 0x69c65f , 0x69c65f , 0x69c65f= , 0x69c65f , 0x69c65f , 0x69a202 , 0x69a321 , 0x69a38b , 0x69a3f6 , 0x69a4= 62 , 0x699151 , 0x6991d6 , 0x69a4e3 , 0x699092 , 0x69923e , 0x69a555 , 0x69a5b= d , 0x69a605 , 0x69a66d , 0x69a6bf , 0x69a790 , 0x69a7d8 , 0x69a840 , 0x69a8c5= , 0x69a90d , 0x69a955 , 0x69a9bd , 0x69aa25 = , 0x69aa8d , 0x69ab12 , 0x69ab64 = , 0x69abb6 , 0x69ac87 , 0x69ad01 , 0x69ad7b ,= 0x69af47 , 0x69afb4 , 0x69b021 <= exec_byte_code+9995>, 0x69b08e , 0x69b0fb , 0x69b14d , 0x69b1cb , 0x69b21d , 0x69b26f , 0x69b= 2c1 , 0x69b3cd , 0x699d31 , 0x69b42b , 0x69b473 , 0x69b53f , 0x69b5a8 , = 0x69b606 , 0x69b64e , 0x69b694 = , 0x69b6da , 0x69b728 , 0x69c65f , 0x69b780 , 0x69b7c6 , 0x69b80c , 0x6= 9b852 , 0x69b898 , 0x69b8de , 0x699d31 , 0x69c65f , 0x69b926 , 0x69b97b = , 0x69b9c3 , 0x69ba0b , 0x69ba7= 3 , 0x69badb , 0x69bb23 , 0x69bc3d , 0x69bca5 , 0x69bd0d , 0x69bd75 , 0= x69bdbb , 0x69c65f , 0x699c65 <= exec_byte_code+4943>, 0x699829 , 0x699003 , 0x6998d5 , 0x699956 , = 0x6999d4 , 0x699c19 , 0x699c2e , 0x699574 , 0x699ce8 , 0x699d68 , 0x699df6 , 0= x699e3f , 0x69a01d , 0x69a09a , 0x69a11f , 0x69a17f , 0x6997db , 0x69be03 , 0= x69be88 , 0x69bed0 , 0x69bf18 <= exec_byte_code+13826>, 0x69bf60 , 0x69bfa8 , 0x69c010 , 0x69c078 , 0x69c0e0 , 0x69c148 , 0x69= c2be , 0x69c326 , 0x69c38e , 0x69c3d6 , 0x69c43e , 0x69c4a6 , 0x69c4ee = , 0x69c536 , 0x69b313 , 0x69b36= 5 , 0x69c588 , 0x69c5f4 , 0x69c65f , 0x699a52 , 0x699a6f , 0x699adb , 0x69= 9b47 , 0x699bb0 , 0x69a711 , 0x69ac08 , 0x69b4c0 , 0x69c7f6 , 0x69c86b , 0x= 69c65f , 0x69c65f , 0x69c901 , 0x69c988 , 0x69c65f , 0x69c65f , 0x69c65f , 0x69c65f , 0x69c65f , 0x69c= 65f , 0x69c65f , 0x69c65f , 0x69cb9c } const_length =3D 4 bytestr_length =3D 29 vectorp =3D 0x946b20 quitcounter =3D 1 '\001' stack_items =3D 5 sa_avail =3D 16315 sa_count =3D 12 sa_must_free =3D false stack_base =3D 0x7fffffffc870 stack_lim =3D 0x7fffffffc898 top =3D 0x7fffffffc880 void_stack_lim =3D 0x7fffffffc898 bytestr_data =3D 0x7fffffffc898 "\b\204\b" pc =3D 0x7fffffffc8a5 "\n)B\211A\t=3D\204\032" count =3D 12 result =3D XIL(0x7fffffffcb30) #31 0x0000000000644b6f in funcall_lambda (fun=3DXIL(0x946abd), nargs=3D1, a= rg_vector=3D0x7fffffffcd08) at eval.c:2977 size =3D 6 val =3D XIL(0x7fffffffcc68) syms_left =3D make_number(257) next =3D XIL(0x1200c0b080) lexenv =3D make_number(1440909) count =3D 12 i =3D 0 optional =3D false rest =3D false previous_optional_or_rest =3D false #32 0x0000000000643fb9 in Ffuncall (nargs=3D2, args=3D0x7fffffffcd00) at ev= al.c:2778 fun =3D XIL(0x946abd) original_fun =3D XIL(0x4dd0a0) funcar =3D XIL(0xc0b080) numargs =3D 1 val =3D XIL(0xc2a0) count =3D 11 #33 0x00000000006996f0 in exec_byte_code (bytestr=3DXIL(0x94601c), vector=3DXIL(0x94603d), maxdepth=3Dmake_numbe= r(3), args_template=3Dmake_number(256), nargs=3D1, args=3D0x7fffffffd2a8) a= t bytecode.c:630 op =3D 1 type =3D (unknown: 12133568) targets =3D=20 {0x69c65f , 0x69c684 = , 0x69c686 , 0x69c688 , 0x69c68= a , 0x69c68a , 0x69c6ef , 0x69c763 , 0x698e2a , 0x698e2c , 0x698e2e , 0x69= 8e30 , 0x698e32 , 0x698e32 , 0x698e38 , 0x698df9 , 0x6992fe , 0x699300 , 0x699= 302 , 0x699304 , 0x699306 , 0x699306 , 0x69933b , 0x69930c , 0x69960d , 0x6996= 0f , 0x699611 , 0x699613 , 0x699615 , 0x699615 , 0x6995c7 , 0x6995de , 0x6996b= d , 0x6996bf , 0x6996c1 , 0x6996c3 , 0x6996c5 , 0x6996c5 , 0x699677 , 0x69968e= , 0x699772 , 0x699774 , 0x699776 , 0x699778 = , 0x69977a , 0x69977a , 0x69972c = , 0x699743 , 0x699fd1 , 0x699eb7 , 0x699eae ,= 0x69c65f , 0x69c65f , 0x69c65f= , 0x69c65f , 0x69c65f , 0x69a202 , 0x69a321 , 0x69a38b , 0x69a3f6 , 0x69a4= 62 , 0x699151 , 0x6991d6 , 0x69a4e3 , 0x699092 , 0x69923e , 0x69a555 , 0x69a5b= d , 0x69a605 , 0x69a66d , 0x69a6bf , 0x69a790 , 0x69a7d8 , 0x69a840 , 0x69a8c5= , 0x69a90d , 0x69a955 , 0x69a9bd , 0x69aa25 = , 0x69aa8d , 0x69ab12 , 0x69ab64 = , 0x69abb6 , 0x69ac87 , 0x69ad01 , 0x69ad7b ,= 0x69af47 , 0x69afb4 , 0x69b021 <= exec_byte_code+9995>, 0x69b08e , 0x69b0fb , 0x69b14d , 0x69b1cb , 0x69b21d , 0x69b26f , 0x69b= 2c1 , 0x69b3cd , 0x699d31 , 0x69b42b , 0x69b473 , 0x69b53f , 0x69b5a8 , = 0x69b606 , 0x69b64e , 0x69b694 = , 0x69b6da , 0x69b728 , 0x69c65f , 0x69b780 , 0x69b7c6 , 0x69b80c , 0x6= 9b852 , 0x69b898 , 0x69b8de , 0x699d31 , 0x69c65f , 0x69b926 , 0x69b97b = , 0x69b9c3 , 0x69ba0b , 0x69ba7= 3 , 0x69badb , 0x69bb23 , 0x69bc3d , 0x69bca5 , 0x69bd0d , 0x69bd75 , 0= x69bdbb , 0x69c65f , 0x699c65 <= exec_byte_code+4943>, 0x699829 , 0x699003 , 0x6998d5 , 0x699956 , = 0x6999d4 , 0x699c19 , 0x699c2e , 0x699574 , 0x699ce8 , 0x699d68 , 0x699df6 , 0= x699e3f , 0x69a01d , 0x69a09a , 0x69a11f , 0x69a17f , 0x6997db , 0x69be03 , 0= x69be88 , 0x69bed0 , 0x69bf18 <= exec_byte_code+13826>, 0x69bf60 , 0x69bfa8 , 0x69c010 , 0x69c078 , 0x69c0e0 , 0x69c148 , 0x69= c2be , 0x69c326 , 0x69c38e , 0x69c3d6 , 0x69c43e , 0x69c4a6 , 0x69c4ee = , 0x69c536 , 0x69b313 , 0x69b36= 5 , 0x69c588 , 0x69c5f4 , 0x69c65f , 0x699a52 , 0x699a6f , 0x699adb , 0x69= 9b47 , 0x699bb0 , 0x69a711 , 0x69ac08 , 0x69b4c0 , 0x69c7f6 , 0x69c86b , 0x= 69c65f , 0x69c65f , 0x69c901 , 0x69c988 , 0x69c65f , 0x69c65f , 0x69c65f , 0x69c65f , 0x69c65f , 0x69c= 65f , 0x69c65f , 0x69c65f , 0x69cb9c } const_length =3D 4 bytestr_length =3D 17 vectorp =3D 0x946040 quitcounter =3D 1 '\001' stack_items =3D 4 sa_avail =3D 16335 sa_count =3D 10 sa_must_free =3D false stack_base =3D 0x7fffffffccf0 stack_lim =3D 0x7fffffffcd10 top =3D 0x7fffffffcd00 void_stack_lim =3D 0x7fffffffcd10 bytestr_data =3D 0x7fffffffcd10 "p\030\301 \210\302\001\206\v" pc =3D 0x7fffffffcd1c "\210\301 )\207\320\377\377\377\177" count =3D 10 result =3D XIL(0x2fc92d3) #34 0x0000000000644b6f in funcall_lambda (fun=3DXIL(0x945fdd), nargs=3D1, a= rg_vector=3D0x7fffffffd2a0) at eval.c:2977 size =3D 6 val =3D XIL(0x7fffffffd0d8) syms_left =3D make_number(256) next =3D XIL(0x1200c0b080) lexenv =3D XIL(0x7fffffffd0b0) count =3D 10 i =3D 0 optional =3D false rest =3D false previous_optional_or_rest =3D false #35 0x0000000000643fb9 in Ffuncall (nargs=3D2, args=3D0x7fffffffd298) at ev= al.c:2778 fun =3D XIL(0x945fdd) original_fun =3D XIL(0xa39590) funcar =3D XIL(0x589371) numargs =3D 1 val =3D XIL(0) count =3D 9 #36 0x0000000000639907 in Ffuncall_interactively (nargs=3D2, args=3D0x7ffff= fffd298) at callint.c:252 speccount =3D 8 #37 0x0000000000644337 in funcall_subr (subr=3D0xb90a00 , numargs=3D2, args=3D0x7fffff= ffd298) at eval.c:2831 #38 0x0000000000643f75 in Ffuncall (nargs=3D3, args=3D0x7fffffffd290) at ev= al.c:2776 fun =3D XIL(0xb90a05) original_fun =3D XIL(0x66c0) funcar =3D XIL(0x645e21) numargs =3D 2 val =3D XIL(0x7fffffffd280) count =3D 7 #39 0x000000000063bde9 in Fcall_interactively (function=3DXIL(0xa39590), record_flag=3DXIL(0), keys=3DXIL(0xca3695)) = at callint.c:854 val =3D XIL(0) args =3D 0x7fffffffd290 visargs =3D 0x7fffffffd2a8 specs =3D XIL(0x80fa7c) filter_specs =3D XIL(0x80fa7c) teml =3D XIL(0x7fffffffd108) up_event =3D XIL(0) enable =3D XIL(0) sa_avail =3D 16310 sa_count =3D 6 sa_must_free =3D false speccount =3D 6 next_event =3D 1 prefix_arg =3D XIL(0) string =3D 0x7fffffffd2e0 "P" tem =3D 0x77842b "" varies =3D 0x7fffffffd2c0 "" i =3D 3 nargs =3D 3 mark =3D 5760715 arg_from_tty =3D false key_count =3D 1 record_then_fail =3D false save_this_command =3D XIL(0xa39590) save_last_command =3D XIL(0x4628d0) save_this_original_command =3D XIL(0xa39590) save_real_this_command =3D XIL(0xa39590) #40 0x0000000000644490 in funcall_subr (subr=3D0xb90a40 , numargs=3D3, args=3D0x7fffffffd= 610) at eval.c:2856 internal_argbuf =3D=20 {XIL(0xb90a40), XIL(0x7fffffffd528), make_number(1440909), XIL(0x= a00c0b080), XIL(0xb90a45), XIL(0x7fffffffd548), XIL(0xb90a40), XIL(0x7fffff= ffd540)} internal_args =3D 0x7fffffffd610 #41 0x0000000000643f75 in Ffuncall (nargs=3D4, args=3D0x7fffffffd608) at ev= al.c:2776 fun =3D XIL(0xb90a45) original_fun =3D XIL(0xb1b80) funcar =3D XIL(0xc0b080) numargs =3D 3 val =3D XIL(0) count =3D 5 #42 0x00000000006996f0 in exec_byte_code (bytestr=3DXIL(0x8aea5c), vector=3DXIL(0x8aea7d), maxdepth=3Dmake_numbe= r(13), args_template=3Dmake_number(1025), nargs=3D1, args=3D0x7fffffffdb40)= at bytecode.c:630 op =3D 3 type =3D CATCHER targets =3D=20 {0x69c65f , 0x69c684 = , 0x69c686 , 0x69c688 , 0x69c68= a , 0x69c68a , 0x69c6ef , 0x69c763 , 0x698e2a , 0x698e2c , 0x698e2e , 0x69= 8e30 , 0x698e32 , 0x698e32 , 0x698e38 , 0x698df9 , 0x6992fe , 0x699300 , 0x699= 302 , 0x699304 , 0x699306 , 0x699306 , 0x69933b , 0x69930c , 0x69960d , 0x6996= 0f , 0x699611 , 0x699613 , 0x699615 , 0x699615 , 0x6995c7 , 0x6995de , 0x6996b= d , 0x6996bf , 0x6996c1 , 0x6996c3 , 0x6996c5 , 0x6996c5 , 0x699677 , 0x69968e= , 0x699772 , 0x699774 , 0x699776 , 0x699778 = , 0x69977a , 0x69977a , 0x69972c = , 0x699743 , 0x699fd1 , 0x699eb7 , 0x699eae ,= 0x69c65f , 0x69c65f , 0x69c65f= , 0x69c65f , 0x69c65f , 0x69a202 , 0x69a321 , 0x69a38b , 0x69a3f6 , 0x69a4= 62 , 0x699151 , 0x6991d6 , 0x69a4e3 , 0x699092 , 0x69923e , 0x69a555 , 0x69a5b= d , 0x69a605 , 0x69a66d , 0x69a6bf , 0x69a790 , 0x69a7d8 , 0x69a840 , 0x69a8c5= , 0x69a90d , 0x69a955 , 0x69a9bd , 0x69aa25 = , 0x69aa8d , 0x69ab12 , 0x69ab64 = , 0x69abb6 , 0x69ac87 , 0x69ad01 , 0x69ad7b ,= 0x69af47 , 0x69afb4 , 0x69b021 <= exec_byte_code+9995>, 0x69b08e , 0x69b0fb , 0x69b14d , 0x69b1cb , 0x69b21d , 0x69b26f , 0x69b= 2c1 , 0x69b3cd , 0x699d31 , 0x69b42b , 0x69b473 , 0x69b53f , 0x69b5a8 , = 0x69b606 , 0x69b64e , 0x69b694 = , 0x69b6da , 0x69b728 , 0x69c65f , 0x69b780 , 0x69b7c6 , 0x69b80c , 0x6= 9b852 , 0x69b898 , 0x69b8de , 0x699d31 , 0x69c65f , 0x69b926 , 0x69b97b = , 0x69b9c3 , 0x69ba0b , 0x69ba7= 3 , 0x69badb , 0x69bb23 , 0x69bc3d , 0x69bca5 , 0x69bd0d , 0x69bd75 , 0= x69bdbb , 0x69c65f , 0x699c65 <= exec_byte_code+4943>, 0x699829 , 0x699003 , 0x6998d5 , 0x699956 , = 0x6999d4 , 0x699c19 , 0x699c2e , 0x699574 , 0x699ce8 , 0x699d68 , 0x699df6 , 0= x699e3f , 0x69a01d , 0x69a09a , 0x69a11f , 0x69a17f , 0x6997db , 0x69be03 , 0= x69be88 , 0x69bed0 , 0x69bf18 <= exec_byte_code+13826>, 0x69bf60 , 0x69bfa8 , 0x69c010 , 0x69c078 , 0x69c0e0 , 0x69c148 , 0x69= c2be , 0x69c326 , 0x69c38e , 0x69c3d6 , 0x69c43e , 0x69c4a6 , 0x69c4ee = , 0x69c536 , 0x69b313 , 0x69b36= 5 , 0x69c588 , 0x69c5f4 , 0x69c65f , 0x699a52 , 0x699a6f , 0x699adb , 0x69= 9b47 , 0x699bb0 , 0x69a711 , 0x69ac08 , 0x69b4c0 , 0x69c7f6 , 0x69c86b , 0x= 69c65f , 0x69c65f , 0x69c901 , 0x69c988 , 0x69c65f , 0x69c65f , 0x69c65f , 0x69c65f , 0x69c65f , 0x69c= 65f , 0x69c65f , 0x69c65f , 0x69cb9c } const_length =3D 25 bytestr_length =3D 165 vectorp =3D 0x8aea80 quitcounter =3D 1 '\001' stack_items =3D 14 sa_avail =3D 16107 sa_count =3D 5 sa_must_free =3D false stack_base =3D 0x7fffffffd5d0 stack_lim =3D 0x7fffffffd640 top =3D 0x7fffffffd608 void_stack_lim =3D 0x7fffffffd640 bytestr_data =3D 0x7fffffffd640 "\306\020\211?\205\023" pc =3D 0x7fffffffd6bb "\006\006\071\203\242" count =3D 5 result =3D XIL(0) #43 0x0000000000644b6f in funcall_lambda (fun=3DXIL(0x8aea2d), nargs=3D1, a= rg_vector=3D0x7fffffffdb38) at eval.c:2977 size =3D 5 val =3D XIL(0x7fffffffda98) syms_left =3D make_number(1025) next =3D XIL(0x1200c0b080) lexenv =3D make_number(34910567923712) count =3D 5 i =3D 0 optional =3D false rest =3D false previous_optional_or_rest =3D false #44 0x0000000000643fb9 in Ffuncall (nargs=3D2, args=3D0x7fffffffdb30) at ev= al.c:2778 fun =3D XIL(0x8aea2d) original_fun =3D XIL(0x3f30) funcar =3D XIL(0x1) numargs =3D 1 val =3D XIL(0x7fffffffdb38) count =3D 4 #45 0x0000000000643891 in call1 (fn=3DXIL(0x3f30), arg1=3DXIL(0xa39590)) at= eval.c:2627 #46 0x000000000058a56b in command_loop_1 () at keyboard.c:1482 scount =3D 3 cmd =3D XIL(0xa39590) keybuf =3D=20 {make_number(10), XIL(0x2012e48b3), XIL(0), XIL(0x7a10), XIL(0x10= 000010f), XIL(0), XIL(0xc0a7a0), XIL(0x7a10), make_number(55834574852), XIL= (0xc12a90), XIL(0x7fffffffdbc0), XIL(0), XIL(0x7fffffffdc00), make_number(1= 644723), make_number(34910567923712), XIL(0xc0b080), XIL(0x580b87), XIL(0),= XIL(0x7fffffffdc00), XIL(0x57e6cb), XIL(0), XIL(0xc0b080), XIL(0x7fffffffd= c60), XIL(0), XIL(0x7fffffffdc30), XIL(0x57e6cb), XIL(0x5), XIL(0x7a10), XI= L(0x7fffffffdc70), XIL(0x640415)} i =3D 1 prev_modiff =3D 182 prev_buffer =3D 0xc9e400 already_adjusted =3D false #47 0x000000000063fffe in internal_condition_case (bfun=3D0x589d5b , handlers=3DXIL(0x5280), hfun=3D0x589= 3bf ) at eval.c:1336 val =3D XIL(0x57e6cb) c =3D 0x2c80280 #48 0x0000000000589971 in command_loop_2 (ignore=3DXIL(0)) at keyboard.c:11= 10 val =3D XIL(0xc900) #49 0x000000000063f4fd in internal_catch (tag=3DXIL(0xc900), func=3D0x58994= 4 , arg=3DXIL(0)) at eval.c:1101 val =3D XIL(0) c =3D 0x2c80160 #50 0x000000000058990f in command_loop () at keyboard.c:1089 #51 0x0000000000588ea8 in recursive_edit_1 () at keyboard.c:695 count =3D 1 val =3D XIL(0x7fffffffdde0) #52 0x000000000058909d in Frecursive_edit () at keyboard.c:766 count =3D 0 buffer =3D XIL(0) #53 0x0000000000586c3c in main (argc=3D3, argv=3D0x7fffffffe028) at emacs.c= :1717 stack_bottom_variable =3D 0x2c6c290 do_initial_setlocale =3D true dumping =3D false skip_args =3D 1 no_loadup =3D false junk =3D 0x0 dname_arg =3D 0x0 ch_to_dir =3D 0x0 original_pwd =3D 0x0 disable_aslr =3D false rlim =3D { rlim_cur =3D 10022912,=20 rlim_max =3D 18446744073709551615 } sockfd =3D -1 module_assertions =3D true Lisp Backtrace: "file-name-as-directory" (0xffffb7c8) "realpath-truename" (0xffffbb70) "while" (0xffffbe50) "let" (0xffffc070) "progn" (0xffffc1c0) "eval" (0xffffc3f0) "elisp--eval-last-sexp" (0xffffc888) "eval-last-sexp" (0xffffcd08) "eval-print-last-sexp" (0xffffd2a0) "funcall-interactively" (0xffffd298) "call-interactively" (0xffffd610) "command-execute" (0xffffdb38) --=-=-= Content-Type: text/plain I have written a dynamic module which provides a function realpath-truename similar to file-truename, but which uses canonicalize_file_name(3) internally and which doesn't respect file name handlers. It is hosted at the following URL: https://gitlab.com/basil-conto/realpath Repeatedly calling realpath-truename on a directory name in an Emacs started with --module-assertions segfaults in a call to file-name-as-directory. The precise recipe I am using is the following: 0. git clone https://gitlab.com/basil-conto/realpath.git 1. cd realpath 2. make 3. cd /path/to/emacs/src 4. gdb emacs 5. set logging on 6. run -Q --module-assertions 7. (progn (module-load "/path/to/realpath.so") (dotimes (_ 1000) (realpath-truename user-emacs-directory))) C-j 9. bt full I attach the corresponding GDB log. I am not confident that the module is written properly, in particular w.r.t. nonlocal exits, but I don't see what, if anything, I am doing wrong, so any help would be greatly appreciated. Thanks, -- Basil In GNU Emacs 26.1.92 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2019-02-25 built on thunk Repository revision: 1dff09739346037a588a3b9290800c09a9b3409a Windowing system distributor 'The X.Org Foundation', version 11.0.12003000 System Description: Debian GNU/Linux buster/sid Configured using: 'configure 'CC=ccache gcc' 'CFLAGS=-O0 -g3 -ggdb -gdwarf-4 -pipe' --config-cache --prefix=/home/blc/.local --program-suffix=26 --enable-checking=yes,glyphs --enable-check-lisp-object-type --with-mailutils --with-x-toolkit=lucid --with-modules --with-file-notification=yes --with-x' Configured features: XAW3D XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS LIBSYSTEMD LCMS2 Important settings: value of $LANG: en_IE.UTF-8 locale-coding-system: utf-8-unix --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 25 21:59:50 2019 Received: (at 34655) by debbugs.gnu.org; 26 Feb 2019 02:59:50 +0000 Received: from localhost ([127.0.0.1]:52090 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gySyD-0004Zk-Kx for submit@debbugs.gnu.org; Mon, 25 Feb 2019 21:59:49 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50803) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gySyA-0004ZW-9e for 34655@debbugs.gnu.org; Mon, 25 Feb 2019 21:59:46 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53919) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gySy4-0002qk-Qc; Mon, 25 Feb 2019 21:59:40 -0500 Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1gySy4-0005NR-Mq; Mon, 25 Feb 2019 21:59:40 -0500 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: "Basil L. Contovounesios" In-Reply-To: <874l8r1t3a.fsf@tcd.ie> (contovob@tcd.ie) Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> Message-Id: Date: Mon, 25 Feb 2019 21:59:40 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: 34655@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) [[[ 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. ]]] > I have written a dynamic module which provides a function > realpath-truename The function might be useful, but that is not the right name for it. In the GNU system we do not use "path" to mean a file name. Could you describe in words what job the function does? Then I could suggest a name. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 26 06:17:06 2019 Received: (at 34655) by debbugs.gnu.org; 26 Feb 2019 11:17:06 +0000 Received: from localhost ([127.0.0.1]:52325 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyajR-0004qu-Tv for submit@debbugs.gnu.org; Tue, 26 Feb 2019 06:17:06 -0500 Received: from mail-ed1-f53.google.com ([209.85.208.53]:46798) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyajQ-0004qN-08 for 34655@debbugs.gnu.org; Tue, 26 Feb 2019 06:17:04 -0500 Received: by mail-ed1-f53.google.com with SMTP id f2so10348797edy.13 for <34655@debbugs.gnu.org>; Tue, 26 Feb 2019 03:17:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=WOjzsMJM9GB7KcurjQ6VTLYuM3YA1RDcn+5O0+XR5Pg=; b=EPNoUNbav4jlw84K4CKBev2guWVQjXecHjbZ4NBS6lhdPila8NcGRw4x+2Lv4/HPHr yAZvr1yTyF87GBUQS1JpDDmHJErOz++jY+eXCEy3TUrg887ZxNM/o67RCm8/8jJCe7da MZGXpPBup3YcR+/9YGlf6j6kZnLEpZyBvi0HZ+t7ZECPf46XAgKvRc5eTfTJALRK57Oc u0mokxvE64uGaC08nbVeqoDJ3KM1d93eR/mJWrx06cTyWAfu2T0ztimNIpxMvY2HG6ku Lvjo8W+30M6qrMfuIXliWPN7UBv1ExLhcaunoB8R1OrSvWJg1W/5/NWG5iWTRm8KcNyu H0MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=WOjzsMJM9GB7KcurjQ6VTLYuM3YA1RDcn+5O0+XR5Pg=; b=khqed44LaiOYkLp07bJspG0gh72CKCV1OitNWDTexg2x2g1TvhOkaiQxYiNMD9gsDC vsBTe7qKe7uZF9eosl4xiaSfX7gmVCRsNFWSTDcEWfUyWgSMLCEeWXkfYHoq9TnTD8kd C1qbJR38+RyWkDzyYeDl9OokO23fpHZQ6gDSCfOpDgcEt9VRTPfZ/9M5JIZxkbtD83Za TuHP9WPfDxg2/V9wMTZX3EV16Lj09Lfr92kF8gN46ZXBG5ozc9HpR6XlMO4mFvjeyZUB k2czYfo9ZI8gAUZgNBYqbR9x2Wwh82Ow7htDuCRmTMl1Kz6fEz6IKGhWR50kHDYQD9pV RGiA== X-Gm-Message-State: AHQUAuYX8anfvtN8dTUsrkv99oZdC3dag2ALVXZVRVmAA7NIFMHZCE5G aZiOKnt3IPzR1qfwx1d3KnWFZSeyaOWkQQ== X-Google-Smtp-Source: AHgI3IbAQpmUQg5OwZdwFz50DSDkCmKe04losuXKxNupHmL3i6lXqfs3FLOWmEYV5XWyNo7BQE0kxA== X-Received: by 2002:a50:b4db:: with SMTP id x27mr18607187edd.90.1551179818187; Tue, 26 Feb 2019 03:16:58 -0800 (PST) Received: from localhost ([2a02:8084:20e2:c380:f786:805d:f4ab:1006]) by smtp.gmail.com with ESMTPSA id f10sm3410757edb.60.2019.02.26.03.16.56 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 26 Feb 2019 03:16:57 -0800 (PST) From: "Basil L. Contovounesios" To: Richard Stallman Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> Date: Tue, 26 Feb 2019 11:16:56 +0000 In-Reply-To: (Richard Stallman's message of "Mon, 25 Feb 2019 21:59:40 -0500") Message-ID: <87h8cqre8n.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: 34655@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Richard Stallman writes: > > I have written a dynamic module which provides a function > > realpath-truename > > The function might be useful, but that is not the right name for it. > In the GNU system we do not use "path" to mean a file name. Thanks, I am aware of this. See below for how the name came to be. > Could you describe in words what job the function does? > Then I could suggest a name. Thanks, but just to clarify: I have not written this module with the intention of advertising it for others to use; I don't think anyone would find it of great use. I was motivated to write it to test Emacs' new (at the time) module system, and because, with enough packages installed, file-truename slowed down package-initialize (and thus my emacs-init-time) by a non-negligible amount. I thus overrode file-truename with realpath-truename using advice, with the caveat that realpath-truename does not respect file name handlers (in practice I never needed this). The new package-quickstart feature has made the module largely unnecessary. Either way, I regard it as a personal experiment. Re: the name, I chose 'realpath' because the original implementation was just that: a wrapper around realpath(3). It was only in a later version that I switched to using canonicalize_file_name(3) instead. Perhaps a better name would have been 'truename' or similar, but I don't think this is important enough a matter to justify renaming it now. Do you? The reason I submitted this bug report is because I don't know whether the switch --module-assertions has unveiled an issue in my module or Emacs' module implementation. -- Basil From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 26 10:27:30 2019 Received: (at 34655) by debbugs.gnu.org; 26 Feb 2019 15:27:30 +0000 Received: from localhost ([127.0.0.1]:53200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyedm-0006al-Ah for submit@debbugs.gnu.org; Tue, 26 Feb 2019 10:27:30 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56974) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyedk-0006aY-Ta for 34655@debbugs.gnu.org; Tue, 26 Feb 2019 10:27:29 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34498) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gyede-0005kq-Hf; Tue, 26 Feb 2019 10:27:23 -0500 Received: from [176.228.60.248] (port=3932 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gyedX-0004Nv-KF; Tue, 26 Feb 2019 10:27:16 -0500 Date: Tue, 26 Feb 2019 17:27:30 +0200 Message-Id: <83a7iimuxp.fsf@gnu.org> From: Eli Zaretskii To: "Basil L. Contovounesios" In-reply-to: <87h8cqre8n.fsf@tcd.ie> (contovob@tcd.ie) Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> <87h8cqre8n.fsf@tcd.ie> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: 34655@debbugs.gnu.org, rms@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: "Basil L. Contovounesios" > Date: Tue, 26 Feb 2019 11:16:56 +0000 > Cc: 34655@debbugs.gnu.org > > The reason I submitted this bug report is because I don't know whether > the switch --module-assertions has unveiled an issue in my module or > Emacs' module implementation. So without using --module-assertions the crash doesn't happen, is that what you are saying? From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 26 10:45:16 2019 Received: (at 34655) by debbugs.gnu.org; 26 Feb 2019 15:45:16 +0000 Received: from localhost ([127.0.0.1]:53228 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyeux-00072i-R9 for submit@debbugs.gnu.org; Tue, 26 Feb 2019 10:45:16 -0500 Received: from eggs.gnu.org ([209.51.188.92]:32844) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyeuw-00072U-Ix for 34655@debbugs.gnu.org; Tue, 26 Feb 2019 10:45:15 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34729) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gyeur-0007K6-35; Tue, 26 Feb 2019 10:45:09 -0500 Received: from [176.228.60.248] (port=1367 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gyeuq-0001FO-LO; Tue, 26 Feb 2019 10:45:08 -0500 Date: Tue, 26 Feb 2019 17:45:21 +0200 Message-Id: <8336oamu3y.fsf@gnu.org> From: Eli Zaretskii To: "Basil L. Contovounesios" In-reply-to: <874l8r1t3a.fsf@tcd.ie> (contovob@tcd.ie) Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: 34655@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: "Basil L. Contovounesios" > Date: Mon, 25 Feb 2019 21:00:41 +0000 > > Starting program: /home/blc/.local/src/emacs26/src/emacs -Q --module-assertions > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > [New Thread 0x7ffff01cb700 (LWP 8299)] > [New Thread 0x7fffef9ac700 (LWP 8300)] > [New Thread 0x7fffef1ab700 (LWP 8301)] > > Thread 1 "emacs" received signal SIGSEGV, Segmentation fault. > re_search_2 (bufp=0xbf5d00 , str1=0x0, size1=0, str2=0x0, size2=18, startpos=0, > range=18, regs=0x0, stop=18) at regex.c:4354 > 4354 buf_ch = STRING_CHAR_AND_LENGTH (d, buf_charlen); > #0 0x0000000000608594 in re_search_2 > (bufp=0xbf5d00 , str1=0x0, size1=0, str2=0x0, size2=18, startpos=0, range=18, regs=0x0, stop=18) at regex.c:4354 > buf_charlen = 0 > irange = 18 > lim = 0 > d = 0x0 > buf_ch = 18 > val = 691541629 > string1 = 0x0 > string2 = 0x0 > fastmap = 0xbf5d38 "" > translate = make_number(0) > total_size = 18 > endpos = 18 > anchored_start = 0 '\000' > multibyte = 1 '\001' > #1 0x0000000000607f91 in re_search > (bufp=0xbf5d00 , string=0x0, size=18, startpos=0, range=18, regs=0x0) > at regex.c:4181 > #2 0x00000000005f3fd0 in fast_string_match_internal > (regexp=XIL(0x8c761c), string=XIL(0x3036ec4), table=XIL(0)) at search.c:485 > val = 140737488336288 > bufp = 0xbf5d00 Here's your problem: fast_string_match_internal got a Lisp string=XIL(0x3036ec4), but its data passed to re_search as the 2nd arg is a NULL pointer. You need to find out how this happens, e.g. by setting a watchpoint on string's data inside Ffile_name_as_directory. Or maybe the string is already corrupted there? From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 26 13:42:41 2019 Received: (at 34655) by debbugs.gnu.org; 26 Feb 2019 18:42:41 +0000 Received: from localhost ([127.0.0.1]:53298 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyhge-0002k5-Se for submit@debbugs.gnu.org; Tue, 26 Feb 2019 13:42:41 -0500 Received: from mail-ed1-f46.google.com ([209.85.208.46]:34894) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyhgd-0002js-A9 for 34655@debbugs.gnu.org; Tue, 26 Feb 2019 13:42:40 -0500 Received: by mail-ed1-f46.google.com with SMTP id g19so11664758edp.2 for <34655@debbugs.gnu.org>; Tue, 26 Feb 2019 10:42:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=Omve0DKSrOTfz+gN8md+QgLZMjbm6FK+DI7UeFSUr78=; b=1k/bMFNN8Q9sjRSdJTooO3rxUWX0dZHTjWcowPJtFeb1MKnFGipd0me3TJuyM0nXIJ vTjOmOvHxwBFfMG2cF1v3J1Jt307Hobh8IFt54X+FndFPmLAdqurBYFzeSyUB/NlvvbF J6/6Xw+cLA53XAbhpvUSOcUmBdZcFwKTKZUG/8iVAml+FdIL0Tzl4daKqeVSrfkZJHRi VE723I+g7dQSuB+vhGELSEm127o13cLDv1um1Py8IvpvhrqUIlGb93xIIyhox7ldHMVW SeKItuQkVJRWFaNXC+nCTjLJRWhXF6u9B+SbykFn44zf2117wxLDF/3iYSp22fMGEeRC lLIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=Omve0DKSrOTfz+gN8md+QgLZMjbm6FK+DI7UeFSUr78=; b=JiIrD9l5J+FR+lny34QBjoY3/LQ4MVoGlwKG3aMQsPCXEEsScTK7YgVOUmMb2rvEaI Cfp/354B1POqVZf8e4WnLdS4MEy1bEIriFdGO392F9T2LvxYO+g4C4GTuoSThSgaCO/2 MZyKNP1TFKCBfQvaOOTmX9EHu7iOk34jnXUU5AFmrMTxxu2z++xZSrnEkePObVAPSv3N v9vJvmqHg3gu07XNjJ+vT40UJzmdzG1Wogt+kD0S9gELZ7nsTZICUsL+3DRcoRGs5lo0 wVbjYIQHJg3+4Xr/YPIURZPTd5sXCCEsOCakH8Sj26XxBIKpY53TJPEStS056sVKarAi 41hQ== X-Gm-Message-State: AHQUAua4s3pD0aqBQQwca3yxd3qXdhI2fUhvpqe1Iz19dBKFOCzqbsr5 PCnpAfXyvR5ej0VpM9gmbXRg0w== X-Google-Smtp-Source: AHgI3IbizMhwCgfpDtUcHJMX5gy8j/m2nngslwgc1zm+65AB3+MtlkjOSrVruC066Z27EUq6lrJLFg== X-Received: by 2002:a17:906:6a49:: with SMTP id n9mr2422667ejs.30.1551206553330; Tue, 26 Feb 2019 10:42:33 -0800 (PST) Received: from localhost ([134.226.214.248]) by smtp.gmail.com with ESMTPSA id u21sm2340835ejm.45.2019.02.26.10.42.32 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 26 Feb 2019 10:42:32 -0800 (PST) From: "Basil L. Contovounesios" To: Eli Zaretskii Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> <87h8cqre8n.fsf@tcd.ie> <83a7iimuxp.fsf@gnu.org> Date: Tue, 26 Feb 2019 18:42:29 +0000 In-Reply-To: <83a7iimuxp.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 26 Feb 2019 17:27:30 +0200") Message-ID: <8736oaqtm2.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: 34655@debbugs.gnu.org, rms@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: "Basil L. Contovounesios" >> Date: Tue, 26 Feb 2019 11:16:56 +0000 >> Cc: 34655@debbugs.gnu.org >> >> The reason I submitted this bug report is because I don't know whether >> the switch --module-assertions has unveiled an issue in my module or >> Emacs' module implementation. > > So without using --module-assertions the crash doesn't happen, is that > what you are saying? Yes. I can't guarantee the crash doesn't happen without --module-assertions of course, but in my tests it only seems to crop up with the switch (and reliably so). -- Basil From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 26 23:10:19 2019 Received: (at 34655) by debbugs.gnu.org; 27 Feb 2019 04:10:19 +0000 Received: from localhost ([127.0.0.1]:53437 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyqXz-0007uX-4X for submit@debbugs.gnu.org; Tue, 26 Feb 2019 23:10:19 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57104) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyqXw-0007u7-W0 for 34655@debbugs.gnu.org; Tue, 26 Feb 2019 23:10:17 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43791) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gyqXr-0001ey-NX; Tue, 26 Feb 2019 23:10:11 -0500 Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1gyqXr-0000BU-Jp; Tue, 26 Feb 2019 23:10:11 -0500 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: "Basil L. Contovounesios" In-Reply-To: <87h8cqre8n.fsf@tcd.ie> (contovob@tcd.ie) Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> <87h8cqre8n.fsf@tcd.ie> Message-Id: Date: Tue, 26 Feb 2019 23:10:11 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: 34655@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) [[[ 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. ]]] > Re: the name, I chose 'realpath' because the original implementation was > just that: a wrapper around realpath(3). It was only in a later version > that I switched to using canonicalize_file_name(3) instead. Perhaps a > better name would have been 'truename' or similar, but I don't think > this is important enough a matter to justify renaming it now. Do you? If you don't think it is worth publicizing, and you don't really want to use it, I won't claim that minor fixes in it are important. A good name might be nonmagic-file-truename -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 17 12:39:16 2019 Received: (at 34655) by debbugs.gnu.org; 17 Mar 2019 16:39:16 +0000 Received: from localhost ([127.0.0.1]:47693 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h5Yod-00057h-02 for submit@debbugs.gnu.org; Sun, 17 Mar 2019 12:39:16 -0400 Received: from mail-ed1-f48.google.com ([209.85.208.48]:46672) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h5YoZ-00057P-12 for 34655@debbugs.gnu.org; Sun, 17 Mar 2019 12:39:13 -0400 Received: by mail-ed1-f48.google.com with SMTP id n17so11495048edt.13 for <34655@debbugs.gnu.org>; Sun, 17 Mar 2019 09:39:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version; bh=949F/Do/GG8JI3X8doA74MWTMVZFvpGLREwAeYqgeKg=; b=RI4gr9jTZ13Bu3RnTcwGXF+qRyXMS6WurcCtEeY57h8/yi7tpVf4NrV+rMBXemaTge McY/HpIfpDtw/MvpikZT9+9LDMGQljoqKxUGeZdZyQs6PLzbSQsbGKwVYJogtZE4jMhj yxBN35yS3rucxeKWcogYbeWx3+i++SM6xE+FKGLPGKDOA5s2G3x7L1TuQPtsjqWErKFm fzJjh4cVM0DYqHFW7l0evhTfFBhCjPIhC1I7GTtB3PDPS+h1/POaqY4RBCByqWfVoXzC 2MN568GppPXYCncmrrlTQ4LjRJsA8fkdUo/LP+iIVLKpI1FLi81ct3UvhObyExc87YrI 6t2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:message-id :user-agent:mime-version; bh=949F/Do/GG8JI3X8doA74MWTMVZFvpGLREwAeYqgeKg=; b=Bp/QWWBjMWldxEpkSX0Eh4pmpfX/34PXygEqL/1/7NjdAM00HYCgrfv+y+HTyiVEaD VSArnUpYysFExhey5GMRtZm5ubwoN4l7jmja09vWvJpm/ZFdrjjBIvrLPWEYOjVzyzel Z20N+s1kQgj+Nb1vhNNu3+1n4qYjzHLqr4258zgxtx3+Q1p7scyFc2QpC5Q7YYmvaGrg zRHIRXhB1YM4ZIHmisiEdqpGdqkiNafM5btdiefHZj71g4azvbqvzGEyN6JYMDbUfJ/S wY+w0B8vruRnKn/D7tNUkLVwjlD3Yx7Q80CahBMETuyBfGIzRZ+DTjZGqFfs33jaQ3zR 8d4A== X-Gm-Message-State: APjAAAXQ16IUkpEEoj9aWS6fwxFfSx+powW2ha+WfmT0loShjdr0SVc2 pHxdY9DVrrKoiVgS9Ahma2g5Kw== X-Google-Smtp-Source: APXvYqwHm321xAeEiC5GDKGoz756ApnECCm0ucIdKocOZnZbl1R8aC37CAqOsJ88NeRQZ/YYE9JvOQ== X-Received: by 2002:a50:b8e2:: with SMTP id l89mr10202583ede.140.1552840745215; Sun, 17 Mar 2019 09:39:05 -0700 (PDT) Received: from localhost ([2a02:8084:20e2:c380:f786:805d:f4ab:1006]) by smtp.gmail.com with ESMTPSA id f5sm2629983edt.36.2019.03.17.09.39.03 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sun, 17 Mar 2019 09:39:03 -0700 (PDT) From: "Basil L. Contovounesios" To: Eli Zaretskii Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> Date: Sun, 17 Mar 2019 16:38:58 +0000 Message-ID: <87h8c1cv6l.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: 34655@debbugs.gnu.org, Philipp Stephani X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=gdb.txt Content-Transfer-Encoding: quoted-printable Starting program: /home/blc/.local/src/emacs26/src/emacs -Q --module-assert= ions [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff07c1700 (LWP 31458)] [New Thread 0x7fffefe12700 (LWP 31459)] [New Thread 0x7fffef481700 (LWP 31460)] Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=3D6, backtr= ace_limit=3D2147483647) at emacs.c:364 364 signal (sig, SIG_DFL); #0 0x0000000000584d53 in terminate_due_to_signal (sig=3D6, backtrace_limit= =3D2147483647) at emacs.c:364 #1 0x000000000061bfdf in die (msg=3D0x786cf2 "STRINGP (*p) && SSDATA (*p)", file=3D0x7869a0 "emacs-m= odule.c", line=3D984) at alloc.c:7406 #2 0x00000000006854ce in value_to_lisp (v=3D0x3059c90) at emacs-module.c:9= 84 p =3D 0x3059c90 values =3D XIL(0x2fb6243) env =3D 0x3059b70 environments =3D XIL(0x2fb6353) vptr =3D 0x3059c90 optr =3D 0x3059c90 num_environments =3D 0 num_values =3D 3 b =3D true o =3D XIL(0x7fffffffb5b0) #3 0x0000000000682ad6 in module_funcall (env=3D0x3059b70, fun=3D0x2e52d60, nargs=3D1, args=3D0x7fffffffb728) at emacs-module.c:480 i =3D 0 internal_handler_CONDITION_CASE =3D 0x2c802a0 internal_cleanup_CONDITION_CASE =3D 0x2c802a0 internal_handler_CATCHER_ALL =3D 0x2c7f9c0 internal_cleanup_CATCHER_ALL =3D 0x2c7f9c0 newargs =3D 0x7fffffffb5e0 sa_avail =3D 16368 sa_count =3D 23 sa_must_free =3D false nargs1 =3D 2 result =3D 0x7fffffffb6a0 #4 0x00007fffee809263 in rp_funcall (env=3D0x3059b70, value=3D0x7fffffffb728, name=3D0x7fffee80a02d "file-n= ame-as-directory", nargs=3D1, args=3D0x7fffffffb728) at realpath.c:62 #5 0x00007fffee80951e in Frealpath_truename (env=3D0x3059b70, nargs=3D1, args=3D0x7fffffffb750, data=3D0x0) at real= path.c:127 file =3D 0x3059c90 dir =3D 0x2e3db80 obuf =3D 0x3059c70 "/home/blc/.emacs.d/" nbuf =3D 0x3059ce0 "/home/blc/.emacs.d" #6 0x0000000000684eb8 in funcall_module (function=3DXIL(0x2cd8fc5), nargs=3D1, arglist=3D0x7fffffffb990) at ema= cs-module.c:788 func =3D 0x2cd8fc0 pub =3D { size =3D 140737488336824,=20 private_members =3D 0x7ffff6c43760,=20 make_global_ref =3D 0x2c85380,=20 free_global_ref =3D 0x0,=20 non_local_exit_check =3D 0x7fffffffb830,=20 non_local_exit_clear =3D 0x8ec8b95782e18b00,=20 non_local_exit_get =3D 0x2c85380,=20 non_local_exit_signal =3D 0x2c85380,=20 non_local_exit_throw =3D 0x7fffffffb840,=20 make_function =3D 0xc17f20 ,=20 funcall =3D 0x42,=20 intern =3D 0xcea0,=20 type_of =3D 0x7fffffffb820,=20 is_not_nil =3D 0x57e6cb ,=20 eq =3D 0x7fffffffb840,=20 extract_integer =3D 0x44e01043390,=20 make_integer =3D 0x7fffffffb860,=20 extract_float =3D 0x61f56e ,=20 make_float =3D 0x7fffffffb840,=20 copy_string_contents =3D 0x438310 ,=20 make_string =3D 0x7fffffffb860,=20 make_user_ptr =3D 0x8096c4 ,=20 get_user_ptr =3D 0x580dca ,=20 set_user_ptr =3D 0x0,=20 get_user_finalizer =3D 0x7fffffffb980,=20 set_user_finalizer =3D 0x642070 ,=20 vec_get =3D 0x7fffffffb890,=20 vec_set =3D 0x438310 ,=20 vec_size =3D 0x2d94b15,=20 should_quit =3D 0x7e4480 } priv =3D { pending_non_local_exit =3D emacs_funcall_exit_return,=20 non_local_exit_symbol =3D XIL(0),=20 non_local_exit_data =3D XIL(0),=20 values =3D XIL(0xc9a023) } env =3D 0x3059b70 count =3D 22 sa_avail =3D 16376 sa_count =3D 23 sa_must_free =3D false args =3D 0x7fffffffb750 ret =3D 0x1100463791 #7 0x0000000000644baa in funcall_lambda (fun=3DXIL(0x2cd8fc5), nargs=3D1, = arg_vector=3D0x7fffffffb990) at eval.c:2987 val =3D XIL(0x648c9c) syms_left =3D XIL(0x7fffffffb990) next =3D XIL(0x21055d0) lexenv =3D XIL(0x580de9) count =3D 22 i =3D 34624976 optional =3D false rest =3D false previous_optional_or_rest =3D false #8 0x00000000006447f1 in apply_lambda (fun=3DXIL(0x2cd8fc5), args=3DXIL(0x= 1295563), count=3D21) at eval.c:2913 args_left =3D XIL(0) i =3D 1 numargs =3D 1 arg_vector =3D 0x7fffffffb990 tem =3D XIL(0x8096c4) sa_avail =3D 16376 sa_count =3D 22 sa_must_free =3D false #9 0x00000000006429c9 in eval_sub (form=3DXIL(0x1295573)) at eval.c:2286 fun =3D XIL(0x2cd8fc5) val =3D XIL(0x3057534) original_fun =3D XIL(0x21055d0) original_args =3D XIL(0x1295563) funcar =3D XIL(0x2d6f6f1) count =3D 21 argvals =3D {XIL(0x7fffffffbae0), XIL(0x1293903), XIL(0x2105600), X= IL(0x2d4e000), XIL(0x41f2b0), make_number(0), XIL(0x10), make_number(2)} #10 0x000000000063cef2 in Fprogn (body=3DXIL(0x129a7d3)) at eval.c:459 form =3D XIL(0x1295573) val =3D XIL(0x3057534) #11 0x000000000063cf24 in prog_ignore (body=3DXIL(0x129a773)) at eval.c:470 #12 0x000000000063f11c in Fwhile (args=3DXIL(0x129a6c3)) at eval.c:992 test =3D XIL(0x1293903) body =3D XIL(0x129a773) #13 0x0000000000642382 in eval_sub (form=3DXIL(0x129a663)) at eval.c:2193 args_left =3D XIL(0x129a6c3) numargs =3D make_number(4) fun =3D XIL(0xb90f45) val =3D XIL(0x7fffffffbca0) original_fun =3D XIL(0xae0a0) original_args =3D XIL(0x129a6c3) funcar =3D XIL(0xc0b080) count =3D 20 argvals =3D {XIL(0), XIL(0), XIL(0x2e3dad0), XIL(0), XIL(0x7fffffff= bde0), XIL(0x684c6c), XIL(0x7fffffffbc80), XIL(0x2e501b4)} #14 0x000000000063cef2 in Fprogn (body=3DXIL(0)) at eval.c:459 form =3D XIL(0x129a663) val =3D XIL(0) #15 0x000000000063f03c in Flet (args=3DXIL(0x129a5d3)) at eval.c:973 temps =3D 0x7fffffffbd20 tem =3D make_number(0) lexenv =3D XIL(0) elt =3D XIL(0x1293a03) varlist =3D XIL(0) count =3D 18 argnum =3D 2 sa_avail =3D 16368 sa_count =3D 18 sa_must_free =3D false varlist_len =3D 2 nvars =3D 2 #16 0x0000000000642382 in eval_sub (form=3DXIL(0x129a5c3)) at eval.c:2193 args_left =3D XIL(0x129a5d3) numargs =3D make_number(2) fun =3D XIL(0xb90f05) val =3D XIL(0xc2a0) original_fun =3D XIL(0x83a0) original_args =3D XIL(0x129a5d3) funcar =3D XIL(0x57e6cb) count =3D 17 argvals =3D {XIL(0x2e501b4), XIL(0), make_number(0), XIL(0xc0a7a0),= XIL(0x7fffffffbe80), XIL(0xc0b080), XIL(0x7fffffffbf00), XIL(0)} #17 0x000000000063cef2 in Fprogn (body=3DXIL(0)) at eval.c:459 form =3D XIL(0x129a5c3) val =3D XIL(0xc2a0) #18 0x0000000000642382 in eval_sub (form=3DXIL(0x1299623)) at eval.c:2193 args_left =3D XIL(0x1299613) numargs =3D make_number(2) fun =3D XIL(0xb90bc5) val =3D XIL(0x1105280) original_fun =3D XIL(0xa920) original_args =3D XIL(0x1299613) funcar =3D make_number(1644217) count =3D 16 argvals =3D {XIL(0x7fffffffbfb0), XIL(0xc0a7a0), XIL(0xc9e400), XIL= (0), XIL(0x7fffffffbfd0), XIL(0xc12a90), XIL(0x580b87), XIL(0)} #19 0x0000000000641d39 in Feval (form=3DXIL(0x1299623), lexical=3DXIL(0)) a= t eval.c:2061 count =3D 15 #20 0x0000000000644464 in funcall_subr (subr=3D0xb911c0 , numargs=3D= 2, args=3D0x7fffffffc210) at eval.c:2853 internal_argbuf =3D {XIL(0xb911c0), XIL(0x7fffffffc0f8), make_numbe= r(1440909), XIL(0xa00c0b080), XIL(0xb911c5), XIL(0x7fffffffc118), XIL(0xb91= 1c0), XIL(0x7fffffffc110)} internal_args =3D 0x7fffffffc210 #21 0x0000000000643f75 in Ffuncall (nargs=3D3, args=3D0x7fffffffc208) at ev= al.c:2776 fun =3D XIL(0xb911c5) original_fun =3D XIL(0x53a0) funcar =3D make_number(1604955) numargs =3D 2 val =3D XIL(0x7fffffffc190) count =3D 14 #22 0x000000000069985f in exec_byte_code (bytestr=3DXIL(0x94686c), vector= =3DXIL(0x94688d), maxdepth=3Dmake_number(16), args_template=3Dmake_number(2= 57), nargs=3D1, args=3D0x7fffffffc6b0) at bytecode.c:630 op =3D 2 type =3D CATCHER targets =3D {0x69c7ce , 0x69c7f3 , 0x69c7f5 , 0x69c7f7 , 0x69c7f9 , 0x69c7f9 , 0x69c8= 5e , 0x69c8d2 , 0x698f99 , 0x698f9b , 0x698f9d , 0x698f9f , 0x698fa1 , 0x698= fa1 , 0x698fa7 , 0x698f68 , 0x69946d , 0x69946f , 0x699471 , 0x699473 , 0x6994= 75 , 0x699475 , 0x6994aa , 0x69947b , 0x69977c , 0x69977e , 0x699780 , 0x69978= 2 , 0x699784 , 0x699784 , 0x699736 , 0x69974d , 0x69982c , 0x69982e , 0x699830= , 0x699832 , 0x699834 , 0x699834 , 0x6997e6 = , 0x6997fd , 0x6998e1 , 0x6998e3 = , 0x6998e5 , 0x6998e7 , 0x6998e9 , 0x6998e9 ,= 0x69989b , 0x6998b2 , 0x69a140 <= exec_byte_code+5819>, 0x69a026 , 0x69a01d , 0x69c7ce , 0x69c7ce = , 0x69c7ce , 0x69c7ce , 0x69c7c= e , 0x69a371 , 0x69a490 , 0x69a4fa , 0x69a565 , 0x69a5d1 , 0x6992c0 , 0x69934= 5 , 0x69a652 , 0x699201 , 0x6993ad , 0x69a6c4 , 0x69a72c , 0x69a774 , 0x69a7dc= , 0x69a82e , 0x69a8ff , 0x69a947 , 0x69a9af = , 0x69aa34 , 0x69aa7c , 0x69aac4 = , 0x69ab2c , 0x69ab94 , 0x69abfc , 0x69ac81 ,= 0x69acd3 , 0x69ad25 , 0x69adf6 <= exec_byte_code+9073>, 0x69ae70 , 0x69aeea , 0x69b0b6 , 0x69b123 , = 0x69b190 , 0x69b1fd , 0x69b26a <= exec_byte_code+10213>, 0x69b2bc , 0x69b33a , 0x69b38c , 0x69b3de , 0x69b430 , 0x69b53c , 0x69= 9ea0 , 0x69b59a , 0x69b5e2 , 0x69b6ae , 0x69b717 , 0x69b775 , 0x69b7bd ,= 0x69b803 , 0x69b849 , 0x69b897= , 0x69c7ce , 0x69b8ef , 0x69b935 , 0x69b97b , 0x69b9c1 , 0x69ba07 , 0x= 69ba4d , 0x699ea0 , 0x69c7ce , 0x69ba95 , 0x69baea , 0x69bb32 , 0x69bb7a , 0x69bbe2 , 0x69bc4a , 0x69bc= 92 , 0x69bdac , 0x69be14 , 0x69be7c , 0x69bee4 , 0x69bf2a , 0x69c7ce , = 0x699dd4 , 0x699998 , 0x699172 , 0x699a44 , 0x699ac5 , 0x699b43 , 0x699d88 , 0= x699d9d , 0x6996e3 , 0x699e57 , 0x699ed7 , 0x699f65 , 0x699fae , 0x69a18c , 0x= 69a209 , 0x69a28e , 0x69a2ee , 0x69994a , 0x69bf72 , 0x69bff7 , 0x69c03f , = 0x69c087 , 0x69c0cf , 0x69c117 = , 0x69c17f , 0x69c1e7 , 0x69c24f , 0x69c2b7 , 0x69c42d , 0x69c495 , 0x6= 9c4fd , 0x69c545 , 0x69c5ad , 0x69c615 , 0x69c65d , 0x69c6a5 , 0x69b482 , 0x69b4d4 , 0x69c6f7 , 0x69c7= 63 , 0x69c7ce , 0x699bc1 , 0x699bde , 0x699c4a , 0x699cb6 , 0x699d1f , 0x69a= 880 , 0x69ad77 , 0x69b62f , 0x69c965 , 0x69c9da , 0x69c7ce , 0x69c7ce , 0= x69ca70 , 0x69caf7 , 0x69c7ce <= exec_byte_code+15689>, 0x69c7ce , 0x69c7ce , 0x69c7ce , 0x69c7ce , 0x69c7ce , 0x69c7ce , 0x69= c7ce , 0x69cd0b } const_length =3D 7 bytestr_length =3D 43 vectorp =3D 0x946890 quitcounter =3D 1 '\001' stack_items =3D 17 sa_avail =3D 16205 sa_count =3D 14 sa_must_free =3D false stack_base =3D 0x7fffffffc1a0 stack_lim =3D 0x7fffffffc228 top =3D 0x7fffffffc208 void_stack_lim =3D 0x7fffffffc228 bytestr_data =3D 0x7fffffffc228 "\301\001!\211@\001A\211@\001A\211@= \001A\001\004\006\a\302\303\304\305 !\b\"\002\203#" pc =3D 0x7fffffffc243 "\002\203#" count =3D 14 result =3D XIL(0) #23 0x0000000000644b6f in funcall_lambda (fun=3DXIL(0x94683d), nargs=3D1, a= rg_vector=3D0x7fffffffc6a8) at eval.c:2977 size =3D 5 val =3D XIL(0x7fffffffc608) syms_left =3D make_number(257) next =3D XIL(0x1200c0b080) lexenv =3D XIL(0x7fffffffc5e0) count =3D 14 i =3D 0 optional =3D false rest =3D false previous_optional_or_rest =3D false #24 0x0000000000643fb9 in Ffuncall (nargs=3D2, args=3D0x7fffffffc6a0) at ev= al.c:2778 fun =3D XIL(0x94683d) original_fun =3D XIL(0xa39960) funcar =3D XIL(0x645e21) numargs =3D 1 val =3D XIL(0x7fffffffc680) count =3D 13 #25 0x000000000069985f in exec_byte_code (bytestr=3DXIL(0x946b0c), vector= =3DXIL(0x946b2d), maxdepth=3Dmake_number(4), args_template=3Dmake_number(25= 7), nargs=3D1, args=3D0x7fffffffcb30) at bytecode.c:630 op =3D 1 type =3D (unknown: 12114688) targets =3D {0x69c7ce , 0x69c7f3 , 0x69c7f5 , 0x69c7f7 , 0x69c7f9 , 0x69c7f9 , 0x69c8= 5e , 0x69c8d2 , 0x698f99 , 0x698f9b , 0x698f9d , 0x698f9f , 0x698fa1 , 0x698= fa1 , 0x698fa7 , 0x698f68 , 0x69946d , 0x69946f , 0x699471 , 0x699473 , 0x6994= 75 , 0x699475 , 0x6994aa , 0x69947b , 0x69977c , 0x69977e , 0x699780 , 0x69978= 2 , 0x699784 , 0x699784 , 0x699736 , 0x69974d , 0x69982c , 0x69982e , 0x699830= , 0x699832 , 0x699834 , 0x699834 , 0x6997e6 = , 0x6997fd , 0x6998e1 , 0x6998e3 = , 0x6998e5 , 0x6998e7 , 0x6998e9 , 0x6998e9 ,= 0x69989b , 0x6998b2 , 0x69a140 <= exec_byte_code+5819>, 0x69a026 , 0x69a01d , 0x69c7ce , 0x69c7ce = , 0x69c7ce , 0x69c7ce , 0x69c7c= e , 0x69a371 , 0x69a490 , 0x69a4fa , 0x69a565 , 0x69a5d1 , 0x6992c0 , 0x69934= 5 , 0x69a652 , 0x699201 , 0x6993ad , 0x69a6c4 , 0x69a72c , 0x69a774 , 0x69a7dc= , 0x69a82e , 0x69a8ff , 0x69a947 , 0x69a9af = , 0x69aa34 , 0x69aa7c , 0x69aac4 = , 0x69ab2c , 0x69ab94 , 0x69abfc , 0x69ac81 ,= 0x69acd3 , 0x69ad25 , 0x69adf6 <= exec_byte_code+9073>, 0x69ae70 , 0x69aeea , 0x69b0b6 , 0x69b123 , = 0x69b190 , 0x69b1fd , 0x69b26a <= exec_byte_code+10213>, 0x69b2bc , 0x69b33a , 0x69b38c , 0x69b3de , 0x69b430 , 0x69b53c , 0x69= 9ea0 , 0x69b59a , 0x69b5e2 , 0x69b6ae , 0x69b717 , 0x69b775 , 0x69b7bd ,= 0x69b803 , 0x69b849 , 0x69b897= , 0x69c7ce , 0x69b8ef , 0x69b935 , 0x69b97b , 0x69b9c1 , 0x69ba07 , 0x= 69ba4d , 0x699ea0 , 0x69c7ce , 0x69ba95 , 0x69baea , 0x69bb32 , 0x69bb7a , 0x69bbe2 , 0x69bc4a , 0x69bc= 92 , 0x69bdac , 0x69be14 , 0x69be7c , 0x69bee4 , 0x69bf2a , 0x69c7ce , = 0x699dd4 , 0x699998 , 0x699172 , 0x699a44 , 0x699ac5 , 0x699b43 , 0x699d88 , 0= x699d9d , 0x6996e3 , 0x699e57 , 0x699ed7 , 0x699f65 , 0x699fae , 0x69a18c , 0x= 69a209 , 0x69a28e , 0x69a2ee , 0x69994a , 0x69bf72 , 0x69bff7 , 0x69c03f , = 0x69c087 , 0x69c0cf , 0x69c117 = , 0x69c17f , 0x69c1e7 , 0x69c24f , 0x69c2b7 , 0x69c42d , 0x69c495 , 0x6= 9c4fd , 0x69c545 , 0x69c5ad , 0x69c615 , 0x69c65d , 0x69c6a5 , 0x69b482 , 0x69b4d4 , 0x69c6f7 , 0x69c7= 63 , 0x69c7ce , 0x699bc1 , 0x699bde , 0x699c4a , 0x699cb6 , 0x699d1f , 0x69a= 880 , 0x69ad77 , 0x69b62f , 0x69c965 , 0x69c9da , 0x69c7ce , 0x69c7ce , 0= x69ca70 , 0x69caf7 , 0x69c7ce <= exec_byte_code+15689>, 0x69c7ce , 0x69c7ce , 0x69c7ce , 0x69c7ce , 0x69c7ce , 0x69c7ce , 0x69= c7ce , 0x69cd0b } const_length =3D 4 bytestr_length =3D 29 vectorp =3D 0x946b30 quitcounter =3D 1 '\001' stack_items =3D 5 sa_avail =3D 16315 sa_count =3D 12 sa_must_free =3D false stack_base =3D 0x7fffffffc690 stack_lim =3D 0x7fffffffc6b8 top =3D 0x7fffffffc6a0 void_stack_lim =3D 0x7fffffffc6b8 bytestr_data =3D 0x7fffffffc6b8 "\b\204\b" pc =3D 0x7fffffffc6c5 "\n)B\211A\t=3D\204\032" count =3D 12 result =3D XIL(0x7fffffffc950) #26 0x0000000000644b6f in funcall_lambda (fun=3DXIL(0x946acd), nargs=3D1, a= rg_vector=3D0x7fffffffcb28) at eval.c:2977 size =3D 6 val =3D XIL(0x7fffffffca88) syms_left =3D make_number(257) next =3D XIL(0x1200c0b080) lexenv =3D make_number(1440909) count =3D 12 i =3D 0 optional =3D false rest =3D false previous_optional_or_rest =3D false #27 0x0000000000643fb9 in Ffuncall (nargs=3D2, args=3D0x7fffffffcb20) at ev= al.c:2778 fun =3D XIL(0x946acd) original_fun =3D XIL(0x4dd0a0) funcar =3D XIL(0xc0b080) numargs =3D 1 val =3D XIL(0xc2a0) count =3D 11 #28 0x000000000069985f in exec_byte_code (bytestr=3DXIL(0x94602c), vector= =3DXIL(0x94604d), maxdepth=3Dmake_number(3), args_template=3Dmake_number(25= 6), nargs=3D1, args=3D0x7fffffffd0c8) at bytecode.c:630 op =3D 1 type =3D (unknown: 12133568) targets =3D {0x69c7ce , 0x69c7f3 , 0x69c7f5 , 0x69c7f7 , 0x69c7f9 , 0x69c7f9 , 0x69c8= 5e , 0x69c8d2 , 0x698f99 , 0x698f9b , 0x698f9d , 0x698f9f , 0x698fa1 , 0x698= fa1 , 0x698fa7 , 0x698f68 , 0x69946d , 0x69946f , 0x699471 , 0x699473 , 0x6994= 75 , 0x699475 , 0x6994aa , 0x69947b , 0x69977c , 0x69977e , 0x699780 , 0x69978= 2 , 0x699784 , 0x699784 , 0x699736 , 0x69974d , 0x69982c , 0x69982e , 0x699830= , 0x699832 , 0x699834 , 0x699834 , 0x6997e6 = , 0x6997fd , 0x6998e1 , 0x6998e3 = , 0x6998e5 , 0x6998e7 , 0x6998e9 , 0x6998e9 ,= 0x69989b , 0x6998b2 , 0x69a140 <= exec_byte_code+5819>, 0x69a026 , 0x69a01d , 0x69c7ce , 0x69c7ce = , 0x69c7ce , 0x69c7ce , 0x69c7c= e , 0x69a371 , 0x69a490 , 0x69a4fa , 0x69a565 , 0x69a5d1 , 0x6992c0 , 0x69934= 5 , 0x69a652 , 0x699201 , 0x6993ad , 0x69a6c4 , 0x69a72c , 0x69a774 , 0x69a7dc= , 0x69a82e , 0x69a8ff , 0x69a947 , 0x69a9af = , 0x69aa34 , 0x69aa7c , 0x69aac4 = , 0x69ab2c , 0x69ab94 , 0x69abfc , 0x69ac81 ,= 0x69acd3 , 0x69ad25 , 0x69adf6 <= exec_byte_code+9073>, 0x69ae70 , 0x69aeea , 0x69b0b6 , 0x69b123 , = 0x69b190 , 0x69b1fd , 0x69b26a <= exec_byte_code+10213>, 0x69b2bc , 0x69b33a , 0x69b38c , 0x69b3de , 0x69b430 , 0x69b53c , 0x69= 9ea0 , 0x69b59a , 0x69b5e2 , 0x69b6ae , 0x69b717 , 0x69b775 , 0x69b7bd ,= 0x69b803 , 0x69b849 , 0x69b897= , 0x69c7ce , 0x69b8ef , 0x69b935 , 0x69b97b , 0x69b9c1 , 0x69ba07 , 0x= 69ba4d , 0x699ea0 , 0x69c7ce , 0x69ba95 , 0x69baea , 0x69bb32 , 0x69bb7a , 0x69bbe2 , 0x69bc4a , 0x69bc= 92 , 0x69bdac , 0x69be14 , 0x69be7c , 0x69bee4 , 0x69bf2a , 0x69c7ce , = 0x699dd4 , 0x699998 , 0x699172 , 0x699a44 , 0x699ac5 , 0x699b43 , 0x699d88 , 0= x699d9d , 0x6996e3 , 0x699e57 , 0x699ed7 , 0x699f65 , 0x699fae , 0x69a18c , 0x= 69a209 , 0x69a28e , 0x69a2ee , 0x69994a , 0x69bf72 , 0x69bff7 , 0x69c03f , = 0x69c087 , 0x69c0cf , 0x69c117 = , 0x69c17f , 0x69c1e7 , 0x69c24f , 0x69c2b7 , 0x69c42d , 0x69c495 , 0x6= 9c4fd , 0x69c545 , 0x69c5ad , 0x69c615 , 0x69c65d , 0x69c6a5 , 0x69b482 , 0x69b4d4 , 0x69c6f7 , 0x69c7= 63 , 0x69c7ce , 0x699bc1 , 0x699bde , 0x699c4a , 0x699cb6 , 0x699d1f , 0x69a= 880 , 0x69ad77 , 0x69b62f , 0x69c965 , 0x69c9da , 0x69c7ce , 0x69c7ce , 0= x69ca70 , 0x69caf7 , 0x69c7ce <= exec_byte_code+15689>, 0x69c7ce , 0x69c7ce , 0x69c7ce , 0x69c7ce , 0x69c7ce , 0x69c7ce , 0x69= c7ce , 0x69cd0b } const_length =3D 4 bytestr_length =3D 17 vectorp =3D 0x946050 quitcounter =3D 1 '\001' stack_items =3D 4 sa_avail =3D 16335 sa_count =3D 10 sa_must_free =3D false stack_base =3D 0x7fffffffcb10 stack_lim =3D 0x7fffffffcb30 top =3D 0x7fffffffcb20 void_stack_lim =3D 0x7fffffffcb30 bytestr_data =3D 0x7fffffffcb30 "p\030\301 \210\302\001\206\v" pc =3D 0x7fffffffcb3c "\210\301 )\207\316\377\377\377\177" count =3D 10 result =3D XIL(0x128ca33) #29 0x0000000000644b6f in funcall_lambda (fun=3DXIL(0x945fed), nargs=3D1, a= rg_vector=3D0x7fffffffd0c0) at eval.c:2977 size =3D 6 val =3D XIL(0x7fffffffcef8) syms_left =3D make_number(256) next =3D XIL(0x1200c0b080) lexenv =3D XIL(0x7fffffffced0) count =3D 10 i =3D 0 optional =3D false rest =3D false previous_optional_or_rest =3D false #30 0x0000000000643fb9 in Ffuncall (nargs=3D2, args=3D0x7fffffffd0b8) at ev= al.c:2778 fun =3D XIL(0x945fed) original_fun =3D XIL(0xa39590) funcar =3D XIL(0x589371) numargs =3D 1 val =3D XIL(0) count =3D 9 #31 0x0000000000639907 in Ffuncall_interactively (nargs=3D2, args=3D0x7ffff= fffd0b8) at callint.c:252 speccount =3D 8 #32 0x0000000000644337 in funcall_subr (subr=3D0xb90a00 , numargs=3D2, args=3D0x7fffffffd0b8) at eval.c:2831 #33 0x0000000000643f75 in Ffuncall (nargs=3D3, args=3D0x7fffffffd0b0) at ev= al.c:2776 fun =3D XIL(0xb90a05) original_fun =3D XIL(0x66c0) funcar =3D XIL(0x645e21) numargs =3D 2 val =3D XIL(0x7fffffffd0a0) count =3D 7 #34 0x000000000063bde9 in Fcall_interactively (function=3DXIL(0xa39590), re= cord_flag=3DXIL(0), keys=3DXIL(0xca3695)) at callint.c:854 val =3D XIL(0) args =3D 0x7fffffffd0b0 visargs =3D 0x7fffffffd0c8 specs =3D XIL(0x80fa7c) filter_specs =3D XIL(0x80fa7c) teml =3D XIL(0x7fffffffcf28) up_event =3D XIL(0) enable =3D XIL(0) sa_avail =3D 16310 sa_count =3D 6 sa_must_free =3D false speccount =3D 6 next_event =3D 1 prefix_arg =3D XIL(0) string =3D 0x7fffffffd100 "P" tem =3D 0x77842b "" varies =3D 0x7fffffffd0e0 "" i =3D 3 nargs =3D 3 mark =3D 5760715 arg_from_tty =3D false key_count =3D 1 record_then_fail =3D false save_this_command =3D XIL(0xa39590) save_last_command =3D XIL(0x4627b0) save_this_original_command =3D XIL(0xa39590) save_real_this_command =3D XIL(0xa39590) #35 0x0000000000644490 in funcall_subr (subr=3D0xb90a40 , numargs=3D3, args=3D0x7fffffffd430) at eval.c:2856 internal_argbuf =3D {XIL(0xb90a40), XIL(0x7fffffffd348), make_numbe= r(1440909), XIL(0xa00c0b080), XIL(0xb90a45), XIL(0x7fffffffd368), XIL(0xb90= a40), XIL(0x7fffffffd360)} internal_args =3D 0x7fffffffd430 #36 0x0000000000643f75 in Ffuncall (nargs=3D4, args=3D0x7fffffffd428) at ev= al.c:2776 fun =3D XIL(0xb90a45) original_fun =3D XIL(0xb1b80) funcar =3D XIL(0xc0b080) numargs =3D 3 val =3D XIL(0) count =3D 5 #37 0x000000000069985f in exec_byte_code (bytestr=3DXIL(0x8aea6c), vector= =3DXIL(0x8aea8d), maxdepth=3Dmake_number(13), args_template=3Dmake_number(1= 025), nargs=3D1, args=3D0x7fffffffd960) at bytecode.c:630 op =3D 3 type =3D CATCHER targets =3D {0x69c7ce , 0x69c7f3 , 0x69c7f5 , 0x69c7f7 , 0x69c7f9 , 0x69c7f9 , 0x69c8= 5e , 0x69c8d2 , 0x698f99 , 0x698f9b , 0x698f9d , 0x698f9f , 0x698fa1 , 0x698= fa1 , 0x698fa7 , 0x698f68 , 0x69946d , 0x69946f , 0x699471 , 0x699473 , 0x6994= 75 , 0x699475 , 0x6994aa , 0x69947b , 0x69977c , 0x69977e , 0x699780 , 0x69978= 2 , 0x699784 , 0x699784 , 0x699736 , 0x69974d , 0x69982c , 0x69982e , 0x699830= , 0x699832 , 0x699834 , 0x699834 , 0x6997e6 = , 0x6997fd , 0x6998e1 , 0x6998e3 = , 0x6998e5 , 0x6998e7 , 0x6998e9 , 0x6998e9 ,= 0x69989b , 0x6998b2 , 0x69a140 <= exec_byte_code+5819>, 0x69a026 , 0x69a01d , 0x69c7ce , 0x69c7ce = , 0x69c7ce , 0x69c7ce , 0x69c7c= e , 0x69a371 , 0x69a490 , 0x69a4fa , 0x69a565 , 0x69a5d1 , 0x6992c0 , 0x69934= 5 , 0x69a652 , 0x699201 , 0x6993ad , 0x69a6c4 , 0x69a72c , 0x69a774 , 0x69a7dc= , 0x69a82e , 0x69a8ff , 0x69a947 , 0x69a9af = , 0x69aa34 , 0x69aa7c , 0x69aac4 = , 0x69ab2c , 0x69ab94 , 0x69abfc , 0x69ac81 ,= 0x69acd3 , 0x69ad25 , 0x69adf6 <= exec_byte_code+9073>, 0x69ae70 , 0x69aeea , 0x69b0b6 , 0x69b123 , = 0x69b190 , 0x69b1fd , 0x69b26a <= exec_byte_code+10213>, 0x69b2bc , 0x69b33a , 0x69b38c , 0x69b3de , 0x69b430 , 0x69b53c , 0x69= 9ea0 , 0x69b59a , 0x69b5e2 , 0x69b6ae , 0x69b717 , 0x69b775 , 0x69b7bd ,= 0x69b803 , 0x69b849 , 0x69b897= , 0x69c7ce , 0x69b8ef , 0x69b935 , 0x69b97b , 0x69b9c1 , 0x69ba07 , 0x= 69ba4d , 0x699ea0 , 0x69c7ce , 0x69ba95 , 0x69baea , 0x69bb32 , 0x69bb7a , 0x69bbe2 , 0x69bc4a , 0x69bc= 92 , 0x69bdac , 0x69be14 , 0x69be7c , 0x69bee4 , 0x69bf2a , 0x69c7ce , = 0x699dd4 , 0x699998 , 0x699172 , 0x699a44 , 0x699ac5 , 0x699b43 , 0x699d88 , 0= x699d9d , 0x6996e3 , 0x699e57 , 0x699ed7 , 0x699f65 , 0x699fae , 0x69a18c , 0x= 69a209 , 0x69a28e , 0x69a2ee , 0x69994a , 0x69bf72 , 0x69bff7 , 0x69c03f , = 0x69c087 , 0x69c0cf , 0x69c117 = , 0x69c17f , 0x69c1e7 , 0x69c24f , 0x69c2b7 , 0x69c42d , 0x69c495 , 0x6= 9c4fd , 0x69c545 , 0x69c5ad , 0x69c615 , 0x69c65d , 0x69c6a5 , 0x69b482 , 0x69b4d4 , 0x69c6f7 , 0x69c7= 63 , 0x69c7ce , 0x699bc1 , 0x699bde , 0x699c4a , 0x699cb6 , 0x699d1f , 0x69a= 880 , 0x69ad77 , 0x69b62f , 0x69c965 , 0x69c9da , 0x69c7ce , 0x69c7ce , 0= x69ca70 , 0x69caf7 , 0x69c7ce <= exec_byte_code+15689>, 0x69c7ce , 0x69c7ce , 0x69c7ce , 0x69c7ce , 0x69c7ce , 0x69c7ce , 0x69= c7ce , 0x69cd0b } const_length =3D 25 bytestr_length =3D 165 vectorp =3D 0x8aea90 quitcounter =3D 1 '\001' stack_items =3D 14 sa_avail =3D 16107 sa_count =3D 5 sa_must_free =3D false stack_base =3D 0x7fffffffd3f0 stack_lim =3D 0x7fffffffd460 top =3D 0x7fffffffd428 void_stack_lim =3D 0x7fffffffd460 bytestr_data =3D 0x7fffffffd460 "\306\020\211?\205\023" pc =3D 0x7fffffffd4db "\006\006\071\203\242" count =3D 5 result =3D XIL(0) #38 0x0000000000644b6f in funcall_lambda (fun=3DXIL(0x8aea3d), nargs=3D1, a= rg_vector=3D0x7fffffffd958) at eval.c:2977 size =3D 5 val =3D XIL(0x7fffffffd8b8) syms_left =3D make_number(1025) next =3D XIL(0x1200c0b080) lexenv =3D make_number(34910567923712) count =3D 5 i =3D 0 optional =3D false rest =3D false previous_optional_or_rest =3D false #39 0x0000000000643fb9 in Ffuncall (nargs=3D2, args=3D0x7fffffffd950) at ev= al.c:2778 fun =3D XIL(0x8aea3d) original_fun =3D XIL(0x3f30) funcar =3D XIL(0x1) numargs =3D 1 val =3D XIL(0x7fffffffd958) count =3D 4 #40 0x0000000000643891 in call1 (fn=3DXIL(0x3f30), arg1=3DXIL(0xa39590)) at= eval.c:2627 #41 0x000000000058a56b in command_loop_1 () at keyboard.c:1482 scount =3D 3 cmd =3D XIL(0xa39590) keybuf =3D {make_number(10), XIL(0x2012e48b3), XIL(0), XIL(0x7a10),= XIL(0x10000010f), XIL(0), XIL(0xc0a7a0), XIL(0x7a10), make_number(55834574= 852), XIL(0xc12a90), XIL(0x7fffffffd9e0), XIL(0), XIL(0x7fffffffda20), make= _number(1644723), make_number(34910567923712), XIL(0xc0b080), XIL(0x580b87)= , XIL(0), XIL(0x7fffffffda20), XIL(0x57e6cb), XIL(0), XIL(0xc0b080), XIL(0x= 7fffffffda80), XIL(0), XIL(0x7fffffffda50), XIL(0x57e6cb), XIL(0x5), XIL(0x= 7a10), XIL(0x7fffffffda90), XIL(0x640415)} i =3D 1 prev_modiff =3D 18 prev_buffer =3D 0xc9e400 already_adjusted =3D false #42 0x000000000063fffe in internal_condition_case (bfun=3D0x589d5b , handlers=3DXIL(0x5280), hfun=3D0x5893bf ) at eval.c:13= 36 val =3D XIL(0x57e6cb) c =3D 0x2c80180 #43 0x0000000000589971 in command_loop_2 (ignore=3DXIL(0)) at keyboard.c:11= 10 val =3D XIL(0xc900) #44 0x000000000063f4fd in internal_catch (tag=3DXIL(0xc900), func=3D0x58994= 4 , arg=3DXIL(0)) at eval.c:1101 val =3D XIL(0) c =3D 0x2c80060 #45 0x000000000058990f in command_loop () at keyboard.c:1089 #46 0x0000000000588ea8 in recursive_edit_1 () at keyboard.c:695 count =3D 1 val =3D XIL(0x7fffffffdc00) #47 0x000000000058909d in Frecursive_edit () at keyboard.c:766 count =3D 0 buffer =3D XIL(0) #48 0x0000000000586c3c in main (argc=3D3, argv=3D0x7fffffffde48) at emacs.c= :1717 stack_bottom_variable =3D 0x2c6c290 do_initial_setlocale =3D true dumping =3D false skip_args =3D 1 no_loadup =3D false junk =3D 0x0 dname_arg =3D 0x0 ch_to_dir =3D 0x0 original_pwd =3D 0x0 disable_aslr =3D false rlim =3D { rlim_cur =3D 10022912,=20 rlim_max =3D 18446744073709551615 } sockfd =3D -1 module_assertions =3D true Lisp Backtrace: "realpath-truename" (0xffffb990) "while" (0xffffbc70) "let" (0xffffbe90) "progn" (0xffffbfe0) "eval" (0xffffc210) "elisp--eval-last-sexp" (0xffffc6a8) "eval-last-sexp" (0xffffcb28) "eval-print-last-sexp" (0xffffd0c0) "funcall-interactively" (0xffffd0b8) "call-interactively" (0xffffd430) "command-execute" (0xffffd958) #2 0x00000000006854ce in value_to_lisp (v=3D0x3059c90) at emacs-module.c:9= 84 984 eassert (STRINGP (*p) && SSDATA (*p)); $1 =3D (Lisp_Object *) 0x3059c90 Lisp_String $2 =3D (struct Lisp_String *) 0x3057690 0 quit --=-=-= Content-Type: text/plain [CCing Philipp as the author of module assertions.] Eli Zaretskii writes: >> From: "Basil L. Contovounesios" >> Date: Mon, 25 Feb 2019 21:00:41 +0000 >> >> Starting program: /home/blc/.local/src/emacs26/src/emacs -Q --module-assertions >> [Thread debugging using libthread_db enabled] >> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". >> [New Thread 0x7ffff01cb700 (LWP 8299)] >> [New Thread 0x7fffef9ac700 (LWP 8300)] >> [New Thread 0x7fffef1ab700 (LWP 8301)] >> >> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault. >> re_search_2 (bufp=0xbf5d00 , str1=0x0, size1=0, str2=0x0, size2=18, startpos=0, >> range=18, regs=0x0, stop=18) at regex.c:4354 >> 4354 buf_ch = STRING_CHAR_AND_LENGTH (d, buf_charlen); >> #0 0x0000000000608594 in re_search_2 >> (bufp=0xbf5d00 , str1=0x0, size1=0, str2=0x0, size2=18, startpos=0, range=18, regs=0x0, stop=18) at regex.c:4354 >> buf_charlen = 0 >> irange = 18 >> lim = 0 >> d = 0x0 >> buf_ch = 18 >> val = 691541629 >> string1 = 0x0 >> string2 = 0x0 >> fastmap = 0xbf5d38 "" >> translate = make_number(0) >> total_size = 18 >> endpos = 18 >> anchored_start = 0 '\000' >> multibyte = 1 '\001' >> #1 0x0000000000607f91 in re_search >> (bufp=0xbf5d00 , string=0x0, size=18, startpos=0, range=18, regs=0x0) >> at regex.c:4181 >> #2 0x00000000005f3fd0 in fast_string_match_internal >> (regexp=XIL(0x8c761c), string=XIL(0x3036ec4), table=XIL(0)) at search.c:485 >> val = 140737488336288 >> bufp = 0xbf5d00 > > Here's your problem: fast_string_match_internal got a Lisp > string=XIL(0x3036ec4), but its data passed to re_search as the 2nd arg > is a NULL pointer. You need to find out how this happens, e.g. by > setting a watchpoint on string's data inside Ffile_name_as_directory. > Or maybe the string is already corrupted there? The file name string is already corrupted when Ffile_name_as_directory is called; see below. First, I rewrote the dynamic module[1] to add nonlocal exit checks after almost every call to the module API. [1]: https://gitlab.com/basil-conto/realpath I also added the following assertions to src/emacs-module.c: --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=module-asserts.patch diff --git a/src/emacs-module.c b/src/emacs-module.c index 0abfd3f6f1..4f2b0ecd4b 100644 --- a/src/emacs-module.c +++ b/src/emacs-module.c @@ -458,6 +458,8 @@ module_make_function (emacs_env *env, ptrdiff_t min_arity, ptrdiff_t max_arity, return lisp_to_value (env, result); } +static bool my_check = false; + static emacs_value module_funcall (emacs_env *env, emacs_value fun, ptrdiff_t nargs, emacs_value args[]) @@ -473,6 +475,7 @@ module_funcall (emacs_env *env, emacs_value fun, ptrdiff_t nargs, xsignal0 (Qoverflow_error); SAFE_ALLOCA_LISP (newargs, nargs1); newargs[0] = value_to_lisp (fun); + my_check = EQ (newargs[0], Qfile_name_as_directory); for (ptrdiff_t i = 0; i < nargs; i++) newargs[1 + i] = value_to_lisp (args[i]); emacs_value result = lisp_to_value (env, Ffuncall (nargs1, newargs)); @@ -581,8 +584,10 @@ module_make_string (emacs_env *env, const char *str, ptrdiff_t length) /* FIXME: AUTO_STRING_WITH_LEN requires STR to be null-terminated, but we shouldn't require that. */ AUTO_STRING_WITH_LEN (lstr, str, length); - return lisp_to_value (env, - code_convert_string_norecord (lstr, Qutf_8, false)); + Lisp_Object lisp = code_convert_string_norecord (lstr, Qutf_8, false); + eassert (STRINGP (lisp) && SSDATA (lisp)); + my_check = true; + return lisp_to_value (env, lisp); } static emacs_value @@ -955,6 +960,8 @@ value_to_lisp_bits (emacs_value v) static Lisp_Object value_to_lisp (emacs_value v) { + bool b = my_check; + my_check = false; if (module_assertions) { /* Check the liveness of the value by iterating over all live @@ -972,7 +979,11 @@ value_to_lisp (emacs_value v) { Lisp_Object *p = XSAVE_POINTER (XCAR (values), 0); if (p == optr) - return *p; + { + if (b) + eassert (STRINGP (*p) && SSDATA (*p)); + return *p; + } ++num_values; } ++num_environments; @@ -1008,6 +1019,8 @@ lisp_to_value_bits (Lisp_Object o) static emacs_value lisp_to_value (emacs_env *env, Lisp_Object o) { + bool b = my_check; + my_check = false; if (module_assertions) { /* Add the new value to the list of values allocated from this @@ -1020,6 +1033,11 @@ lisp_to_value (emacs_env *env, Lisp_Object o) ATTRIBUTE_MAY_ALIAS emacs_value ret = vptr; struct emacs_env_private *priv = env->private_members; priv->values = Fcons (make_save_ptr (ret), priv->values); + if (b) + { + eassert (STRINGP (o) && SSDATA (o)); + eassert (STRINGP (*optr) && SSDATA (*optr)); + } return ret; } --=-=-= Content-Type: text/plain These reveal that value_to_lisp eventually returns a corrupted string, but I don't know why. I've seen comments in src/fileio.c referring to string-relocation during GC; could this be at play here? Either way, do you have any suggestions on how to proceed? Here's the full recipe again, now with debugging symbols for the module: 0. git clone https://gitlab.com/basil-conto/realpath.git 1. cd realpath 2. make DEBUG=1 3. cd /path/to/emacs/src 4. gdb emacs 5. set logging on 6. r -Q --module-assertions 7. (progn (module-load "/path/to/realpath.so") (dotimes (_ 1000) (realpath-truename user-emacs-directory))) C-j [The loop usually trips the assertions on its first run, but if it doesn't, just try again once or twice.] 8. bt full 9. f 2 10. p p 11. pr [#] 12. xpr I attach the resulting GDB log. Thanks, -- Basil --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 17 13:08:21 2019 Received: (at 34655) by debbugs.gnu.org; 17 Mar 2019 17:08:21 +0000 Received: from localhost ([127.0.0.1]:47703 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h5ZGn-0005rA-4U for submit@debbugs.gnu.org; Sun, 17 Mar 2019 13:08:21 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34241) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h5ZGl-0005qw-Nl for 34655@debbugs.gnu.org; Sun, 17 Mar 2019 13:08:20 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49701) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5ZGg-0001t2-BF; Sun, 17 Mar 2019 13:08:14 -0400 Received: from [176.228.60.248] (port=3340 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h5ZGf-0003Vo-OB; Sun, 17 Mar 2019 13:08:14 -0400 Date: Sun, 17 Mar 2019 19:08:01 +0200 Message-Id: <83lg1dwhse.fsf@gnu.org> From: Eli Zaretskii To: "Basil L. Contovounesios" In-reply-to: <87h8c1cv6l.fsf@tcd.ie> (contovob@tcd.ie) Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: 34655@debbugs.gnu.org, p.stephani2@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: "Basil L. Contovounesios" > Cc: <34655@debbugs.gnu.org>, Philipp Stephani > Date: Sun, 17 Mar 2019 16:38:58 +0000 > > These reveal that value_to_lisp eventually returns a corrupted string, > but I don't know why. Did you try to identify the code which causes the corruption, i.e. the data is valid before that code runs, and invalid after that? If not, can you try? The way to do that is by painstakingly stepping through the code while examining the relevant data, possibly with help of watchpoints and displays set up by the GDB "display" command. > I've seen comments in src/fileio.c referring to string-relocation > during GC; could this be at play here? It could be, if your module code holds onto C pointers to Lisp string data while Emacs runs parts of the interpreter which could GC. Does that happen anywhere in your code or in the code involved in module-assertions? > Either way, do you have any suggestions on how to proceed? See above. I tried at the time to reproduce your problem, and failed. But I did that on Windows, where I needed to replace the non-existent realpath by an equivalent function, so it's not a faithful reproduction. I will see if I can find time to look at this on a GNU machine, unless someone beats me to it. > 8. bt full > 9. f 2 > 10. p p > 11. pr [#] > 12. xpr Why did you expect 'p' to be a valid Lisp object? It's actually a pointer to a Lisp object, i.e. try (gdb) p *p (gdb) xpr From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 17 19:53:11 2019 Received: (at 34655) by debbugs.gnu.org; 17 Mar 2019 23:53:11 +0000 Received: from localhost ([127.0.0.1]:47861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h5faY-0007it-KH for submit@debbugs.gnu.org; Sun, 17 Mar 2019 19:53:10 -0400 Received: from mail-ed1-f51.google.com ([209.85.208.51]:34286) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h5faW-0007iZ-Ub for 34655@debbugs.gnu.org; Sun, 17 Mar 2019 19:53:09 -0400 Received: by mail-ed1-f51.google.com with SMTP id a16so12009823edn.1 for <34655@debbugs.gnu.org>; Sun, 17 Mar 2019 16:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=0zpeSc4DC1PqQ45iyNnWxaaZR4XczT+tiAOIBtkVNCw=; b=But7g/dq2BTRzf3/s89I4/39EEFUldSPA40MrfNfKiaOm5r6PWaWuXv0kylF3MTt8M /G0iyEK3y++ZSDXUb7ZgIcice0jlWmJpkLmrTJOnzORQFcvpI1UqDo6KWvbiFGjtEq4Z ytPJT2gTe2qSD60m3dUCUIBEfcQOp9bj3zwGhzldP3LMY3U6OX2VHz2CFbuCInoUhEcp 12GqwgA5VoN2S8jpeOkaHZ3cH3GaI8X05PbSI9OdOXrxvA4rqO4A2G4aTfByZTEl5h3n ccLJLpMx3t1YerlQ1K31XK4SVBfKAbdw5xh5CTIxnkXP1uLGeEhv7PdzsW45rcyOIhRX MpOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=0zpeSc4DC1PqQ45iyNnWxaaZR4XczT+tiAOIBtkVNCw=; b=Ku8xgl9RV2KBLqX+28ykCW5/PKIc16z2HXkE5WOH2d9IPFwMsbRrcq1+TyBsvbF2l0 eQhs8C0pmIJb+uq9wgk1NNataUzBnNt2bf53ECZYYweGu58s7VF416Rsq2A8X5Q61RuJ S2Wvo5mmdjTj5WVVYs7FggSvx+5D1bgnpl0CvjNPoVjhxw0E6ngejsg8vWuUJoP92f51 yi9V3Q7t6cOLh2h6Ob8pAObFc4oaql8kEKoAC/2dUsudXD7N8PeLQhHaRdM9nt/cmXnb k5w/0kCT6dI41U/EF3FZ6yeDhFaj3kaFIuQ9ISWgrxyrKMb3Y09ZqXyZ8nwetOGS8k57 wHWg== X-Gm-Message-State: APjAAAVQ2/RQBwLRxZ+JqxH5oucfGb9dU5JzFXyvn92q/FbGtRQw55+q +S4T+dY2emf73EZEJDjHJkgQiw== X-Google-Smtp-Source: APXvYqx6PgVUoWUL12JemWgnHnvZJC83zOgsrCFbGeKHd/dBPk4cGNQcYZ+QqR1rZ1DrJZfIlreVnw== X-Received: by 2002:a17:906:1182:: with SMTP id n2mr9049666eja.35.1552866782987; Sun, 17 Mar 2019 16:53:02 -0700 (PDT) Received: from localhost ([2a02:8084:20e2:c380:20c2:134e:4f3a:683a]) by smtp.gmail.com with ESMTPSA id i9sm2447915edl.65.2019.03.17.16.53.01 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sun, 17 Mar 2019 16:53:02 -0700 (PDT) From: "Basil L. Contovounesios" To: Eli Zaretskii Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> Date: Sun, 17 Mar 2019 23:52:55 +0000 In-Reply-To: <83lg1dwhse.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 17 Mar 2019 19:08:01 +0200") Message-ID: <87va0h12js.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: 34655@debbugs.gnu.org, p.stephani2@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: "Basil L. Contovounesios" >> Cc: <34655@debbugs.gnu.org>, Philipp Stephani >> Date: Sun, 17 Mar 2019 16:38:58 +0000 >>=20 >> These reveal that value_to_lisp eventually returns a corrupted string, >> but I don't know why. > > Did you try to identify the code which causes the corruption, i.e. the > data is valid before that code runs, and invalid after that? If not, > can you try? The way to do that is by painstakingly stepping through > the code while examining the relevant data, possibly with help of > watchpoints and displays set up by the GDB "display" command. The patch adding assertions to emacs-module.c narrows the problematic code to lines 123--127 of the dynamic module[1]: if (rp_lisp_string (env, &file, nbuf) && rp_funcall (env, &dir, "directory-name-p", 1, &dir) && env->is_not_nil (env, dir)) /* Return directory name when given one =C3=A0 la Ffile_truename. = */ rp_funcall (env, &file, "file-name-as-directory", 1, &file); [1]: https://gitlab.com/basil-conto/realpath/blob/master/realpath.c#L123-127 On line 123, 'file' is set to an Emacs string created from the C string 'nbuf' ('rp_lisp_string' wraps 'module_make_string' along with a nonlocal exit check, and similarly 'rp_funcall' wraps 'module_funcall'). On line 127, 'file' is passed to 'file-name-as-directory'. The assertions added to 'module_make_string' and 'lisp_to_value' never fail, suggesting the string returned by them is fine (though the assertions in 'lisp_to_value' only target intermediate Lisp_Objects, not the returned emacs_value). The assertion added to 'value_to_lisp' via 'module_funcall', OTOH, does fail. I'll see if I can step through this, though I'm not yet sure how I'll distinguish the problematic call to the module function from the hundreds of unproblematic ones before it. There's probably a way to teach GDB how to inspect emacs_values which I'm not yet familiar with. >> I've seen comments in src/fileio.c referring to string-relocation >> during GC; could this be at play here? > > It could be, if your module code holds onto C pointers to Lisp string > data while Emacs runs parts of the interpreter which could GC. Does > that happen anywhere in your code or in the code involved in > module-assertions? I can't speak for emacs-module.c (I haven't yet understood how Vmodule_environments and its save pointers work), but the only exchange between C and Lisp strings in my code is via the module API, i.e. module_make_string and module_copy_string_contents. I would hope the API and its opaque emacs_value type make it difficult for such issues to arise. >> Either way, do you have any suggestions on how to proceed? > > See above. > > I tried at the time to reproduce your problem, and failed. But I did > that on Windows, where I needed to replace the non-existent realpath > by an equivalent function, so it's not a faithful reproduction. I > will see if I can find time to look at this on a GNU machine, unless > someone beats me to it. Replacing 'canonicalize_file_name' with 'strdup' still reproduces the issue for me. Perhaps increasing the number of calls to realpath-truename from 1000 to 5000 will also help. >> 8. bt full >> 9. f 2 >> 10. p p >> 11. pr [#] >> 12. xpr > > Why did you expect 'p' to be a valid Lisp object? It's actually a > pointer to a Lisp object, i.e. try > > (gdb) p *p > (gdb) xpr Oops, that was a thinko. The only difference is GDB reports XIL(...) instead of (Lisp_Object *), though. Thank you for your help, I'll report more as time allows. --=20 Basil From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 18 12:21:44 2019 Received: (at 34655) by debbugs.gnu.org; 18 Mar 2019 16:21:44 +0000 Received: from localhost ([127.0.0.1]:49065 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h5v1E-0007NQ-6j for submit@debbugs.gnu.org; Mon, 18 Mar 2019 12:21:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57440) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h5v1B-0007N8-HU for 34655@debbugs.gnu.org; Mon, 18 Mar 2019 12:21:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40961) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5v16-0000zS-4d; Mon, 18 Mar 2019 12:21:36 -0400 Received: from [176.228.60.248] (port=1635 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h5v15-0000Xy-I8; Mon, 18 Mar 2019 12:21:35 -0400 Date: Mon, 18 Mar 2019 18:21:25 +0200 Message-Id: <835zsgw3ui.fsf@gnu.org> From: Eli Zaretskii To: "Basil L. Contovounesios" In-reply-to: <87va0h12js.fsf@tcd.ie> (contovob@tcd.ie) Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: 34655@debbugs.gnu.org, p.stephani2@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: "Basil L. Contovounesios" > Cc: <34655@debbugs.gnu.org>, > Date: Sun, 17 Mar 2019 23:52:55 +0000 > > > I tried at the time to reproduce your problem, and failed. But I did > > that on Windows, where I needed to replace the non-existent realpath > > by an equivalent function, so it's not a faithful reproduction. I > > will see if I can find time to look at this on a GNU machine, unless > > someone beats me to it. > > Replacing 'canonicalize_file_name' with 'strdup' still reproduces the > issue for me. Perhaps increasing the number of calls to > realpath-truename from 1000 to 5000 will also help. Right, the strdup part did that for me. (My previous attempt also used strdup as part of the replacement, but still failed to reproduce. Memory corruption bugs are frequently weird that way.) So I modified your recipe slightly, like this: (progn (module-load "/path/to/realpath.so") (setq garbage-collection-messages t) (dotimes (i 5000) (message "%d" i) (realpath-truename user-emacs-directory))) put it on a file named rp.el, and then ran it under GDB: (gdb) r -batch --module-assertions -l ./rp.el Here's what I see: [...] 3077 3078 3079 3080 Garbage collecting... Garbage collecting...done Thread 1 received signal SIGSEGV, Segmentation fault. 0x011e9918 in rpl_re_search_2 (bufp=0x17c0260 , str1=0x0, size1=0, str2=0x0, size2=20, startpos=0, range=20, regs=0x0, stop=20) at regex-emacs.c:3322 3322 buf_ch = STRING_CHAR_AND_LENGTH (d, buf_charlen) Looks like it indeed crashes after a GC, and on my system needs more than 3000 iterations. So let's run it with a breakpoint at the beginning of GC: (gdb) break alloc.c:6044 Breakpoint 3 at 0x11fa1bb: file alloc.c, line 6044. (gdb) r -batch --module-assertions -l ./rp.el [...] 3080 Thread 1 hit Breakpoint 3, garbage_collect_1 (gcst=0x82bb84) at alloc.c:6044 6044 record_in_backtrace (QAutomatic_GC, 0, 0); The backtrace at this point: (gdb) bt #0 garbage_collect_1 (gcst=0x82bb84) at alloc.c:6044 #1 0x011fa88e in garbage_collect () at alloc.c:6241 #2 0x01149adc in maybe_gc () at lisp.h:5028 #3 0x0123b012 in Ffuncall (nargs=2, args=0x82bcb0) at eval.c:2829 #4 0x0128c3cf in module_funcall (env=0x6122730, fun=0x6122868, nargs=1, args=0x82bd50) at emacs-module.c:483 #5 0x62d8136f in rp_funcall (env=0x6122730, value=0x82bd50, name=0x62d83060 "directory-name-p", nargs=1, args=0x82bd50) at realpath.c:62 #6 0x62d815cc in Frealpath_truename (env=0x6122730, nargs=1, args=0x82bd90, data=0x0) at realpath.c:124 [...] Lisp Backtrace: "directory-name-p" (0x82bcb8) "realpath-truename" (0x82bf80) "while" (0x82c2c8) "let" (0x82c538) "eval-buffer" (0x82cab0) "load-with-code-conversion" (0x82d0f0) "load" (0x82d9b8) "command-line-1" (0x82e3d0) "command-line" (0x82efe8) "normal-top-level" (0x82f690) As you see, the call to Ffuncall is the one that triggers GC from time to time. What happens with our 'file' at this point? (gdb) fr 6 (gdb) p file $1 = (emacs_value) 0x6122848 (gdb) p *file $2 = (gdb) p *(Lisp_Object *)file $3 = XIL(0x8000000006121ed0) (gdb) xtype Lisp_String (gdb) xstring $4 = (struct Lisp_String *) 0x6121ed0 "d:/usr/eli/.emacs.d/" Still valid. Now let's see who thrashes it: (gdb) p *$4 $5 = { u = { s = { size = 20, size_byte = 20, intervals = 0x0, data = 0x611e9fc "d:/usr/eli/.emacs.d/" }, next = 0x14, gcaligned = 20 '\024' } } (gdb) watch -l $4->u.s.data Hardware watchpoint 4: -location $4->u.s.data (gdb) c Continuing. Garbage collecting... Thread 1 hit Hardware watchpoint 4: -location $4->u.s.data Old value = (unsigned char *) 0x611e9fc "\024" New value = (unsigned char *) 0x0 sweep_strings () at alloc.c:2163 2163 NEXT_FREE_LISP_STRING (s) = string_free_list; (gdb) list 2158 /* Reset the strings's `data' member so that we 2159 know it's free. */ 2160 s->u.s.data = NULL; 2161 2162 /* Put the string on the free-list. */ 2163 NEXT_FREE_LISP_STRING (s) = string_free_list; 2164 string_free_list = ptr_bounds_clip (s, sizeof *s); 2165 ++nfree; 2166 } 2167 } Bingo! This is sweep_strings freeing our string, because it evidently doesn't think it's a Lisp object that is being still referenced. The culprit is this fragment from emacs-module.c, which is called each time you receive a Lisp object from Emacs which you want to use in your module: /* Convert O to an emacs_value. Allocate storage if needed; this can signal if memory is exhausted. Must be an injective function. */ static emacs_value lisp_to_value (emacs_env *env, Lisp_Object o) { if (module_assertions) { /* Add the new value to the list of values allocated from this environment. The value is actually a pointer to the Lisp_Object cast to emacs_value. We make a copy of the object on the free store to guarantee unique addresses. */ ATTRIBUTE_MAY_ALIAS Lisp_Object *optr = xmalloc (sizeof o); *optr = o; void *vptr = optr; ATTRIBUTE_MAY_ALIAS emacs_value ret = vptr; struct emacs_env_private *priv = env->private_members; priv->values = Fcons (make_mint_ptr (ret), priv->values); return ret; } What this does is make a copy of each Lisp object you get from Emacs, store that copy in memory allocated off the heap, and hand your module a pointer to the copy instead of the original object. So when you call, e.g., directory-name-p, an Emacs function, it gets that copy of the object. But memory allocation by xmalloc doesn't record the allocated memory in the red-black tree we maintain for the purposes of detecting Lisp objects referenced by C stack-based variables. So when GC comes to examine the C stack, it doesn't consider the variable 'file' in your module as being a pointer to a live Lisp object, and so it doesn't mark it. Then the sweep phase of GC recycles your Lisp object, which in this case involves setting the string's data to a NULL pointer. The patch to fix this is below; it simply marks these copied values by hand, thus preventing them from being GCed. It ran successfully with even 50,000 iterations. Philipp, any comments/objections? --- src/emacs-module.c~0 2019-02-25 10:18:35.000000000 +0200 +++ src/emacs-module.c 2019-03-18 08:33:00.564476000 +0200 @@ -1133,6 +1133,15 @@ mark_modules (void) mark_object (priv->non_local_exit_symbol); mark_object (priv->non_local_exit_data); mark_object (priv->values); + if (module_assertions) + { + for (Lisp_Object values = priv->values; + CONSP (values); values = XCDR (values)) + { + Lisp_Object *p = xmint_pointer (XCAR (values)); + mark_object (*p); + } + } } } From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 18 12:58:48 2019 Received: (at 34655) by debbugs.gnu.org; 18 Mar 2019 16:58:48 +0000 Received: from localhost ([127.0.0.1]:49094 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h5vb5-0008Mw-S2 for submit@debbugs.gnu.org; Mon, 18 Mar 2019 12:58:48 -0400 Received: from mail-ed1-f44.google.com ([209.85.208.44]:34958) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h5vb1-0008Me-HB for 34655@debbugs.gnu.org; Mon, 18 Mar 2019 12:58:47 -0400 Received: by mail-ed1-f44.google.com with SMTP id d6so13593330eds.2 for <34655@debbugs.gnu.org>; Mon, 18 Mar 2019 09:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=IetyZ2HDBdTfFYPwiK/vDyB0pzwgXPIcDPLlCd9d0JM=; b=puXnklzfmoy1+6FTM3caoT+cHocl1m5UllK54B9y0JHxt5OshTiv4r7ra1NibKyKwq +9EeOLsgwH+B6F9SQ8SCEh7V36PyFoyZkpf/xzQJlULmez+7tv58lIfam7p8TkaCamwX 8Xye7eMOmT78MrhlIHw0dzzIW5PtLzAM2bM27u6ZIKtiRFQE9WcCjMRm958RTahFmaGP Em1GWGgYOkAGHNBE2qrzhNiGzaKgBMd9jY/9Uz0LNIjLNubBIasS2bxzqcgWmGi/aQkb qNXkStmphX6pFz82GyGKk7BeTE5QoWyYD8o+LwnzaEhMdvESs4nDc9Powanmgmcx9P5T vsEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=IetyZ2HDBdTfFYPwiK/vDyB0pzwgXPIcDPLlCd9d0JM=; b=mk3Yb4n9Rlizw70pKZYS7hJS2qlXMuXG5acHFxwk/qTH3i76oSiasMzQB3Bjdg8asD 5B6hIu1vYC905sLKBvZZNOft9FT/qZ/pBtOVlFrXPdMmFGMbgbS2fPhmvqwer1FZALRe KONsFhHextwFKS16vpWgqc1LIGOXJ0MXTzcR1FGCR8MnnXxcA0VHkE7Q4dpVnhLKUdoE 1T9FrDp9mCnlXsZ8oG1uFXKeOdnvtz+XAMdg/EfKQMGHPcXDJWdMr2cb32Cctodf1+Es PK5Wgg/eROEK6QAgGKxn/6BTmJNWnyLOX5kZF8HEv7/u4Oe2kPeMhnWsMxJISdnrGsLv 7hRQ== X-Gm-Message-State: APjAAAWR25+08Gs0ADRfhnG8nqUei/JEJhj5tASWXZTAl4jFEH8/ThFf PnGQX5pe+Xj8i6l1LD1xBsAQKw== X-Google-Smtp-Source: APXvYqxgmbMXYymnKEUkMGontZlvMd3PgK72vytQJcSoWwpwexsrjz50J2X6GxjdEC2tnVoZgsZ0eg== X-Received: by 2002:a50:b566:: with SMTP id z35mr5489356edd.266.1552928317815; Mon, 18 Mar 2019 09:58:37 -0700 (PDT) Received: from localhost ([2a02:8084:20e2:c380:20c2:134e:4f3a:683a]) by smtp.gmail.com with ESMTPSA id i5sm2540295eja.47.2019.03.18.09.58.36 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Mon, 18 Mar 2019 09:58:36 -0700 (PDT) From: "Basil L. Contovounesios" To: Eli Zaretskii Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> <835zsgw3ui.fsf@gnu.org> Date: Mon, 18 Mar 2019 16:58:35 +0000 In-Reply-To: <835zsgw3ui.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 18 Mar 2019 18:21:25 +0200") Message-ID: <87ef7486h0.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: 34655@debbugs.gnu.org, p.stephani2@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > The patch to fix this is below; it simply marks these copied values by > hand, thus preventing them from being GCed. It ran successfully with > even 50,000 iterations. I can confirm that your patch fixes the issue. I am very grateful not only for your looking into this, but also for taking the time to explain the whole process; it has been enlightening and would have taken me a lot of time to figure out alone. Thanks, -- Basil From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 18 13:53:20 2019 Received: (at 34655) by debbugs.gnu.org; 18 Mar 2019 17:53:20 +0000 Received: from localhost ([127.0.0.1]:49167 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h5wRs-0001Hq-2i for submit@debbugs.gnu.org; Mon, 18 Mar 2019 13:53:20 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47040) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h5wRq-0001Hb-1k for 34655@debbugs.gnu.org; Mon, 18 Mar 2019 13:53:18 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42787) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5wRk-0005NC-Ia; Mon, 18 Mar 2019 13:53:12 -0400 Received: from [176.228.60.248] (port=3332 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h5wRj-0001qA-TS; Mon, 18 Mar 2019 13:53:12 -0400 Date: Mon, 18 Mar 2019 19:53:03 +0200 Message-Id: <83r2b4ul1c.fsf@gnu.org> From: Eli Zaretskii To: "Basil L. Contovounesios" In-reply-to: <87ef7486h0.fsf@tcd.ie> (contovob@tcd.ie) Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> <835zsgw3ui.fsf@gnu.org> <87ef7486h0.fsf@tcd.ie> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: 34655@debbugs.gnu.org, p.stephani2@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: "Basil L. Contovounesios" > Cc: <34655@debbugs.gnu.org>, > Date: Mon, 18 Mar 2019 16:58:35 +0000 > > Eli Zaretskii writes: > > > The patch to fix this is below; it simply marks these copied values by > > hand, thus preventing them from being GCed. It ran successfully with > > even 50,000 iterations. > > I can confirm that your patch fixes the issue. Great, thanks for testing. > I am very grateful not only for your looking into this, but also for > taking the time to explain the whole process; it has been enlightening > and would have taken me a lot of time to figure out alone. You are welcome. I will wait for a few days to give Philipp and others a chance to comment, and push then if no one comes up with objections. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 21 12:12:00 2019 Received: (at 34655) by debbugs.gnu.org; 21 Mar 2019 16:12:01 +0000 Received: from localhost ([127.0.0.1]:53429 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h70IS-0000EB-Ig for submit@debbugs.gnu.org; Thu, 21 Mar 2019 12:12:00 -0400 Received: from mail-oi1-f182.google.com ([209.85.167.182]:35043) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h70IR-0000Dz-FD for 34655@debbugs.gnu.org; Thu, 21 Mar 2019 12:11:59 -0400 Received: by mail-oi1-f182.google.com with SMTP id j132so5085457oib.2 for <34655@debbugs.gnu.org>; Thu, 21 Mar 2019 09:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1AWlZmfqcS+Zl+6AIvRddL5CZP2ZXjFYh0n7zCMs8T0=; b=JRND/BRcVK37amC8RKXaQ+kTANI2NUcL8hcgWQ53hI2yEVEExbfaxBcy6fZqPqgYie o97GRU7dmPcw8+8ESczRlc02hJgBS4GhIbTp+aRrD9iOt6h7s7Ps8ZKk7SN7Pe224yrt aujtxGYK5GQWq3yxgZRAIkLiWE33QY5dQRon5Yzio3lXITVJoaD02lH56erBLTLOTwm2 hZNeklU/L5SnhOWOGRo3BTRFKNlUUuRE5/wzXRnaDdavthinvFC26Q+2EWAORTKX4Tsy SVqbVlzQ4r0cWWBySgY+piIDcFcJkLtCMHqEsJLsVw+aYrD/gNY9Hw4fryzJGSH/AHBd Jy3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1AWlZmfqcS+Zl+6AIvRddL5CZP2ZXjFYh0n7zCMs8T0=; b=JHMqbPAye8De7jrnu3gpzYXZOiZ/RR3oWAr3uHxIe6gdxJwsd9mNydUQ8V+jn6HE9g p+JtjjPfONlQy7omgPbH8TfCRJugufNSBlnU8FdjBsBYTlDcSQRK2svjxSDSyphoV/Ca VORUmwi7ekb99JWMJX9yL5EtQO1BzOTm4d6Xae3ZuFRYqxsi2EUmCBTWlaTnf1Ee31tO DXloC0gRyy8/0f0nu1/h3U+HhxCJdNHyXbX3nj6Z27mg45huqMYVkj774GY2Z7HXuDdW 9ugDFfWWKtiprULJOIc/2wq44gPkmRt3gb2LwYbTX8XYrK1TuB1KJvRDc3KCwoOKLs/o V2kA== X-Gm-Message-State: APjAAAWZFYrm0i/psfR304O0WU6NnQaHlSMRthxRlvYnUy3Msn/Cp5zA joi30UkDD9XEyxOb0fI/J/mlA1gNZplhM4mtSHM= X-Google-Smtp-Source: APXvYqyrTBlQJOmA9ePo3PO9p8hJiW3FFATpSmzIPc41H5rgih3XAKGmiiVh66YDNcKnAws1U1DQ/qZbdnTled34XFg= X-Received: by 2002:aca:310a:: with SMTP id x10mr4604oix.161.1553184712048; Thu, 21 Mar 2019 09:11:52 -0700 (PDT) MIME-Version: 1.0 References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> <835zsgw3ui.fsf@gnu.org> <87ef7486h0.fsf@tcd.ie> <83r2b4ul1c.fsf@gnu.org> In-Reply-To: <83r2b4ul1c.fsf@gnu.org> From: Philipp Stephani Date: Thu, 21 Mar 2019 17:11:41 +0100 Message-ID: Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 34655 Cc: "Basil L. Contovounesios" , 34655@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Am Mo., 18. M=C3=A4rz 2019 um 18:53 Uhr schrieb Eli Zaretskii : > > > From: "Basil L. Contovounesios" > > Cc: <34655@debbugs.gnu.org>, > > Date: Mon, 18 Mar 2019 16:58:35 +0000 > > > > Eli Zaretskii writes: > > > > > The patch to fix this is below; it simply marks these copied values b= y > > > hand, thus preventing them from being GCed. It ran successfully with > > > even 50,000 iterations. > > > > I can confirm that your patch fixes the issue. > > Great, thanks for testing. > > > I am very grateful not only for your looking into this, but also for > > taking the time to explain the whole process; it has been enlightening > > and would have taken me a lot of time to figure out alone. > > You are welcome. > > I will wait for a few days to give Philipp and others a chance to > comment, and push then if no one comes up with objections. I haven't checked everything in detail, but my impression is that this is rather another instance of bug#31238. Fixing this only when module assertions are enabled will probably not fix anything, but rather mask issues. Reverting commit 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a is still the right approach here. Can you please hold off a bit? I've almost completed the revert, but haven't pushed it yet. Once that's in we can check whether it also fixes this issue. Thanks! From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 21 13:00:53 2019 Received: (at 34655) by debbugs.gnu.org; 21 Mar 2019 17:00:53 +0000 Received: from localhost ([127.0.0.1]:53454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h713k-0001PZ-St for submit@debbugs.gnu.org; Thu, 21 Mar 2019 13:00:53 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35778) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h713j-0001PM-Bv for 34655@debbugs.gnu.org; Thu, 21 Mar 2019 13:00:51 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41676) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h713b-0004b1-PE; Thu, 21 Mar 2019 13:00:44 -0400 Received: from [176.228.60.248] (port=1414 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h713b-0007d8-2A; Thu, 21 Mar 2019 13:00:43 -0400 Date: Thu, 21 Mar 2019 19:00:42 +0200 Message-Id: <831s30upqd.fsf@gnu.org> From: Eli Zaretskii To: Philipp Stephani , Stefan Monnier In-reply-to: (message from Philipp Stephani on Thu, 21 Mar 2019 17:11:41 +0100) Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> <835zsgw3ui.fsf@gnu.org> <87ef7486h0.fsf@tcd.ie> <83r2b4ul1c.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: contovob@tcd.ie, 34655@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Philipp Stephani > Date: Thu, 21 Mar 2019 17:11:41 +0100 > Cc: "Basil L. Contovounesios" , 34655@debbugs.gnu.org > > I haven't checked everything in detail, but my impression is that this > is rather another instance of bug#31238. Fixing this only when module > assertions are enabled will probably not fix anything, but rather mask > issues. Reverting commit 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a is > still the right approach here. Can you please hold off a bit? I've > almost completed the revert, but haven't pushed it yet. Once that's in > we can check whether it also fixes this issue. I will CC Stefan, who committed 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a. I'm not sure we should revert that; we could instead add GC protection for those parts that need it. And the list consed by module-assertions certainly is one of those. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 21 14:28:26 2019 Received: (at 34655) by debbugs.gnu.org; 21 Mar 2019 18:28:26 +0000 Received: from localhost ([127.0.0.1]:53548 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h72QU-0003Yn-3Q for submit@debbugs.gnu.org; Thu, 21 Mar 2019 14:28:26 -0400 Received: from mail-ot1-f45.google.com ([209.85.210.45]:45932) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h72QS-0003YZ-KY for 34655@debbugs.gnu.org; Thu, 21 Mar 2019 14:28:25 -0400 Received: by mail-ot1-f45.google.com with SMTP id e5so5314611otk.12 for <34655@debbugs.gnu.org>; Thu, 21 Mar 2019 11:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=qqEc+6xb93fa3eMSS1Ub0YcJxEBu+LoMzI5n+6rUbDM=; b=kUFtUIqQ+abqRIHNuSe7SOzjdQWNgWlx6wvNT8MCxDvnZNtIvNbmyLb3gx+CT+b3Um PGZDGmTw1uKc9F99JrSnITaL8tSPTnA5W1MpKx+nmBuAg8FKlGg3Zp5wlYduyPTT1c2u OJuaA41fGiIE6KNZJ6oCFXJLK2xfH2JZmBTEVaJIaURoakc1vU9CXiX0QY3AS3QY9ul0 gKaVrUNMVNOAzLCgY8vzr43u5jhMfaBpxYHj7cPvbCaxMLxseA0A53gUkN/kmCs4k9/b hAtYVjtbnuplzvqOfrH87JXrduUJ07tQfVjxvJrTwIvQbu2yYhqUN2dY4HYhYWrY0hKu B79A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=qqEc+6xb93fa3eMSS1Ub0YcJxEBu+LoMzI5n+6rUbDM=; b=IdetEn9J6Ol80fn366Dd21No+U/sLWzZJVzHfxrpImQK/hGj7pguhLDsNE+aTXUUfs 9CMBFRIoFa+iwQmUPyEmJEGp2xYKJ/6L14rzmAPzTdze6DmU+6ozowq1xq+oTmxWoJus 3t2/OqKLpSRbzntX3oeuOISYVi+Ak0LAlMS0/Fzqob1xFscrO5ZTqyuX/FGJumrP2YHf P60POKf//DR7auPfmu/p2v9/YH3yhhYbGZsZ3EtPCQZPwFoO3ozrpzp5EeA77h/7Euvq 0YuGHRT/Hiiq7ptPp0BpqwhoAxWvhDADh/TudowB7LyNw8WNvO4d2TvG8FVWFgjR3/yB Vsjg== X-Gm-Message-State: APjAAAWIocMw8TKAphZeezYXCsU5mVTzErt0yB3YGwznaM/qZXLA3TYw ht1RwCjiPGMgdgQ8shbyp6eY+r4w1UqX684xn2E= X-Google-Smtp-Source: APXvYqySdygcqUQ+TwPZ2+HiVC3V06hP4lC9+Z4QOqqPDxz6uAk+0/kuP5wZtkRtlMkFeJC200CW27EQtzcqHOQ1roI= X-Received: by 2002:a05:6830:15d2:: with SMTP id j18mr3337864otr.37.1553192898554; Thu, 21 Mar 2019 11:28:18 -0700 (PDT) MIME-Version: 1.0 References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> <835zsgw3ui.fsf@gnu.org> <87ef7486h0.fsf@tcd.ie> <83r2b4ul1c.fsf@gnu.org> <831s30upqd.fsf@gnu.org> In-Reply-To: <831s30upqd.fsf@gnu.org> From: Philipp Stephani Date: Thu, 21 Mar 2019 19:28:07 +0100 Message-ID: Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 34655 Cc: "Basil L. Contovounesios" , 34655@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Am Do., 21. M=C3=A4rz 2019 um 18:00 Uhr schrieb Eli Zaretskii : > > > From: Philipp Stephani > > Date: Thu, 21 Mar 2019 17:11:41 +0100 > > Cc: "Basil L. Contovounesios" , 34655@debbugs.gnu.org > > > > I haven't checked everything in detail, but my impression is that this > > is rather another instance of bug#31238. Fixing this only when module > > assertions are enabled will probably not fix anything, but rather mask > > issues. Reverting commit 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a is > > still the right approach here. Can you please hold off a bit? I've > > almost completed the revert, but haven't pushed it yet. Once that's in > > we can check whether it also fixes this issue. > > I will CC Stefan, who committed 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a. > > I'm not sure we should revert that; we could instead add GC protection > for those parts that need it. Yes, that's what reverting that commit does :-) We need to mark the objects in all cases, not just when module assertions are enabled. Note that both the designer of the module API (Daniel) and I as one of its main implementers disagree with commit 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a. I'm happy to discuss alternatives, but for now we should revert it and discuss the alternatives *before* implementing them. I've already confirmed that reverting commit 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a fixes bug#31238, and I can try it with this bug as well. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 21 15:23:50 2019 Received: (at 34655) by debbugs.gnu.org; 21 Mar 2019 19:23:50 +0000 Received: from localhost ([127.0.0.1]:53612 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h73I5-0006yO-Q1 for submit@debbugs.gnu.org; Thu, 21 Mar 2019 15:23:50 -0400 Received: from mail-ot1-f44.google.com ([209.85.210.44]:46997) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h73I4-0006y9-7t for 34655@debbugs.gnu.org; Thu, 21 Mar 2019 15:23:48 -0400 Received: by mail-ot1-f44.google.com with SMTP id c18so6410092otl.13 for <34655@debbugs.gnu.org>; Thu, 21 Mar 2019 12:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7ZGwer1W0tdj+wnKS4mp4+J6wlMXpE1xwFAgblo1gUk=; b=jQnpoY0nQHsi7uZanzTSRMgUY272gFzugHDsoQpcGjnBm8YL2vUlv9vJPdSkVHLJGz XtdnUFdC3IvUJUQm5bClhx9VFyUK8kjwMPY1McgccEuvpHfk1x2P+/b4jAb4S9+W7ftJ 1DipYfJX4aATH9jKD4ai9Po+wFhUSmdEQpkVY9epW22lGA9U7Z5v7x4a1YU3naAKdZCJ m8bVAy7dYx9QsCtN5Ph80VtLyhcbJrYT69hnrowgMz6uVfuK9fEMKlTmw+4taf0Fxhuz K3tYw7pgcz7pVorlRPJ+01HnkJJtAV4kbVYRFzlYoAtrY0yewewLWrIhEENarrgQu+Ek zBIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7ZGwer1W0tdj+wnKS4mp4+J6wlMXpE1xwFAgblo1gUk=; b=TE0wW7ObYH7dKD7toMgMUAm4dAyquf5HfhHOKjDjLYrrb6HpzSp2PbnCPWynBmiJko 48wlAUMvTab/OrP9+YBikIAcfeHvYc1jif91evmF9eLDQwHB+okSf6RkTDUdHDhSjse7 PyzgXmaKUZXIMUHyxlXDLAPTd5/uk1F8K6LFa7TQF6iLgEkjlF8tpt4wrAuEy3/3rgRZ Go18IEUX1w8aYQ4ngM+n0KRby3SRA7e4fr7Qb7voA9NBLo/u0+txInQlHDk2B4eJutmy O69p5OkMYT3pCgkq7OmZSv0l5ZsNKpy3E1LQLXQ53DB8TEQoey1RY6y6catJ0qu6w88s ox2w== X-Gm-Message-State: APjAAAUiIIxhokhpsT0xtaIaA4XwwuTCelEDIVWi/8bklQ9O9jscW6XS NX1FH1WRzogfawiIAyAbXBDIw+1pddu5FIXouIw= X-Google-Smtp-Source: APXvYqyEQUGEDxIuRr/aH5x0fvKRUZY+6oDtnmoG6xAFXygt4IX52EV4Ga1XWMbOuPF4btmPpbmiXESmENOgzWB2mMk= X-Received: by 2002:a9d:62c8:: with SMTP id z8mr3797319otk.144.1553196221499; Thu, 21 Mar 2019 12:23:41 -0700 (PDT) MIME-Version: 1.0 References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> <835zsgw3ui.fsf@gnu.org> <87ef7486h0.fsf@tcd.ie> <83r2b4ul1c.fsf@gnu.org> <831s30upqd.fsf@gnu.org> In-Reply-To: From: Philipp Stephani Date: Thu, 21 Mar 2019 20:23:30 +0100 Message-ID: Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 34655 Cc: "Basil L. Contovounesios" , 34655@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Am Do., 21. M=C3=A4rz 2019 um 19:28 Uhr schrieb Philipp Stephani : > > Am Do., 21. M=C3=A4rz 2019 um 18:00 Uhr schrieb Eli Zaretskii : > > > > > From: Philipp Stephani > > > Date: Thu, 21 Mar 2019 17:11:41 +0100 > > > Cc: "Basil L. Contovounesios" , 34655@debbugs.gnu.or= g > > > > > > I haven't checked everything in detail, but my impression is that thi= s > > > is rather another instance of bug#31238. Fixing this only when module > > > assertions are enabled will probably not fix anything, but rather mas= k > > > issues. Reverting commit 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a is > > > still the right approach here. Can you please hold off a bit? I've > > > almost completed the revert, but haven't pushed it yet. Once that's i= n > > > we can check whether it also fixes this issue. > > > > I will CC Stefan, who committed 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243= a. > > > > I'm not sure we should revert that; we could instead add GC protection > > for those parts that need it. > > Yes, that's what reverting that commit does :-) > We need to mark the objects in all cases, not just when module > assertions are enabled. > Note that both the designer of the module API (Daniel) and I as one of > its main implementers disagree with commit > 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a. I'm happy to discuss > alternatives, but for now we should revert it and discuss the > alternatives *before* implementing them. I've already confirmed that > reverting commit 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a fixes > bug#31238, and I can try it with this bug as well. I wasn't able to reproduce bug#34655 myself (these things tend to be rather flaky), but I've now reverted commit 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a, and at least bug#31238 is now consistently fixed (for me at least). Basil, can you check whether you can still reproduce bug#34655 with the current master? Thanks! From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 21 15:27:38 2019 Received: (at 34655) by debbugs.gnu.org; 21 Mar 2019 19:27:38 +0000 Received: from localhost ([127.0.0.1]:53617 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h73Lm-00073s-FA for submit@debbugs.gnu.org; Thu, 21 Mar 2019 15:27:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43002) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h73Lk-00073d-Jp for 34655@debbugs.gnu.org; Thu, 21 Mar 2019 15:27:36 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48068) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h73Le-0000O3-Vx; Thu, 21 Mar 2019 15:27:31 -0400 Received: from [176.228.60.248] (port=2479 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h73La-0002Y2-F8; Thu, 21 Mar 2019 15:27:28 -0400 Date: Thu, 21 Mar 2019 21:27:25 +0200 Message-Id: <83o964t4de.fsf@gnu.org> From: Eli Zaretskii To: Philipp Stephani In-reply-to: (message from Philipp Stephani on Thu, 21 Mar 2019 19:28:07 +0100) Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> <835zsgw3ui.fsf@gnu.org> <87ef7486h0.fsf@tcd.ie> <83r2b4ul1c.fsf@gnu.org> <831s30upqd.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: contovob@tcd.ie, 34655@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > I will CC Stefan, who committed 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a. > > > > I'm not sure we should revert that; we could instead add GC protection > > for those parts that need it. > > Yes, that's what reverting that commit does :-) AFAIU, it does much more. Stefan intended for the conservative stack marking to do the job, so maybe there's a little more that should be done to get there. Or maybe Stefan didn't consider some important factor(s). In either case, I'd like to hear his POV on this before we decide how to proceed. > We need to mark the objects in all cases, not just when module > assertions are enabled. If we get stack marking to work, we won't need to mark objects explicitly. > Note that both the designer of the module API (Daniel) and I as one of > its main implementers disagree with commit > 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a. OK, but I think Stefan's opinion is not less important. > I've already confirmed that reverting commit > 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a fixes bug#31238, and I can > try it with this bug as well. Please do, it's important to know that, I think. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 21 15:34:18 2019 Received: (at 34655) by debbugs.gnu.org; 21 Mar 2019 19:34:18 +0000 Received: from localhost ([127.0.0.1]:53625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h73SD-0007Et-LJ for submit@debbugs.gnu.org; Thu, 21 Mar 2019 15:34:17 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43938) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h73SB-0007Eg-Mr for 34655@debbugs.gnu.org; Thu, 21 Mar 2019 15:34:16 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h73S4-0002T9-PT; Thu, 21 Mar 2019 15:34:08 -0400 Received: from [176.228.60.248] (port=2891 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h73S2-0004kr-TM; Thu, 21 Mar 2019 15:34:08 -0400 Date: Thu, 21 Mar 2019 21:34:06 +0200 Message-Id: <83mulot429.fsf@gnu.org> From: Eli Zaretskii To: Philipp Stephani In-reply-to: (message from Philipp Stephani on Thu, 21 Mar 2019 20:23:30 +0100) Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> <835zsgw3ui.fsf@gnu.org> <87ef7486h0.fsf@tcd.ie> <83r2b4ul1c.fsf@gnu.org> <831s30upqd.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: contovob@tcd.ie, 34655@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Philipp Stephani > Date: Thu, 21 Mar 2019 20:23:30 +0100 > Cc: Stefan Monnier , "Basil L. Contovounesios" , 34655@debbugs.gnu.org > > I wasn't able to reproduce bug#34655 myself (these things tend to be > rather flaky), but I've now reverted commit > 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a And I've just reverted the revert. I'm sorry, but you cannot apply rules unilaterally: if you think it's not OK to make changes without waiting for consensus, please adhere to the same principles when you want to make your own changes. Let's wait for this discussion to run to completion, before we are doing any more changes in this area. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 21 15:37:43 2019 Received: (at 34655) by debbugs.gnu.org; 21 Mar 2019 19:37:43 +0000 Received: from localhost ([127.0.0.1]:53630 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h73VX-0007Jg-8e for submit@debbugs.gnu.org; Thu, 21 Mar 2019 15:37:43 -0400 Received: from mail-oi1-f176.google.com ([209.85.167.176]:39796) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h73VV-0007JU-Je for 34655@debbugs.gnu.org; Thu, 21 Mar 2019 15:37:41 -0400 Received: by mail-oi1-f176.google.com with SMTP id b4so5563775oif.6 for <34655@debbugs.gnu.org>; Thu, 21 Mar 2019 12:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UaKkp5g9H4xh7q/2BFkU0u7+eV3jG2rtUOB3Z3JmCdo=; b=CONySdMqtqQVt9OoC+j0H4i7fkalK9R3hRZAu2m4/9dwC4HObjFkSAOg44Fxx5TuND uur09gmAX+rtCffLmNiP+FggT+kc3xCXMmV2vfgw76NdSxLAvo0wNXBoBDWH4fH0gay9 1/G6ta0Vn8ZzYW3RLSrhF3uFfA5GDh7t1FWEqqO2x52yR1k6zg4iuJR/B8mexUSMEEfJ qtJD4Bz/d651a7dEtdYv567pHpXWw9lqEezPMU4Zj1/09dRbyVLIMhFfpIF/45CRIhEM Zn/MNQZ3szSwI39xFjvoam4fvTXS4cTmOVwqcO0YnbdWnMOL0QgXIdwuI+HXUcJsPRUH wopw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=UaKkp5g9H4xh7q/2BFkU0u7+eV3jG2rtUOB3Z3JmCdo=; b=oBdFdPbjW2iom+alAQ5oslRDHsrm86wDR2jBilw8SOb8H5w34SXisqM5wMXHsIHGt4 8NSjGEfto0fXEfUZsaOfzRrF9jaacDmYxcuPhV6xY4uF26pXOpGu6zMLUl9H4HSsOQOJ GfezxE2nPodBYEB3omrdEtx14VcPqe2JSYF70WlpOhGJVYHHKCqW8NsLYDpwpkBhWcvp uzWx5aaubgGwzPjgtr8gbknSXSFMzfbMZh+wZSmcLtqVWa9bKfbs00Aw7ank3b5iRtqC eIdzjFuLCQskdrqSlct+nbCMPQbi3nBRTri0PRYdTiWb1RaET6RHrPUAy6kafsGaNYzl fLTA== X-Gm-Message-State: APjAAAUDXCkNQRFJerxJ3bT2j1W97iZFxBy0Ss+ErRr27jYco3PdgLPl Kpqd6o2UfzBCuR6619cKYtDpKVTx13jmsMiN8Eo= X-Google-Smtp-Source: APXvYqxTRZk2HGCSMqNc9os3ibqE+DdYpdOYSiRsvLBQvI50N6DtE6kxNnguhKfFBTDtWC9HXl+P03jsPP7H27x3yJk= X-Received: by 2002:aca:eb10:: with SMTP id j16mr731071oih.65.1553197055798; Thu, 21 Mar 2019 12:37:35 -0700 (PDT) MIME-Version: 1.0 References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> <835zsgw3ui.fsf@gnu.org> <87ef7486h0.fsf@tcd.ie> <83r2b4ul1c.fsf@gnu.org> <831s30upqd.fsf@gnu.org> <83o964t4de.fsf@gnu.org> In-Reply-To: <83o964t4de.fsf@gnu.org> From: Philipp Stephani Date: Thu, 21 Mar 2019 20:37:24 +0100 Message-ID: Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 34655 Cc: "Basil L. Contovounesios" , 34655@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Am Do., 21. M=C3=A4rz 2019 um 20:27 Uhr schrieb Eli Zaretskii : > > > > I will CC Stefan, who committed 3eb93c07f7a60ac9ce8a16f10c3afd5a3a312= 43a. > > > > > > I'm not sure we should revert that; we could instead add GC protectio= n > > > for those parts that need it. > > > > Yes, that's what reverting that commit does :-) > > AFAIU, it does much more. Stefan intended for the conservative stack > marking to do the job, so maybe there's a little more that should be > done to get there. Or maybe Stefan didn't consider some important > factor(s). In either case, I'd like to hear his POV on this before we > decide how to proceed. Let's go back to the known good state first, and then discuss how to go from there. > > > We need to mark the objects in all cases, not just when module > > assertions are enabled. > > If we get stack marking to work, we won't need to mark objects > explicitly. We can't get stack marking to work, even theoretically. A module is free to do emacs_value x =3D ...; uintptr_t y =3D ((uintrptr_t) x) ^ 0x123456u; (garbage-collect) emacs_value z =3D (emacs_value) (y ^ 0x123456u); ... use z ... During the garbage collection, x isn't on the stack anywhere, and the garbage collector couldn't possibly find it. Or: emacs_value x =3D ...; emacs_value *y =3D malloc (sizeof emacs_value); *y =3D x; ... stop using x... (garbage-collect) ...use *y ... Again, during garbage collection x is no longer on the stack. We can only use stack scanning in Emacs because we control the Emacs source code and can make sure these patterns don't occur. Module code is completely arbitrary. > > > Note that both the designer of the module API (Daniel) and I as one of > > its main implementers disagree with commit > > 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a. > > OK, but I think Stefan's opinion is not less important. I value his opinion, but again: let's make the thing work first, and then discuss options. > > > I've already confirmed that reverting commit > > 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a fixes bug#31238, and I can > > try it with this bug as well. > > Please do, it's important to know that, I think. Basil, could you check that with the revert your code now works? Thanks! From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 21 15:50:47 2019 Received: (at 34655) by debbugs.gnu.org; 21 Mar 2019 19:50:47 +0000 Received: from localhost ([127.0.0.1]:53640 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h73iB-0007ch-1G for submit@debbugs.gnu.org; Thu, 21 Mar 2019 15:50:47 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48294) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h73iA-0007cU-5Y for 34655@debbugs.gnu.org; Thu, 21 Mar 2019 15:50:46 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48429) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h73i2-00083I-JU; Thu, 21 Mar 2019 15:50:39 -0400 Received: from [176.228.60.248] (port=4073 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h73i1-0006Cz-Kk; Thu, 21 Mar 2019 15:50:38 -0400 Date: Thu, 21 Mar 2019 21:50:36 +0200 Message-Id: <83lg18t3ar.fsf@gnu.org> From: Eli Zaretskii To: Philipp Stephani In-reply-to: (message from Philipp Stephani on Thu, 21 Mar 2019 20:37:24 +0100) Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> <835zsgw3ui.fsf@gnu.org> <87ef7486h0.fsf@tcd.ie> <83r2b4ul1c.fsf@gnu.org> <831s30upqd.fsf@gnu.org> <83o964t4de.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: contovob@tcd.ie, 34655@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Philipp Stephani > Date: Thu, 21 Mar 2019 20:37:24 +0100 > Cc: Stefan Monnier , "Basil L. Contovounesios" , 34655@debbugs.gnu.org > > Let's go back to the known good state first, and then discuss how to > go from there. I don't see why that is better than discuss first and then go to where we decide to go. It's not like Emacs 27 will be released any time soon, so there's no rush. > We can't get stack marking to work, even theoretically. > > A module is free to do > > emacs_value x = ...; > uintptr_t y = ((uintrptr_t) x) ^ 0x123456u; > (garbage-collect) > emacs_value z = (emacs_value) (y ^ 0x123456u); > ... use z ... > > During the garbage collection, x isn't on the stack anywhere Why do you think x isn't on the stack in this case? Moreover, emacs_value is actually a pointer to a Lisp object, so this object is also somewhere on the stack, right? > emacs_value x = ...; > emacs_value *y = malloc (sizeof emacs_value); > *y = x; > ... stop using x... > (garbage-collect) > ...use *y ... > > Again, during garbage collection x is no longer on the stack. Why do you think it isn't on the stack? > We can only use stack scanning in Emacs because we control the Emacs > source code Actually, we do nothing special about stack-based values in our sources, except avoiding undefined behavior. > > OK, but I think Stefan's opinion is not less important. > > I value his opinion, but again: let's make the thing work first, and > then discuss options. Fixing one bug doesn't necessarily mean things now "work"; there's always one more bug. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 21 16:02:04 2019 Received: (at 34655) by debbugs.gnu.org; 21 Mar 2019 20:02:04 +0000 Received: from localhost ([127.0.0.1]:53662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h73t6-0007vs-3K for submit@debbugs.gnu.org; Thu, 21 Mar 2019 16:02:04 -0400 Received: from mail-ot1-f68.google.com ([209.85.210.68]:46900) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h73t3-0007vL-Us for 34655@debbugs.gnu.org; Thu, 21 Mar 2019 16:02:02 -0400 Received: by mail-ot1-f68.google.com with SMTP id c18so6513388otl.13 for <34655@debbugs.gnu.org>; Thu, 21 Mar 2019 13:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=KfEqZLbYjgz6P+SwUjqo0vChHeEcQi2hKFNR1Un8zZo=; b=ScHc7+rUcCcjRusM89t68OCEhF9QCyDVyQv4fA/th+6XqX9QFBSGm0k52xcRcbnXqV s4XNqh1Uf5P6sbeYKiCmkyy52gk+OzywHMCnkHmxe4p51f+QLoJZxD5zorZbXt8rhM+/ lZR5jC+DL0UGpc9ZmODrhuy9erS0vybxRksUeHPu8woBgyNJWWw+hs3Rz88KYkMCaOEx 0laFqTyaMh0pS90ZDT3GNBBcYNIe99OewTKlOWyuyaW3wrCTDUPRESe7Xt/Hp2ua5MXT gaRpV5btGbNPsgyky3wi7cFLX3+Ndtd50jNzbXDULwka4Pcr2haNhlPtRoQbKJRMX+Lf xHXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=KfEqZLbYjgz6P+SwUjqo0vChHeEcQi2hKFNR1Un8zZo=; b=Y+pqY3RG1I+oQ1pv4O6KO9/MljF5JP0H9eqn1d73RfXUly2FaMFArvZfVs5P2NoML5 6h0EGR3g1hIrK0VMgFW5memlWqCXoBAZQFMwWdiEjOrg9M5BXoB52NyhHCy3S39/KbSJ rNJosAtZJE4Klkizbi/+Fx782NLNUxWKY2CJevTmIOttNgaoFMzDtY0QLK7PTwEERRG7 ty02YIwjxwNd1rkUN2wOScKbf8ux1VaV/+sZHmM/nIgbSPG1x3DziOZO1fhSzcmiaeiu je9yyoYfszf3KPUxaM95BPLIGsVdWKVS0+YWoL3XFnE/s0aZsqtT5c2X2lMWfFwOGqJb pGqQ== X-Gm-Message-State: APjAAAXA7+rFYRs4SIKehX+WULxM7CfZk+klgNZ0RTTmWxt1ADSWYBfy Cbi9WqRq7J9eFa4np7Xbd8HMJ9tciRC8Dj2dc3A= X-Google-Smtp-Source: APXvYqxaNp1/pypgUVEGZztEGp+UJeYPDgq9TxUL0cVMnzzDs7gaaCkeSN5HoYEBtP4VaCbonhAb7FSgIxcHemFP1ZM= X-Received: by 2002:a9d:62c8:: with SMTP id z8mr3924886otk.144.1553198514773; Thu, 21 Mar 2019 13:01:54 -0700 (PDT) MIME-Version: 1.0 References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> <835zsgw3ui.fsf@gnu.org> <87ef7486h0.fsf@tcd.ie> <83r2b4ul1c.fsf@gnu.org> <831s30upqd.fsf@gnu.org> <83o964t4de.fsf@gnu.org> <83lg18t3ar.fsf@gnu.org> In-Reply-To: <83lg18t3ar.fsf@gnu.org> From: Philipp Stephani Date: Thu, 21 Mar 2019 21:01:43 +0100 Message-ID: Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 34655 Cc: "Basil L. Contovounesios" , 34655@debbugs.gnu.org, Daniel Colascione , Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Am Do., 21. M=C3=A4rz 2019 um 20:50 Uhr schrieb Eli Zaretskii : > > > From: Philipp Stephani > > Date: Thu, 21 Mar 2019 20:37:24 +0100 > > Cc: Stefan Monnier , "Basil L. Contovounesios= " , 34655@debbugs.gnu.org > > > > Let's go back to the known good state first, and then discuss how to > > go from there. > > I don't see why that is better than discuss first and then go to where > we decide to go. It's not like Emacs 27 will be released any time > soon, so there's no rush. For one, it becomes harder and harder to revert commits the older they get. Also such discussions tend to turn into endless debates about the "perfect" solution until one side gives up, without improving anything. I strongly prefer fixing actual bugs that affect users in practice and then discussing (or not discussing) the gold-plating steps later. > > > We can't get stack marking to work, even theoretically. > > > > A module is free to do > > > > emacs_value x =3D ...; > > uintptr_t y =3D ((uintrptr_t) x) ^ 0x123456u; > > (garbage-collect) > > emacs_value z =3D (emacs_value) (y ^ 0x123456u); > > ... use z ... > > > > During the garbage collection, x isn't on the stack anywhere > > Why do you think x isn't on the stack in this case? Because the compiler reused the stack slot for something else? Because the module is written in a language that doesn't use the stack in a way that the garbage collector expects? There's no reason to assume modules have any form of C-compatible stack layout. > > Moreover, emacs_value is actually a pointer to a Lisp object, so this > object is also somewhere on the stack, right? > > > emacs_value x =3D ...; > > emacs_value *y =3D malloc (sizeof emacs_value); > > *y =3D x; > > ... stop using x... > > (garbage-collect) > > ...use *y ... > > > > Again, during garbage collection x is no longer on the stack. > > Why do you think it isn't on the stack? Same as above. > > > We can only use stack scanning in Emacs because we control the Emacs > > source code > > Actually, we do nothing special about stack-based values in our > sources, except avoiding undefined behavior. (Stack scanning is undefined behavior, but that's not the point.) We do something very specific with the stack: we make sure that Lisp_Objects are never manipulated in a way similar to the above, and we use the C language. > > > > OK, but I think Stefan's opinion is not less important. > > > > I value his opinion, but again: let's make the thing work first, and > > then discuss options. > > Fixing one bug doesn't necessarily mean things now "work"; there's > always one more bug. That might be theoretically true, but shouldn't impact decisions until that bug is actually found. All regression tests still pass after reverting the commit. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 21 16:14:56 2019 Received: (at 34655) by debbugs.gnu.org; 21 Mar 2019 20:14:56 +0000 Received: from localhost ([127.0.0.1]:53676 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h745Y-0008EI-3v for submit@debbugs.gnu.org; Thu, 21 Mar 2019 16:14:56 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52992) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h745V-0008E3-Vp for 34655@debbugs.gnu.org; Thu, 21 Mar 2019 16:14:55 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49150) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h745P-0006To-FP; Thu, 21 Mar 2019 16:14:47 -0400 Received: from [176.228.60.248] (port=1589 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h745O-00020t-Dl; Thu, 21 Mar 2019 16:14:46 -0400 Date: Thu, 21 Mar 2019 22:14:46 +0200 Message-Id: <83k1gst26h.fsf@gnu.org> From: Eli Zaretskii To: Philipp Stephani In-reply-to: (message from Philipp Stephani on Thu, 21 Mar 2019 21:01:43 +0100) Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> <835zsgw3ui.fsf@gnu.org> <87ef7486h0.fsf@tcd.ie> <83r2b4ul1c.fsf@gnu.org> <831s30upqd.fsf@gnu.org> <83o964t4de.fsf@gnu.org> <83lg18t3ar.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: contovob@tcd.ie, 34655@debbugs.gnu.org, dancol@dancol.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Philipp Stephani > Date: Thu, 21 Mar 2019 21:01:43 +0100 > Cc: Stefan Monnier , "Basil L. Contovounesios" , 34655@debbugs.gnu.org, > Daniel Colascione > > Am Do., 21. März 2019 um 20:50 Uhr schrieb Eli Zaretskii : > > > > > From: Philipp Stephani > > > Date: Thu, 21 Mar 2019 20:37:24 +0100 > > > Cc: Stefan Monnier , "Basil L. Contovounesios" , 34655@debbugs.gnu.org > > > > > > Let's go back to the known good state first, and then discuss how to > > > go from there. > > > > I don't see why that is better than discuss first and then go to where > > we decide to go. It's not like Emacs 27 will be released any time > > soon, so there's no rush. > > For one, it becomes harder and harder to revert commits the older they > get. Also such discussions tend to turn into endless debates about the > "perfect" solution until one side gives up, without improving > anything. I strongly prefer fixing actual bugs that affect users in > practice and then discussing (or not discussing) the gold-plating > steps later. I also prefer fixing bugs (which is why I spent several hours looking into Basil's crash, when no one else was replying to that bug report), but this is a community project, so we should discuss first and act later. Especially when controversial issues are involved. > > > We can't get stack marking to work, even theoretically. > > > > > > A module is free to do > > > > > > emacs_value x = ...; > > > uintptr_t y = ((uintrptr_t) x) ^ 0x123456u; > > > (garbage-collect) > > > emacs_value z = (emacs_value) (y ^ 0x123456u); > > > ... use z ... > > > > > > During the garbage collection, x isn't on the stack anywhere > > > > Why do you think x isn't on the stack in this case? > > Because the compiler reused the stack slot for something else? How can it? You are using the same pointer later. Garbage collection cannot happen unless you call an Emacs function, such as Ffuncall. Calling a function means that even if the pointer to a Lisp object was in a register, it will be put on the stack when calling Emacs. > Because the module is written in a language that doesn't use the stack > in a way that the garbage collector expects? Which language is that, and how can it use the emacs-module machinery? > > Moreover, emacs_value is actually a pointer to a Lisp object, so this > > object is also somewhere on the stack, right? No answer? > We do something very specific with the stack: we make sure that > Lisp_Objects are never manipulated in a way similar to the above, and > we use the C language. If worse comes to worst, we can request module writers to adhere to the same discipline. We already request them to do/not to do quite a few extraordinary things. > All regression tests still pass after reverting the commit. Didn't they also pass before? From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 21 16:26:44 2019 Received: (at 34655) by debbugs.gnu.org; 21 Mar 2019 20:26:44 +0000 Received: from localhost ([127.0.0.1]:53689 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h74Gx-00006B-UQ for submit@debbugs.gnu.org; Thu, 21 Mar 2019 16:26:44 -0400 Received: from mail-oi1-f177.google.com ([209.85.167.177]:36868) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h74Gw-00005n-BF for 34655@debbugs.gnu.org; Thu, 21 Mar 2019 16:26:42 -0400 Received: by mail-oi1-f177.google.com with SMTP id v84so48908oif.4 for <34655@debbugs.gnu.org>; Thu, 21 Mar 2019 13:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=625FkH1nKZq6HzVmVeVuEqczj4QfqNuIgw/RykdwNL4=; b=A0E1UA89Ehy7G0vW7PIh0XQG2djdullnF+rdLoEcKdrR7q7xRnM0RDcysbHoz8/yQG dygXggxxt/jkcak9CVehKyqBjY9OzwKWrzcgaanrIHzdAmL+vcfR0WTG6UGdB3hm92Zh e/KpgniSsrR88wIjhFR1e9C4NHm3TFeNwY+BeU5UtsWOwl5gXeO0RnxTithLcFUl0mys BoKtzfxb5qlMNvd7Pj9ckc0kP82+hmnBxKhnxaQzhXb45wG5iDlEFfE906pMEEI2058N 1EISIvW/vVm8JnULVvuFbhEoCo+VV/Ni5XKBNI3HvOoxOgL0WnAjGAWq94bjrS2EvBfK ljIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=625FkH1nKZq6HzVmVeVuEqczj4QfqNuIgw/RykdwNL4=; b=n7pecDwF1rHSOXxPG6uUyoUignWwKH1czzoltEW3bXtg3j7FYr4MtFp4C1caShtxus /h4S1rU1zmnpcuTP2UjN4ls6OKpmJrwQzQi5rZrQxfEpducdOjKvmQ1Ud6t4UU8CKOou k/o9Wcx3WTCK857Oh8n2leoIqIHDROG7FpYSMPNZx38i1DuIYEMM+rLi9RupHeT0YY7Z PdjADfiSKoOY/UtkVQtoxgbG7GKeOtCrbGa2FeL/4gtJVIWscWG8iEJYUbeZpELg1Qjw vhkvj4CT1BGLck/9L33ajAR6+xDHB/RsKJL0cEnGYK4R9alwgEc+IBptXUgfXQ3LP95D ZTtQ== X-Gm-Message-State: APjAAAW/Suhh7tHUGnI8pHJpOKlcjbNMLl4U4/AF2jaBJZvqVxkpPz1A +ExSgcW4oMUhMC27Kwea4MrLdUuAIKlwpy7R42w= X-Google-Smtp-Source: APXvYqxY11tY5+8nlHbvTgzGIHJ7PQ/pobYXVErf1rudlYrEB3xpfHU9xSDIc8pJoCid8VA1eN/7KrPlmGElmFeQRSE= X-Received: by 2002:aca:d409:: with SMTP id l9mr922137oig.98.1553199996515; Thu, 21 Mar 2019 13:26:36 -0700 (PDT) MIME-Version: 1.0 References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> <835zsgw3ui.fsf@gnu.org> <87ef7486h0.fsf@tcd.ie> <83r2b4ul1c.fsf@gnu.org> <831s30upqd.fsf@gnu.org> <83o964t4de.fsf@gnu.org> <83lg18t3ar.fsf@gnu.org> <83k1gst26h.fsf@gnu.org> In-Reply-To: <83k1gst26h.fsf@gnu.org> From: Philipp Stephani Date: Thu, 21 Mar 2019 21:26:25 +0100 Message-ID: Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 34655 Cc: "Basil L. Contovounesios" , 34655@debbugs.gnu.org, Daniel Colascione , Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Am Do., 21. M=C3=A4rz 2019 um 21:14 Uhr schrieb Eli Zaretskii : > > > From: Philipp Stephani > > Date: Thu, 21 Mar 2019 21:01:43 +0100 > > Cc: Stefan Monnier , "Basil L. Contovounesios= " , 34655@debbugs.gnu.org, > > Daniel Colascione > > > > Am Do., 21. M=C3=A4rz 2019 um 20:50 Uhr schrieb Eli Zaretskii : > > > > > > > From: Philipp Stephani > > > > Date: Thu, 21 Mar 2019 20:37:24 +0100 > > > > Cc: Stefan Monnier , "Basil L. Contovoune= sios" , 34655@debbugs.gnu.org > > > > > > > > Let's go back to the known good state first, and then discuss how t= o > > > > go from there. > > > > > > I don't see why that is better than discuss first and then go to wher= e > > > we decide to go. It's not like Emacs 27 will be released any time > > > soon, so there's no rush. > > > > For one, it becomes harder and harder to revert commits the older they > > get. Also such discussions tend to turn into endless debates about the > > "perfect" solution until one side gives up, without improving > > anything. I strongly prefer fixing actual bugs that affect users in > > practice and then discussing (or not discussing) the gold-plating > > steps later. > > I also prefer fixing bugs (which is why I spent several hours looking > into Basil's crash, when no one else was replying to that bug report), > but this is a community project, so we should discuss first and act > later. Especially when controversial issues are involved. Well, as you can see, these discussions seem to lead nowhere, and both bug#34655 and bug#31238 remain unfixed. > > > > > We can't get stack marking to work, even theoretically. > > > > > > > > A module is free to do > > > > > > > > emacs_value x =3D ...; > > > > uintptr_t y =3D ((uintrptr_t) x) ^ 0x123456u; > > > > (garbage-collect) > > > > emacs_value z =3D (emacs_value) (y ^ 0x123456u); > > > > ... use z ... > > > > > > > > During the garbage collection, x isn't on the stack anywhere > > > > > > Why do you think x isn't on the stack in this case? > > > > Because the compiler reused the stack slot for something else? > > How can it? You are using the same pointer later. Assume I don't use x later, and only y is on the stack during GC. > Garbage collection > cannot happen unless you call an Emacs function, such as Ffuncall. > Calling a function means that even if the pointer to a Lisp object was > in a register, it will be put on the stack when calling Emacs. No matter whether y here is in a register or on the stack, it's not a Lisp_Value, so the GC can't find it. > > > Because the module is written in a language that doesn't use the stack > > in a way that the garbage collector expects? > > Which language is that, and how can it use the emacs-module machinery? Go, for example. It uses green threads with its own stack management and calling conventions. The GC couldn't ever find such a stack. > > > > Moreover, emacs_value is actually a pointer to a Lisp object, so this > > > object is also somewhere on the stack, right? > > No answer? An emacs_value in the current implementation *is* a Lisp_Object cast to emacs_value. If the emacs_value is not on the stack, then there's no way to find the Lisp_Object. > > > We do something very specific with the stack: we make sure that > > Lisp_Objects are never manipulated in a way similar to the above, and > > we use the C language. > > If worse comes to worst, we can request module writers to adhere to > the same discipline. We already request them to do/not to do quite a > few extraordinary things. No we can't. Modules can contain arbitrary code and call arbitrary libraries, which we can't ever control. We need to work with everything that provides a C-compatible interface. > > > All regression tests still pass after reverting the commit. > > Didn't they also pass before? Yes, but the reproduction steps in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D31238 didn't. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 21 16:45:13 2019 Received: (at 34655) by debbugs.gnu.org; 21 Mar 2019 20:45:13 +0000 Received: from localhost ([127.0.0.1]:53709 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h74Yq-0002m5-8W for submit@debbugs.gnu.org; Thu, 21 Mar 2019 16:45:12 -0400 Received: from eggs.gnu.org ([209.51.188.92]:32800) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h74Ym-0002dg-Sb for 34655@debbugs.gnu.org; Thu, 21 Mar 2019 16:45:09 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50391) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h74Yd-0007DB-M4; Thu, 21 Mar 2019 16:45:00 -0400 Received: from [176.228.60.248] (port=3470 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h74Yd-0006dp-54; Thu, 21 Mar 2019 16:44:59 -0400 Date: Thu, 21 Mar 2019 22:44:58 +0200 Message-Id: <83ftrgt0s5.fsf@gnu.org> From: Eli Zaretskii To: Philipp Stephani In-reply-to: (message from Philipp Stephani on Thu, 21 Mar 2019 21:26:25 +0100) Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> <835zsgw3ui.fsf@gnu.org> <87ef7486h0.fsf@tcd.ie> <83r2b4ul1c.fsf@gnu.org> <831s30upqd.fsf@gnu.org> <83o964t4de.fsf@gnu.org> <83lg18t3ar.fsf@gnu.org> <83k1gst26h.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: contovob@tcd.ie, 34655@debbugs.gnu.org, dancol@dancol.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Philipp Stephani > Date: Thu, 21 Mar 2019 21:26:25 +0100 > Cc: Stefan Monnier , "Basil L. Contovounesios" , 34655@debbugs.gnu.org, > Daniel Colascione > > > I also prefer fixing bugs (which is why I spent several hours looking > > into Basil's crash, when no one else was replying to that bug report), > > but this is a community project, so we should discuss first and act > > later. Especially when controversial issues are involved. > > Well, as you can see, these discussions seem to lead nowhere, and both > bug#34655 and bug#31238 remain unfixed. We have been talking about this just a few minutes, so please don't exaggerate. And bug#34655 could be fixed days ago, it isn't yet because I wanted to hear your opinion, and you asked me to hold off the changes. > > > > Why do you think x isn't on the stack in this case? > > > > > > Because the compiler reused the stack slot for something else? > > > > How can it? You are using the same pointer later. > > Assume I don't use x later, and only y is on the stack during GC. If you don't use x, it can be GC'ed. > > Garbage collection > > cannot happen unless you call an Emacs function, such as Ffuncall. > > Calling a function means that even if the pointer to a Lisp object was > > in a register, it will be put on the stack when calling Emacs. > > No matter whether y here is in a register or on the stack, it's not a > Lisp_Value, so the GC can't find it. But x is. And there's the original Lisp object too, somewhere on the stack. > > > Because the module is written in a language that doesn't use the stack > > > in a way that the garbage collector expects? > > > > Which language is that, and how can it use the emacs-module machinery? > > Go, for example. It uses green threads with its own stack management > and calling conventions. The GC couldn't ever find such a stack. So you are saying that Emacs modules cannot be written in Go? > > > > Moreover, emacs_value is actually a pointer to a Lisp object, so this > > > > object is also somewhere on the stack, right? > > > > No answer? > > An emacs_value in the current implementation *is* a Lisp_Object cast > to emacs_value. Under module-assertions, it's a pointer to a (copy of a) Lisp object. > > If worse comes to worst, we can request module writers to adhere to > > the same discipline. We already request them to do/not to do quite a > > few extraordinary things. > > No we can't. Modules can contain arbitrary code and call arbitrary > libraries, which we can't ever control. We need to work with > everything that provides a C-compatible interface. Emacs modules are written to work with Emacs, so surely we can request them to observe certain rules, especially if they don't want to crash Emacs. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 21 16:48:44 2019 Received: (at 34655) by debbugs.gnu.org; 21 Mar 2019 20:48:44 +0000 Received: from localhost ([127.0.0.1]:53713 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h74cG-0004iE-8N for submit@debbugs.gnu.org; Thu, 21 Mar 2019 16:48:44 -0400 Received: from dancol.org ([96.126.100.184]:34532) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h74cE-0004i5-85 for 34655@debbugs.gnu.org; Thu, 21 Mar 2019 16:48:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=xeRwJWVbqxeqSPUtDfF39AYHV+qxuYyiBZ9r+7Tq8z4=; b=laAC5E+RtV5EbUTRKlK2F8ikQicnudZ8LdBSlWayQKsUKptbovOenSQW+8/adAPCfiX7vLgi8hZ3aD+keKhi7+LeYEFjoxHN9iN7kFxJnN6xwnqfUj/QI+5IY8ki0yOsJo4k9J326omPJ+yDTN9S9O7DFX4MZOlxChyIFuyOfXJ1Yk8lT0hwHfmOmUkmET0w/iVS9wGeMzANPdGl4Ihqzlv91fnXoSRytC3G8m8n++y8GmcDLAYCUQb9cTDc0YnuIuj7LJ7BWRO1bitoW+ASSBtiYvyJte4N7a/oReWS1PKzQ3ocyCP+rZDcJbM5Ve24UQPB8YzQ1qvbKYO/bcX4Fw==; Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h74c0-0005o3-Ej; Thu, 21 Mar 2019 13:48:28 -0700 Received: from 127.0.0.1 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Thu, 21 Mar 2019 13:48:28 -0700 Message-ID: <54c0397230795ccc3701339de617d887.squirrel@dancol.org> In-Reply-To: References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> <835zsgw3ui.fsf@gnu.org> <87ef7486h0.fsf@tcd.ie> <83r2b4ul1c.fsf@gnu.org> <831s30upqd.fsf@gnu.org> <83o964t4de.fsf@gnu.org> <83lg18t3ar.fsf@gnu.org> <83k1gst26h.fsf@gnu.org> Date: Thu, 21 Mar 2019 13:48:28 -0700 Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions From: "Daniel Colascione" To: "Philipp Stephani" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: "Basil L. Contovounesios" , 34655@debbugs.gnu.org, Eli Zaretskii , Daniel Colascione , Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Am Do., 21. März 2019 um 21:14 Uhr schrieb Eli Zaretskii : >> >> > From: Philipp Stephani >> > Date: Thu, 21 Mar 2019 21:01:43 +0100 >> > Cc: Stefan Monnier , "Basil L. >> Contovounesios" , 34655@debbugs.gnu.org, >> > Daniel Colascione >> > >> > Am Do., 21. März 2019 um 20:50 Uhr schrieb Eli Zaretskii >> : >> > > >> > > > From: Philipp Stephani >> > > > Date: Thu, 21 Mar 2019 20:37:24 +0100 >> > > > Cc: Stefan Monnier , "Basil L. >> Contovounesios" , 34655@debbugs.gnu.org >> > > > >> > > > Let's go back to the known good state first, and then discuss how >> to >> > > > go from there. >> > > >> > > I don't see why that is better than discuss first and then go to >> where >> > > we decide to go. It's not like Emacs 27 will be released any time >> > > soon, so there's no rush. >> > >> > For one, it becomes harder and harder to revert commits the older they >> > get. Also such discussions tend to turn into endless debates about the >> > "perfect" solution until one side gives up, without improving >> > anything. I strongly prefer fixing actual bugs that affect users in >> > practice and then discussing (or not discussing) the gold-plating >> > steps later. >> >> I also prefer fixing bugs (which is why I spent several hours looking >> into Basil's crash, when no one else was replying to that bug report), >> but this is a community project, so we should discuss first and act >> later. Especially when controversial issues are involved. > > Well, as you can see, these discussions seem to lead nowhere, and both > bug#34655 and bug#31238 remain unfixed. > >> >> > > > We can't get stack marking to work, even theoretically. >> > > > >> > > > A module is free to do >> > > > >> > > > emacs_value x = ...; >> > > > uintptr_t y = ((uintrptr_t) x) ^ 0x123456u; >> > > > (garbage-collect) >> > > > emacs_value z = (emacs_value) (y ^ 0x123456u); >> > > > ... use z ... >> > > > >> > > > During the garbage collection, x isn't on the stack anywhere >> > > >> > > Why do you think x isn't on the stack in this case? >> > >> > Because the compiler reused the stack slot for something else? >> >> How can it? You are using the same pointer later. > > Assume I don't use x later, and only y is on the stack during GC. > >> Garbage collection >> cannot happen unless you call an Emacs function, such as Ffuncall. >> Calling a function means that even if the pointer to a Lisp object was >> in a register, it will be put on the stack when calling Emacs. > > No matter whether y here is in a register or on the stack, it's not a > Lisp_Value, so the GC can't find it. > >> >> > Because the module is written in a language that doesn't use the stack >> > in a way that the garbage collector expects? >> >> Which language is that, and how can it use the emacs-module machinery? > > Go, for example. It uses green threads with its own stack management > and calling conventions. The GC couldn't ever find such a stack. > >> >> > > Moreover, emacs_value is actually a pointer to a Lisp object, so >> this >> > > object is also somewhere on the stack, right? >> >> No answer? > > An emacs_value in the current implementation *is* a Lisp_Object cast > to emacs_value. If the emacs_value is not on the stack, then there's > no way to find the Lisp_Object. > >> >> > We do something very specific with the stack: we make sure that >> > Lisp_Objects are never manipulated in a way similar to the above, and >> > we use the C language. >> >> If worse comes to worst, we can request module writers to adhere to >> the same discipline. We already request them to do/not to do quite a >> few extraordinary things. > > No we can't. Modules can contain arbitrary code and call arbitrary > libraries, which we can't ever control. We need to work with > everything that provides a C-compatible interface. Modules can contain arbitrary code, but they don't have to do arbitrary things with that code. Right now, the contract between modules and Emacs is something like "any value that, I, Emacs, can't find on an Emacs-findable thread is fair game for memory reclaimation." In practice, that works okay most of the time, but if we have to deal with environments that can't guarantee that Emacs values remain on the C stack, we can extend the contract with something like "I, module, am handing you, Emacs, an array of emacs_values, and in addition to my stack, you should check this array before considering a value dead" --- that is, we could just provide a way for a module to associate a bunch of additional GC roots with a given context. Then something like Go could stick any temporary Emacs values in this array. Or we could just have these environments create permanent references. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 21 17:29:29 2019 Received: (at 34655) by debbugs.gnu.org; 21 Mar 2019 21:29:29 +0000 Received: from localhost ([127.0.0.1]:53744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h75Fh-0005gI-8l for submit@debbugs.gnu.org; Thu, 21 Mar 2019 17:29:29 -0400 Received: from mail-ed1-f45.google.com ([209.85.208.45]:37921) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h75Ff-0005g2-2h for 34655@debbugs.gnu.org; Thu, 21 Mar 2019 17:29:27 -0400 Received: by mail-ed1-f45.google.com with SMTP id q14so6295090edr.5 for <34655@debbugs.gnu.org>; Thu, 21 Mar 2019 14:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=onfi3pQ2QGSrLt1t8y12+okWY2xSUoC7UWVT9+4NaxE=; b=Or7ViLUkj4pYZoMAZTQQby+MDmYx+9zWk8o/h6lwB1Luwrt//EVqplGQp+Kv3vzILm g8EHQWpk7wCtKV/31QOyT9ZFWi/zlyPBDv+OHkNXcjSEC8SeY6EIOBbvDiwnkNnNrLAF c3vxJYGWx3Ye4YiDdr6BCzFHWxCYS8e6cQgWoP3bWVtSS7HfxyCYiuIjTewKOIPc43r+ zzCai/3Qvv5I4DxPVjmTPJP1N0dxpckh6enlKybJdJiCKrEOr8PUoihh2FDbOvoAHxL7 FORAMhnfNsm0HORYYjPc4EcBLcad2omNzShKLAO6p5xOAWqq6BgU823BcSSu5up3YUsS I2Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=onfi3pQ2QGSrLt1t8y12+okWY2xSUoC7UWVT9+4NaxE=; b=jKPOMu2weA/LA2NQj1ReFJexjS0W0qfxzbpxlquwcMxDPwPaPbd+JoZvpq9GXPxcLD Au6wX55GcqiNFDBk94Vo2FlrX13RXmbLiDqe4PoSv00MnEtpN6b6H9715iB6+19YF5BN 7wB4CCQkrA4jBCyLy7YceIJFqcvRF0oaaZowoR3KHDrfSq1zxTPbznw8IiJ4+UrVfdvH UuVshSIYwumYnHbyW07lV5p3vv3S37VYnWECflRzGv3CujorGorsKlitm2SIakGmjm+X 4FdhOTe58zofXn7QvL8OkzBh5JztwqpBbOGyLhZrmNGkOAzauKEo5aCK74doaYluLz/L /MOQ== X-Gm-Message-State: APjAAAXGaSoNI67KztcZmtVcEjwEzlEI1xCFQDcJVAd+BrA6ds0QndRv fTocSJivcgzuHL4CwaRVTmbxVg== X-Google-Smtp-Source: APXvYqxAryo/4AYFoYyc0HIwlVMJArfPKD03U1KRZ1givUtzwqhlXY9KRZNoLdIyojARISw8onlX9w== X-Received: by 2002:a17:906:f44:: with SMTP id h4mr3358239ejj.4.1553203761325; Thu, 21 Mar 2019 14:29:21 -0700 (PDT) Received: from localhost ([2a02:8084:20e2:c380:20c2:134e:4f3a:683a]) by smtp.gmail.com with ESMTPSA id y12sm914474eju.43.2019.03.21.14.29.20 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 21 Mar 2019 14:29:20 -0700 (PDT) From: "Basil L. Contovounesios" To: Philipp Stephani Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> <835zsgw3ui.fsf@gnu.org> <87ef7486h0.fsf@tcd.ie> <83r2b4ul1c.fsf@gnu.org> <831s30upqd.fsf@gnu.org> Date: Thu, 21 Mar 2019 21:29:14 +0000 In-Reply-To: (Philipp Stephani's message of "Thu, 21 Mar 2019 20:23:30 +0100") Message-ID: <87ftrfex1x.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: 34655@debbugs.gnu.org, Eli Zaretskii , Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Philipp Stephani writes: > Am Do., 21. M=C3=A4rz 2019 um 19:28 Uhr schrieb Philipp Stephani > : >> >> Am Do., 21. M=C3=A4rz 2019 um 18:00 Uhr schrieb Eli Zaretskii : >> > >> > > From: Philipp Stephani >> > > Date: Thu, 21 Mar 2019 17:11:41 +0100 >> > > Cc: "Basil L. Contovounesios" , 34655@debbugs.gnu.o= rg >> > > >> > > I haven't checked everything in detail, but my impression is that th= is >> > > is rather another instance of bug#31238. Fixing this only when module >> > > assertions are enabled will probably not fix anything, but rather ma= sk >> > > issues. Reverting commit 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a is >> > > still the right approach here. Can you please hold off a bit? I've >> > > almost completed the revert, but haven't pushed it yet. Once that's = in >> > > we can check whether it also fixes this issue. >> > >> > I will CC Stefan, who committed 3eb93c07f7a60ac9ce8a16f10c3afd5a3a3124= 3a. >> > >> > I'm not sure we should revert that; we could instead add GC protection >> > for those parts that need it. >> >> Yes, that's what reverting that commit does :-) >> We need to mark the objects in all cases, not just when module >> assertions are enabled. >> Note that both the designer of the module API (Daniel) and I as one of >> its main implementers disagree with commit >> 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a. I'm happy to discuss >> alternatives, but for now we should revert it and discuss the >> alternatives *before* implementing them. I've already confirmed that >> reverting commit 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a fixes >> bug#31238, and I can try it with this bug as well. > > I wasn't able to reproduce bug#34655 myself (these things tend to be > rather flaky), but I've now reverted commit > 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a, and at least bug#31238 is > now consistently fixed (for me at least). Basil, can you check whether > you can still reproduce bug#34655 with the current master? FWIW, I cannot reproduce bug#34655 after reverting Stefan's commit. Thanks, --=20 Basil From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 21 17:31:33 2019 Received: (at 34655) by debbugs.gnu.org; 21 Mar 2019 21:31:33 +0000 Received: from localhost ([127.0.0.1]:53748 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h75Hg-0005km-OI for submit@debbugs.gnu.org; Thu, 21 Mar 2019 17:31:32 -0400 Received: from mail-ed1-f42.google.com ([209.85.208.42]:39065) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h75He-0005kY-Tn for 34655@debbugs.gnu.org; Thu, 21 Mar 2019 17:31:31 -0400 Received: by mail-ed1-f42.google.com with SMTP id p27so6269812edc.6 for <34655@debbugs.gnu.org>; Thu, 21 Mar 2019 14:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=clKEtt258Yrz2inl7gwMNcJRqBMvoAaDeAXmz9EeubA=; b=V/IwlmZxKQW9IybLLOp4OvuWWkLOXGJ7092ODbmiP7eh0yxGH94SghaSRn/C//XpCE BsMpFnX/CYxN0CLVO1J7xiMpAUkiycgm5YS6ZhtufMNDUnpm2kHoF1EPsZBPwWKycF/B Nfo2UuX7gGxFj4xu1xJTPRkG17TKSouT6RS9uEXnDeizhyVTp4gatEF6VwYpaaxuUvo/ +HjwhwLNezRMeWvOHDWXWAwIIE13Ox8Lib6Z5CdXb9evb2vXk96r92pABS2ibPNwwweW e2vO/OLVa2wsnIbZArT6ffw2Xc1BIp3XdWDXrFhhKGZV44ddSu1a+W63m8tTqFObq4MN mmBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=clKEtt258Yrz2inl7gwMNcJRqBMvoAaDeAXmz9EeubA=; b=MaDDdkecF8sbUYeuEGptL3vR3myNUjy/sNRglKc5wlTKvj2D7DoCzQLck0/8FLYw5L mB/AfXy/nBXFY5WthhxJ26jdA2ra0FregGNSJS1SP+AtlVcO6TLSJHRs9PTwKirG9nQP iIlmRLnjQapujlhtLG6kyV0Vs+XR3ONjVeEb/vZksh3uoKmXChcFP3XmUx9Y9UXjZzzG M1jqyQkkML6HlehwHB5DvXbSUM4LDwfN3w2zZLe5txrDJ14horpn5FXDCUgA0wVXkRpN f5LlD47k+EypN5jPisDdPVJg6KpvR1urDd2vOnLzcIRa7cv5TQiGEMoPCMlGKqd2EQTd FJgA== X-Gm-Message-State: APjAAAXZSa2QV9lmY6I8CojRb4McSAo5VRW21IHntfDHIZmuMc9e+zEj JvoCK+HQIFQnyEpZ9jxby36FCv7s9PuDew== X-Google-Smtp-Source: APXvYqyyNBkH2gptWvfGyDF6EuJrx6erVk5aURrpOYOeIfsOBCt8zOEVW4PvIpBgZuNeGKXomffXbw== X-Received: by 2002:a50:b512:: with SMTP id y18mr3785494edd.126.1553203885231; Thu, 21 Mar 2019 14:31:25 -0700 (PDT) Received: from localhost ([2a02:8084:20e2:c380:20c2:134e:4f3a:683a]) by smtp.gmail.com with ESMTPSA id c12sm1913036edt.31.2019.03.21.14.31.24 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 21 Mar 2019 14:31:24 -0700 (PDT) From: "Basil L. Contovounesios" To: Philipp Stephani Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> <835zsgw3ui.fsf@gnu.org> <87ef7486h0.fsf@tcd.ie> <83r2b4ul1c.fsf@gnu.org> <831s30upqd.fsf@gnu.org> <83o964t4de.fsf@gnu.org> Date: Thu, 21 Mar 2019 21:31:23 +0000 In-Reply-To: (Philipp Stephani's message of "Thu, 21 Mar 2019 20:37:24 +0100") Message-ID: <87bm23ewyc.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: 34655@debbugs.gnu.org, Eli Zaretskii , Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Philipp Stephani writes: > Am Do., 21. M=C3=A4rz 2019 um 20:27 Uhr schrieb Eli Zaretskii : >> >> > I've already confirmed that reverting commit >> > 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a fixes bug#31238, and I can >> > try it with this bug as well. >> >> Please do, it's important to know that, I think. > > Basil, could you check that with the revert your code now works? Thanks! The revert indeed makes bug#34655 go away. Thanks, --=20 Basil From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 21 20:56:27 2019 Received: (at 34655) by debbugs.gnu.org; 22 Mar 2019 00:56:27 +0000 Received: from localhost ([127.0.0.1]:53790 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h78Tz-0004XM-2P for submit@debbugs.gnu.org; Thu, 21 Mar 2019 20:56:27 -0400 Received: from mail01.iro.umontreal.ca ([132.204.25.201]:38756) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h78Tx-0004X8-4E for 34655@debbugs.gnu.org; Thu, 21 Mar 2019 20:56:25 -0400 Received: from mail01.iro.umontreal.ca (mail01.iro.umontreal.ca [127.0.0.1]) by mail01.iro.umontreal.ca (Postfix) with ESMTP id D81B1812DFD5 for <34655@debbugs.gnu.org>; Thu, 21 Mar 2019 20:56:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; h=content-type:content-type:mime-version:user-agent:in-reply-to :date:date:references:message-id:subject:subject:to:from:from; s=dkim; t=1553216179; x=1554080180; bh=asAcNDsuaVNybkeFUArhJDEE A4i0MSDOhf2pfWewf7A=; b=XDYeryiJEJ5TxwjoyPumrnLmY6e6M8TBMLnqGjmq dR3CM3GrqejHH+n7qn0qWnnOMoQ25ShR/ZWtpHkmxTYcQNTKeqT68StweRDio4/b uP4q4GArEx/VTQu7t1IKorbygNtPbHPC/YmwK7uE7T40RPeNRdBhTLW+/higU4Vg ZNnXfC6OSjjPZFWOoqNQdms5j1f/OQTF6JyGPnXqVQC4rsSVZpy+uaNQME194unb n+A88MYoG78M0k5oSF0k7DTZX2FO6B+ItVEeXI7/Ma4kRnWybjuFcpBDVrHJAESh v+gqacdV09mijOrpTH1GgSFoTyHJeE5oFmDK9JEv18xSgg== X-Virus-Scanned: amavisd-new at iro.umontreal.ca Received: from mail01.iro.umontreal.ca ([127.0.0.1]) by mail01.iro.umontreal.ca (mail01.iro.umontreal.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXWj0bLhPgnn for <34655@debbugs.gnu.org>; Thu, 21 Mar 2019 20:56:19 -0400 (EDT) Received: from pastel (75-119-242-252.dsl.teksavvy.com [75.119.242.252]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EAE77812DFB8; Thu, 21 Mar 2019 20:56:18 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions Message-ID: References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> <835zsgw3ui.fsf@gnu.org> <87ef7486h0.fsf@tcd.ie> <83r2b4ul1c.fsf@gnu.org> <831s30upqd.fsf@gnu.org> <83o964t4de.fsf@gnu.org> Date: Thu, 21 Mar 2019 20:56:17 -0400 In-Reply-To: <83o964t4de.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 21 Mar 2019 21:27:25 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34655 Cc: contovob@tcd.ie, 34655@debbugs.gnu.org, Philipp Stephani X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > OK, but I think Stefan's opinion is not less important. I think the module API is already so completely different from what I'd like it to be that it's OK to revert my change here. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 22 03:11:22 2019 Received: (at 34655) by debbugs.gnu.org; 22 Mar 2019 07:11:22 +0000 Received: from localhost ([127.0.0.1]:53944 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7EKn-0005VZ-PP for submit@debbugs.gnu.org; Fri, 22 Mar 2019 03:11:22 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40001) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7EKk-0005VJ-63 for 34655@debbugs.gnu.org; Fri, 22 Mar 2019 03:11:19 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52914) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7EKe-0003e7-4L; Fri, 22 Mar 2019 03:11:12 -0400 Received: from [176.228.60.248] (port=2118 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h7EKd-0006yi-CO; Fri, 22 Mar 2019 03:11:11 -0400 Date: Fri, 22 Mar 2019 10:11:13 +0300 Message-Id: <837ecrtmcu.fsf@gnu.org> From: Eli Zaretskii To: "Basil L. Contovounesios" In-reply-to: <87ftrfex1x.fsf@tcd.ie> (contovob@tcd.ie) Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> <835zsgw3ui.fsf@gnu.org> <87ef7486h0.fsf@tcd.ie> <83r2b4ul1c.fsf@gnu.org> <831s30upqd.fsf@gnu.org> <87ftrfex1x.fsf@tcd.ie> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: 34655@debbugs.gnu.org, p.stephani2@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: "Basil L. Contovounesios" > Cc: Eli Zaretskii , Stefan Monnier , 34655@debbugs.gnu.org > Date: Thu, 21 Mar 2019 21:29:14 +0000 > > FWIW, I cannot reproduce bug#34655 after reverting Stefan's commit. Great, thanks for testing. From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 22 04:16:38 2019 Received: (at 34655) by debbugs.gnu.org; 22 Mar 2019 08:16:38 +0000 Received: from localhost ([127.0.0.1]:53962 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7FLx-00072c-SV for submit@debbugs.gnu.org; Fri, 22 Mar 2019 04:16:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52307) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7FLu-00072F-A7; Fri, 22 Mar 2019 04:16:36 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53705) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7FLn-0008BN-7X; Fri, 22 Mar 2019 04:16:27 -0400 Received: from [176.228.60.248] (port=2300 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h7FLm-0001l0-Sw; Fri, 22 Mar 2019 04:16:27 -0400 Date: Fri, 22 Mar 2019 11:16:28 +0300 Message-Id: <83tvfvs4rn.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-reply-to: (message from Stefan Monnier on Thu, 21 Mar 2019 20:56:17 -0400) Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> <835zsgw3ui.fsf@gnu.org> <87ef7486h0.fsf@tcd.ie> <83r2b4ul1c.fsf@gnu.org> <831s30upqd.fsf@gnu.org> <83o964t4de.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: contovob@tcd.ie, 34655@debbugs.gnu.org, p.stephani2@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) merge 31238 34655 close 34655 thanks > From: Stefan Monnier > Cc: Philipp Stephani , contovob@tcd.ie, 34655@debbugs.gnu.org > Date: Thu, 21 Mar 2019 20:56:17 -0400 > > > OK, but I think Stefan's opinion is not less important. > > I think the module API is already so completely different from what I'd > like it to be that it's OK to revert my change here. OK, so I reverted my revert, and I'm marking this bug done. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 22 04:18:03 2019 Received: (at 34655) by debbugs.gnu.org; 22 Mar 2019 08:18:03 +0000 Received: from localhost ([127.0.0.1]:53969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7FNL-00075P-8h for submit@debbugs.gnu.org; Fri, 22 Mar 2019 04:18:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52559) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7FNI-00074v-Q6 for 34655@debbugs.gnu.org; Fri, 22 Mar 2019 04:18:01 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53722) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7FNC-0000nJ-T8; Fri, 22 Mar 2019 04:17:55 -0400 Received: from [176.228.60.248] (port=2390 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h7FNC-0001o9-DJ; Fri, 22 Mar 2019 04:17:54 -0400 Date: Fri, 22 Mar 2019 11:17:56 +0300 Message-Id: <83sgvfs4p7.fsf@gnu.org> From: Eli Zaretskii To: "Daniel Colascione" In-reply-to: <54c0397230795ccc3701339de617d887.squirrel@dancol.org> Subject: Re: bug#34655: 26.1.92; Segfault in module with --module-assertions References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> <835zsgw3ui.fsf@gnu.org> <87ef7486h0.fsf@tcd.ie> <83r2b4ul1c.fsf@gnu.org> <831s30upqd.fsf@gnu.org> <83o964t4de.fsf@gnu.org> <83lg18t3ar.fsf@gnu.org> <83k1gst26h.fsf@gnu.org> <54c0397230795ccc3701339de617d887.squirrel@dancol.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34655 Cc: contovob@tcd.ie, 34655@debbugs.gnu.org, p.stephani2@gmail.com, dancol@dancol.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Date: Thu, 21 Mar 2019 13:48:28 -0700 > From: "Daniel Colascione" > Cc: "Eli Zaretskii" , > "Stefan Monnier" , > "Basil L. Contovounesios" , > 34655@debbugs.gnu.org, > "Daniel Colascione" > > > No we can't. Modules can contain arbitrary code and call arbitrary > > libraries, which we can't ever control. We need to work with > > everything that provides a C-compatible interface. > > Modules can contain arbitrary code, but they don't have to do arbitrary > things with that code. Right now, the contract between modules and Emacs > is something like "any value that, I, Emacs, can't find on an > Emacs-findable thread is fair game for memory reclaimation." In practice, > that works okay most of the time, but if we have to deal with environments > that can't guarantee that Emacs values remain on the C stack, we can > extend the contract with something like "I, module, am handing you, Emacs, > an array of emacs_values, and in addition to my stack, you should check > this array before considering a value dead" --- that is, we could just > provide a way for a module to associate a bunch of additional GC roots > with a given context. Then something like Go could stick any temporary > Emacs values in this array. > > Or we could just have these environments create permanent references. OK, thanks. What are your opinions regarding usability of stack marking for emacs_value variables used by modules? From unknown Sat Jun 21 10:43:02 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 19 Apr 2019 11:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator