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: hash tables / obarrays Date: Mon, 20 May 2024 08:13:47 +0200 Message-ID: References: <87a5kmqgeo.fsf@gmail.com> <875xvaqel1.fsf@gmail.com> <871q5xr12q.fsf@gmail.com> 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="6905"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , Emacs Devel To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 20 08:15:59 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 1s8wJT-0001aW-AH for ged-emacs-devel@m.gmane-mx.org; Mon, 20 May 2024 08:15:59 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s8wIl-0002H8-LH; Mon, 20 May 2024 02:15:15 -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 1s8wHV-0001FD-Cu for emacs-devel@gnu.org; Mon, 20 May 2024 02:13:57 -0400 Original-Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s8wHQ-00027j-F4; Mon, 20 May 2024 02:13:56 -0400 Original-Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-51ffff16400so6225484e87.2; Sun, 19 May 2024 23:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716185629; x=1716790429; 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=eNDSaZnISUWXWs/AN8bWCHUPuF6zV6rfwoQuziqdXqM=; b=G0xPDP2U3E8D/0Wq3DoovWB3Qs6ktSnWv3NzsDAoNl/8xHgu/ZV/oaWscWScqC5wL4 gf/bKbvB6q0uaCrFuKX4SsoRhP3gV4iP/J3wq1a4nPX8Jh3ofvWgfSe3W2b2EYeOcqd4 1Osozn4ZTwaR16+G4YVksL/EfIipZem3rYHjGGJCHYhCtiOV0eiUT5xbAEjnPMATVNUr IJDdY/lQ/4YLQxFn+B5UMvBTZVF0QLU5hivMtotohmix5bIP+/Y3g55bt5N/EMK8oBNE 4HJOTW3fIFMu5MX+pSUAHc+DKeY3B/67AYikiQv6Y51dEE3ae+dsHxODkTDFnF8PfIJ1 0cRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716185629; x=1716790429; 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=eNDSaZnISUWXWs/AN8bWCHUPuF6zV6rfwoQuziqdXqM=; b=wYipc5X1UqY/rOVjXDbuMU0MitYQaRjod/g+R/WDat1HyiolzfmOt7W/twwQuvE0vU GsgilmbVurVrqZs8gC8j6HpJfqcCjw45YB+fY4APDS6qacbyku5A3w+CkancKVcUYVSL gcYHZbztidK3BOEf3OrIObIu44ZsweB1EDmNRLTmtN2VIYDBWYzIFdPlN0McNTMlldrn i94b9/r9XpqOi2TAoW/qEaPwxzrRAOGRDSPSHscbO8f3Gb0sXxbdWQ3ZQZH57ifxvTlB hJg08hYx3VD7Flx44ITgG6Gco4sl0CcUnOwFtYvc7ZhO37J5fDtZb1twFdGFzQjLcTob V74Q== X-Forwarded-Encrypted: i=1; AJvYcCXa+LxrK3hrCQ+sRKhDKc1+8YFiprAM2P6x0coqPXOPKe5NBLBQc2SfD/2jG79GWE++TDlufhamvQATLYPHbR75twPd X-Gm-Message-State: AOJu0YywQ90yK+YIiEaoVKf2CwUqMCqErO12jW40/K3WjzuhXOefaurK ZiKigMpl0G+8lfLF7CfCoB6BTsQLYwN1St+gFMZAscv2bu9Ngbk2jXKUJQ== X-Google-Smtp-Source: AGHT+IGz4JmPZlmdeU3vz9udnHRz8PnjfimAHWlzsLfiLa1T/tbTfFoS47BSCROr8YZRUV64uISTTw== X-Received: by 2002:a05:6512:61:b0:51c:5570:f570 with SMTP id 2adb3069b0e04-52210473d4fmr21066165e87.59.1716185628980; Sun, 19 May 2024 23:13:48 -0700 (PDT) Original-Received: from pro2.fritz.box (pd9e36556.dip0.t-ipconnect.de. [217.227.101.86]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a5ce59ecbc0sm524429166b.200.2024.05.19.23.13.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 May 2024 23:13:48 -0700 (PDT) In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Mon, 20 May 2024 06:27:10 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::131; envelope-from=gerd.moellmann@gmail.com; helo=mail-lf1-x131.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:319390 Archived-At: Gerd M=C3=B6llmann writes: > Helmut Eller writes: > >>> I'd say a reference we didn't scan :-(. >>> >>> The is_mps with a Lisp_Object doesn't work with symbols, BTW, because >>> the Lisp_Object doesn't contain a pointer, but an offset from lispsym. >> >> The function that tries to print is comp--final and the argument is the >> expr. When I call safe_debug_print on that it goes on for many pages >> and ends with this: >> >> #2314# 635 #2194# 636 #2181# 637 #2022# 638 #1949# 639 #1891# 640 #16= 40#)) #s(comp-data-container nil #s(hash-table test >> igc.c:343: Emacs fatal error: assertion failed: h->obj_type !=3D IGC_O= BJ_FWD >> >> Breakpoint 1, terminate_due_to_signal (sig=3D6, backtrace_limit=3D2147= 483647) >> at emacs.c:443 >> 443 signal (sig, SIG_DFL); >> The program being debugged stopped while in a function called from GDB. >> Evaluation of the expression containing the function >> (safe_debug_print) will be abandoned. >> When the function is done executing, GDB will silently stop. >> (gdb) >> >> So it could have something to do with hash tables after all. > > Could be, of course. > > Maybe you could try the following: In igc_check_fwd, where we find the > header has IGC_OBJ_FWD, > > void > igc_check_fwd (void *client) > { > if (is_mps (client)) > { > struct igc_header *h =3D client_to_base (client); > igc_assert (h->obj_type !=3D IGC_OBJ_FWD); > } > } > > struct igc_fwd > { > struct igc_header header; > mps_addr_t new_base_addr; > }; > > When h->obj_type =3D=3D IGC_OBJ_FWD, then the header is actually an igc_f= wd, > and the new_base_addr points to where the object was forwarded to. > dflt_fwd does that. Some phantasy debug commands woould look like > > (lldb) p *(struct igc_fwd *) h > =3D> ...new_base_addr =3D 0x1234 > > (lldb) p *(struct igc_header *) 0x1234 > (lldb) p base_to_client ((void *) 0x1234) > > We could then perhaps, not always, see what the real object looks like. > For example, if it is a symbol, its name etc. Maybe that gives us a > clue. Probably unrelated, but since we're talking native-comp... I've just removed the special handling of comp units in the dump. This should be unnecessary now that we traverse the dump, and it's actually against the MPS rule that roots may not overlap...