From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: MPS: a random backtrace while toying with gdb Date: Sun, 30 Jun 2024 13:05:24 +0300 Message-ID: <86jzi6hhjv.fsf@gnu.org> References: <87bk3jh8bt.fsf@localhost> <867ce7hvvz.fsf@gnu.org> <86tthbgdlr.fsf@gnu.org> <86r0cehkwr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9852"; mail-complaints-to="usenet@ciao.gmane.io" Cc: pipcet@protonmail.com, yantar92@posteo.net, emacs-devel@gnu.org, eller.helmut@gmail.com To: Gerd =?iso-8859-1?Q?M=F6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 30 12:06:12 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sNrRj-0002NT-Um for ged-emacs-devel@m.gmane-mx.org; Sun, 30 Jun 2024 12:06:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sNrRC-0003Nn-Ob; Sun, 30 Jun 2024 06:05:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sNrRB-0003Mn-BG for emacs-devel@gnu.org; Sun, 30 Jun 2024 06:05:37 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sNrRA-0004K9-KA; Sun, 30 Jun 2024 06:05:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=0TicHN8S00hjxBUc2EuBQBFgO55vCtmDMuRXxj0t/zQ=; b=E5737jE+8KUv9j/EtKJO +FTDqDMN+UqSyEo3DvS//xmfr57jEaMTGHn/27K7/tFWbNOW4CRCSBpbwmQ0F5QneoC8MbJV9c4a2 kgS2jARAX82BzrxO1w5mkU5O97izp5sxdMUV0PN6xmtCCY8vAkPw5it/Lb6tq/3pflEBynjoGQC2y ii0SVrpdwsiQicCvBo9aaGicJVLUH6E7UtOfrxHwbUBPLjijegAU8J+QiHVHGxhsxnTuTdA0frLUV NbrxILq5C5SwPrvVTbLLDuU6ulCYwRHAEjex8k4iEfaV1kgyjqIkOsTbiMmsh/AItq64Pkv0mLvuN IEteVlYCNakZwg==; In-Reply-To: (message from Gerd =?iso-8859-1?Q?M=F6llmann?= on Sun, 30 Jun 2024 11:43:56 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:320931 Archived-At: > From: Gerd Möllmann > Cc: pipcet@protonmail.com, yantar92@posteo.net, emacs-devel@gnu.org, > eller.helmut@gmail.com > Date: Sun, 30 Jun 2024 11:43:56 +0200 > > Eli Zaretskii writes: > > > Which unsafe function did we call in this case, though? AFAICT, we > > simply accessed memory that happens to be behind the barrier: > > > > #9 0x00007ffff3048050 in () at /lib64/libc.so.6 > > #10 0x0000555555827385 in PSEUDOVECTORP (a=XIL(0x7fffeb90875d), code=9) at /home/yantar92/Git/emacs/src/lisp.h:1105 > > #11 PROCESSP (a=XIL(0x7fffeb90875d)) at /home/yantar92/Git/emacs/src/process.h:212 > > #12 XPROCESS (a=XIL(0x7fffeb90875d)) at /home/yantar92/Git/emacs/src/process.h:224 > > #13 handle_child_signal (sig=sig@entry=17) at process.c:7660 > > > > Line 7660 of process.c is this: > > > > struct Lisp_Process *p = XPROCESS (proc); > > > > What "crime" did we commit here? > > Not a crime, but we are using a lib that we know uses barriers and > functions of which get invoked when we hit such a barrier. We can't just > ignore that. What alternatives do we have? Emacs code deals with Lisp objects and memory managed by MPS all over the place. In many case, the programmer doesn't necessarily know whether some data is or isn't in memory managed by MPS. You are asking to do the impossible, IMO. Refraining from touching MPS-managed memory from signal handlers is simply not practical in Emacs. E.g., it would make the profiler useless, because the minimum you must do from the signal handler is to see which Lisp function is being run; if you defer this for later, you will see a completely skewed profile.