From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: MPS: a random backtrace while toying with gdb Date: Tue, 02 Jul 2024 06:33:29 +0200 Message-ID: References: <87bk3jh8bt.fsf@localhost> <87wmm6rcv1.fsf@gmail.com> <86le2mhhsj.fsf@gnu.org> <875xtqramd.fsf@gmail.com> <86cynyhfsn.fsf@gnu.org> <87v81qp91g.fsf@gmail.com> <86tthafbix.fsf@gnu.org> <87plry6sv3.fsf@localhost> <86le2lfjqv.fsf@gnu.org> <87jzi5ibbe.fsf@localhost> <864j99fg0a.fsf@gnu.org> <87msn18225.fsf@localhost> <86le2ldn2t.fsf@gnu.org> <87h6d97zzm.fsf@localhost> <86frstdlla.fsf@gnu.org> <87ed8d7yy3.fsf@localhost> <86bk3hdkv5.fsf@gnu.org> <87a5j17xpa.fsf@localhost> <877ce4992g.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3460"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , eller.helmut@gmail.com, pipcet@protonmail.com, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 02 06:34:26 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 1sOVDm-0000bm-K1 for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Jul 2024 06:34:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOVCz-0000Ov-Hx; Tue, 02 Jul 2024 00:33:37 -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 1sOVCx-0000Oi-Uy for emacs-devel@gnu.org; Tue, 02 Jul 2024 00:33:35 -0400 Original-Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sOVCw-0005uf-22; Tue, 02 Jul 2024 00:33:35 -0400 Original-Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-424adaa6ceeso23145255e9.1; Mon, 01 Jul 2024 21:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719894812; x=1720499612; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=GbqTkADR5bYFd4NdO5gq/dH+C74cchlWFtj6f1625PQ=; b=QNI9zTrzQ+VIsHh0haozSq1N+eJ/Ggi4ICM55l6FZLRwU7k2+a/cBQ7AuxreF9VPsh OcipDfjKaF5oOkMZLhb23zdF0SqZppliihQPBlfHrJsi5+iYJL1LFhiSoYCnyHZCJYGL Kv6ZOPFZLyRmAkWmz1XVl2GhA6Pt5ctFD00PzSaIs4upKkXHIaKAlXhsZG+AAdHV6z22 FClcgjp1BuoNbOPj9E4IRVnU3FlFSEsaa1U1h2jd8h1mVN8r9MAnyahdPkzzEbrMOiZD lFD19ljqVOmvbmcUVr+waGqzWIIcsn05mjmR9ORyNHc9cfnuUpsWZGo4ax/9T32O7rIa OR3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719894812; x=1720499612; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=GbqTkADR5bYFd4NdO5gq/dH+C74cchlWFtj6f1625PQ=; b=evQ21mK55DTDmhkeaZJm1SRxt5jVeUVCRvU07IQKUvPN32olJxy13GdSawZ7bntqfn OTJxuTSFmgQmLvEx12oV5UTXX/O9PQrj9jREr01Wge0pPsk8+V7yyvQKd4Q1a6HCGYN5 yaz/GDbCXNDW2oAeXaZltBDNyudQrkK0nsQZ5ditlFZBIMYxt+TbMORuDuTEO7WXOTu8 klhAl99C89qMp2xDtb2zmLPybhdJaGnjncylvGuUC6Hg8qVhiVAQwCtZVMjBGwN40lIN R4SfkhWYxk8phtcPx8RGorpUjTnnzPTC3QsNN2c7AeCbZxxdmPSJK347MAXhqz6jQG9a tpRQ== X-Forwarded-Encrypted: i=1; AJvYcCXxam9Mt/gTcIyUY85+z9W0a0dwr/AlwRSCmBh8tMe78D2ZX9uU2aY89lZWUB0O2uTavH99vid+3CH8oDY/glH4cog7 X-Gm-Message-State: AOJu0Yyg67j66Oi3fTUwzO5OLdNctAarnrAuM6Knl3ULKjAYuivVXTK8 Tk9la5u00+GP+QFoyvj/wrkeP0E/41U8kwxz/e68bXTFe8A+bzNKVIeQCg== X-Google-Smtp-Source: AGHT+IGGenmj5W4k4KBMhhKigopjQiVdTcosx6qh3ZNmC11/hIMN+INNC75tridG4fhyBut61u/hsg== X-Received: by 2002:a7b:cc96:0:b0:424:8ef1:816a with SMTP id 5b1f17b1804b1-4257a0257c1mr47923345e9.5.1719894811428; Mon, 01 Jul 2024 21:33:31 -0700 (PDT) Original-Received: from pro2.fritz.box (pd9e36129.dip0.t-ipconnect.de. [217.227.97.41]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4256b099c72sm178218465e9.37.2024.07.01.21.33.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jul 2024 21:33:30 -0700 (PDT) In-Reply-To: <877ce4992g.fsf@localhost> (Ihor Radchenko's message of "Mon, 01 Jul 2024 20:00:23 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::32e; envelope-from=gerd.moellmann@gmail.com; helo=mail-wm1-x32e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:321093 Archived-At: Ihor Radchenko writes: > Gerd M=C3=B6llmann writes: > >> Ihor Radchenko writes: >> >>> Note that our SIGCHLD signal handler itself does not re-enter malloc >>> (igc_malloc in our case). It just tries to access the memory arena that >>> is in transient state (in process of allocation). >> >> I think you are missing the read/write barriers that MPS puts on its >> memory. >> >> Consider a single object O. At some point in time, MPS copies O to a new >> address O', as part of the copying GC algorithm. In O it leaves a >> "tombstone" which tells where O' is now found. Then it puts a barrier on >> O, so that any access to O let's MPS fix the reference. (All via >> functions in igc.c. See dflt_fwd which creates the tombstone.) > > It is actually clear for me. > The problem is not with the barrier. The problem is that MPS' barrier > handler cannot work while the arena is locked to allocate a new > (completely unrelated) object. > > My reading of > https://memory-pool-system.readthedocs.io/en/latest/design/protix.html#th= reads > is that the MPS' barrier handler itself is re-entrant: The paragraph above what you cited is .threads.async: POSIX imposes some restrictions on signal handler functions (see design.mps.pthreadext.analysis.signal.safety). Basically the rules say the behaviour of almost all POSIX functions inside a signal handler is undefined, except for a handful of functions which are known to be =E2=80=9Casync-signal safe=E2=80=9D. However, if it=E2=80=99s= known that the signal didn=E2=80=99t happen inside a POSIX function, then it is safe to call ar= bitrary POSIX functions inside a handler. I read this as them being thinking about whether their SIGSEGV handler can use POSIX functions or not. > .threads.async.protection: If the signal handler is invoked because > of an MPS access, then we know the access must have been caused by > client code, because the client is not allowed to permit access to > protectable memory to arbitrary foreign code. In these > circumstances, it=E2=80=99s OK to call arbitrary POSIX functions insi= de the > handler. And the above I read as saying they can because the client is not allowed, and blahblah... > AFAIU, if memory barrier handler were not re-entrant, multi-threading > would simply not be possible. I don't understand how you come to that conclusion, sorry.