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: Sun, 30 Jun 2024 08:43:02 +0200 Message-ID: References: <87bk3jh8bt.fsf@localhost> <867ce7hvvz.fsf@gnu.org> <86tthbgdlr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14619"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: pipcet@protonmail.com, yantar92@posteo.net, emacs-devel@gnu.org, eller.helmut@gmail.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 30 08:43:40 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 1sNoHk-0003bG-4r for ged-emacs-devel@m.gmane-mx.org; Sun, 30 Jun 2024 08:43:40 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sNoHF-0004hk-O4; Sun, 30 Jun 2024 02:43:09 -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 1sNoHD-0004hM-E8 for emacs-devel@gnu.org; Sun, 30 Jun 2024 02:43:07 -0400 Original-Received: from mail-ej1-x632.google.com ([2a00:1450:4864:20::632]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sNoHB-000854-Qo; Sun, 30 Jun 2024 02:43:07 -0400 Original-Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-a729d9d7086so507819566b.0; Sat, 29 Jun 2024 23:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719729783; x=1720334583; darn=gnu.org; h=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=Ic6iDuVX9u9Lb7iOfFxvZbk1JnApkvzprUUNvyCxDJU=; b=EUAkIENEOHLB6pQdzAR1cl/9o77ILYmhm3YK+1rvz9Q+pWpOFSCsDezq6/u3ni5XM9 JbgQ2cj++LXxJ2eBB9VUnpV5aIm72rXB5K4z4K2RT9gZRPp+SUvbLl2KrW2fzgaA2Ibe nRXoa5tLrpAq+6UZ8XOa3lEOOsz8p2J4mkb5tXwSEp/610ij7WSUSuSZWb9nlAbhO9jW xZexe2J/usqO2gVVDMGW/ypGFi1r9HqCOEgHu6ZCeiEa56xx3SMSIbHVHe8ZKmVbl8lh csljLTFJ0/12PHbwaGuThiagmpeKtcQPUyb56cL4fAYzKJu93YroXryfWHUh7Od258F5 3Hjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719729783; x=1720334583; h=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=Ic6iDuVX9u9Lb7iOfFxvZbk1JnApkvzprUUNvyCxDJU=; b=qXkkkhROSsyDS9VZjaHPrOTnAI+CuWs//sMPfMotRD8uGtA4U1VtAU4bL/+guoWiEL x6Hk9Fe/tAcxh8yNN7LUQlaC1jSqfpLg2U3buG/JHnrDk6OCpYUxzDZqaKDdiE3hwaYq QPo1M5qn+vF0y80W2J/mG0w6ZmVepGMZ8CbRTV1ngSnsjf147f88qZyHvMFk6AoxjIuw rGNP6YFGJvg9JKVS5MemtV/dJtIaUxgvwrZfEWNzaUgvDxPgA+fI8bx4xFOdz2BDkeFv G0CuXCYhHQmhz/ag5iAQfO2pw6hndpy+UlFlpzAfs+eTdqbclERGdN4z/W2hedJyF8ON Lgpg== X-Forwarded-Encrypted: i=1; AJvYcCUqjZG/X5Rl4c7t0ZLIKYCk6SUIj20cSqZ2McbuDgy6cxQDfsgiu1AhSMToKYOaO3F4mWzoLRufppD3ekULzrzofyYw X-Gm-Message-State: AOJu0Ywpu7Adwj3MhMRaa7FwnEz/wl1Ifu9XzJ3rWC/0v2NQGZeLxDQ4 S0o9i8EKY9f0PDhuWguTa1nP1Ive1FQtvB58HeLbYEhzv7fqVFOG X-Google-Smtp-Source: AGHT+IGHnhsbMEtkXMSYthBV60ExarBN93rKZfaAPDf1Qmi8cXc12Mmgen4cs/nMS/AToVoI3Em3bA== X-Received: by 2002:a17:907:1c07:b0:a72:7ede:4d12 with SMTP id a640c23a62f3a-a751386ebebmr278723466b.5.1719729783411; Sat, 29 Jun 2024 23:43:03 -0700 (PDT) Original-Received: from pro2.fritz.box (pd9e36a45.dip0.t-ipconnect.de. [217.227.106.69]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a72ab0b8892sm220308266b.222.2024.06.29.23.43.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 29 Jun 2024 23:43:03 -0700 (PDT) In-Reply-To: <86tthbgdlr.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 30 Jun 2024 09:16:00 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::632; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x632.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:320919 Archived-At: Eli Zaretskii writes: > Why "yuck"? That's a valid solution, IMO, especially if there are no > better ones. I'm talking about blocking only a small number of > signals: SIGCHLD, SIGPROF, SIGALRM, and maybe also SIGIO and SIGINT. > (We should also consider SIGUSR1 and SIGUSR2.) I find that really ugly. Of course, should there be no other solution on some platforms, we can try that. It's not needed for macOS, for example. >> > Are there any guidance in the MPS docs for handling such signals in >> > these situations? If not, can we ask them for guidance? It is >> > unrealistic to expect any real-life program to do nothing in signal >> > handlers except setting flags. And even flags could be subject to MPS >> > moving GC, at least in some cases. So there must be some way of >> > dealing with that in a safe way. >> >> It's Emacs' fault. MPS cannot reasonably be expected to assume that a >> client program uses MPS managed memory in a signal handler. My 2 cents. > > That's unreasonable, IMNSHO. Programs manage memory for various > purposes, and nothing in principle should prevent a program from > accessing MPS-managed memory from a signal handler. I disagree. > Are you saying that a program that manages _all_ of its heap-allocated > memory via MPS cannot also handle signals in a safe way? The program can do both, but only if the signal handler behaves. There is not much a signal handler is allowed to do. Portably it can do almost nothing. But even non-portably, it's never safe to call non-reentrant code. On Linux, there is a list of async-signal-safe functions one can call in a signal handler, others cannot be used. I don't expect MPS to be async-signal-safe. I find that unreasonble. Why would it be? Emacs's isn't either. Almost nothing is. >> >> And maybe how to reproduce? >> > >> > Run for enough time with subprocesses that start and terminate, I >> > guess? >> >> Just remembered that I won't be able to reproduce this anyway an macOS, >> where barriers don't use signals. > > AFAIU, this scenario is not necessarily related to barrier-related > signals. SIGCHLD caused us to access MPS-managed memory, which > violated some assertion in MPS, because the arena lock was already > taken. I would have to see an example where no barrier is involved. It is in this case. MPS is doing work, therefore holds the lock, receives SIGxy which it let's the client handle. The client hits a barrier, which invokes MPS's signal handler, which tries to acquire the lock which is already taken.