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: Building the igc branch on MS-Windows Date: Sat, 27 Apr 2024 14:32:18 +0200 Message-ID: References: <86il063imh.fsf@gnu.org> <87y191fwnd.fsf@gmail.com> <87cyqcfv6k.fsf@gmail.com> <86o79wzi31.fsf@gnu.org> <86mspgza23.fsf@gnu.org> <867cgkz7e2.fsf@gnu.org> <87r0esdv7o.fsf@gmail.com> <87le50dmec.fsf@gmail.com> <8734r7etu1.fsf@gmail.com> <86il03xrlz.fsf@gnu.org> <868r0zxpfr.fsf@gnu.org> <861q6rxnst.fsf@gnu.org> <86wmojuj0m.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="9237"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: eller.helmut@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 27 14:33:01 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 1s0hEi-000284-SE for ged-emacs-devel@m.gmane-mx.org; Sat, 27 Apr 2024 14:33:00 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s0hEA-0002Wy-3s; Sat, 27 Apr 2024 08:32:26 -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 1s0hE8-0002Wp-NM for emacs-devel@gnu.org; Sat, 27 Apr 2024 08:32:24 -0400 Original-Received: from mail-ed1-x531.google.com ([2a00:1450:4864:20::531]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s0hE7-0007cf-0V; Sat, 27 Apr 2024 08:32:24 -0400 Original-Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-572669fd9f9so1107835a12.0; Sat, 27 Apr 2024 05:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714221141; x=1714825941; 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=hBor0jNCVOPHFGpuAslcOG9OeqizJDHfCCc3hZ4yq1Q=; b=Xwi+DNEd59Gq+uRbob7fp9DyldpxgxjRkPikNfT+qQ3ejoNM1CRt9Z5NX4JCtUTkhS DqlQS9Gu0Ez4Yy1JPtCOEzRA8AYt8fn7gPzsK3GfpNURQBAYopSizqIYZVEsoD02GMWB Ym7eyG55WuPJtkcMkImD4YRKxI/va+QzrraLiHcS0YRo0YOOGjdtW81PDCyAk3qTxvfY VdSKktO3DW4lPnpZFzjnJqTtA0e42leszcZR92yuvJTg4Zasg5iaUH4CWWzV1EMzpOlB +d4X9Jgp5plNlNcfGpjHSEBFM0jZpOEnydEF9xxAU6Q+CGsgriJtxxdTc3LHvR/G2Xji wgyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714221141; x=1714825941; 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=hBor0jNCVOPHFGpuAslcOG9OeqizJDHfCCc3hZ4yq1Q=; b=uucGTu0eWIx5PFjmnWuFbRPLuAoOYfucxBAlsNz0ikItL+6pUbx1XMcvni0r7u5NfF 7xAaPI+AdY9p4jCX7oLa6uYdJ0HCT9pyTjWXVo2ZdzHf/p1fTTrKXfYlLF2B3sTi1xnc yi8JyiGG4WbrV4FG1G0vN/coIWDrRSQ65i+O4jmfis+j44fUmnKro2sKSahKgrLP1xgU uBY6JCZ0CRxiXrLTHtAWRN2MluJ3nCj9WaTePS02oLDBiO2Awzw0pPN9ZWST8kEany9w io9ts42QHb3gXcoPGiyvG9dSETDiVIi8mE2rhKyGSBATgIPIV/Lr1bIvAq2kWsVCOJ2g sxfA== X-Forwarded-Encrypted: i=1; AJvYcCU/ul99BIf0y+5aIS2zNTkOWDrUjHItITx+1lNOxGN7p8h7l0W6qMt/ztqr2GbOtLjRB9JkIxjBvjyZLp3NZJxzjxhn X-Gm-Message-State: AOJu0Ywpq4SijR4HHuMH7N0ewqm8gj83Vcw1kjec9aoTaF+REKiWxGW7 OTFJ89RJWRfHwUHow9TH1cgxTbwNmazWcj2kHG47AFZ3ZUt2Ev3LngJAlw== X-Google-Smtp-Source: AGHT+IGR8z7DQ/331+UTtONT2RoAFmtkoOzoxsuO+aBEq1QD0BeyE4LI/G6AQma0YVEdlPCIlo035Q== X-Received: by 2002:a17:907:76a4:b0:a58:94c1:88c9 with SMTP id jw4-20020a17090776a400b00a5894c188c9mr3843045ejc.54.1714221140543; Sat, 27 Apr 2024 05:32:20 -0700 (PDT) Original-Received: from pro2.fritz.box (p4fe3ae42.dip0.t-ipconnect.de. [79.227.174.66]) by smtp.gmail.com with ESMTPSA id fx9-20020a170906b74900b00a58e98f5642sm501721ejb.38.2024.04.27.05.32.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 27 Apr 2024 05:32:20 -0700 (PDT) In-Reply-To: <86wmojuj0m.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 27 Apr 2024 14:44:57 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::531; envelope-from=gerd.moellmann@gmail.com; helo=mail-ed1-x531.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:318195 Archived-At: Eli Zaretskii writes: >> > void *extra; >> >> What that is I have no idea. > > See xftfont.c, which seems to be the only one using this. Doesn't look like a reference to Lisp data to me, so I'd say we can ignore it. Usual disclaimers. > I added both ascii_font and extra to fix_face, but the segfault is > still there. What else can be done to dig into this crash? Hm, I see nothing immediately obvious to do except collecting more info where the font comes from. >> While our scanning callbacks run, MPS guarantees us exclusive access to >> only those objects in the address range MPS calls us for. All other >> objects are (potentially) behind read/write barriers. So we can't change >> something in object A while scanning a different object B. > > I don't understand what you are saying here, because there are too > many unknowns: what are "our scanning callbacks"? what do you mean by > "exclusive access"? what is "the address range MPS calls us for"? Ok, sorry. Our scanning callbacks = functions we register with MPS: dflt_scan, the various root scanning functions, like scan_staticvec ... Exclusive access = other threads can't interfere Address range MPS calls us for = the start and end address of the area to scan are passed to dflt_scan, for example. > what does "behind read/write barriers" mean in practice? and could you > show a simple example of "can't change something in object A while > scanning a different object B" -- what are object A and object B here? The barries mean that we might get a SIGBUS or SIGSEGV when trying to access something (read or write) outside of the scanned area (see above). I can't show an example, but maybe this help: Image we are scanning a cons cell. We can then trace car and cdr as references, but we can't follow the car and cdr to where tehy point. Let's say cdr is another cons, then that cons is taboo. >> This does not hold for objects that are not managed by MPS. If B has a >> pointer to malloc'd memory M, we can do with M what we want, but MPS >> also doesn't protect M from other threads. We're on our own. > > What "other threads"? At the moment it's either the main thread or one of the threads created with make-thread I think it is. Even if only one of these runs at a time. The scanning is done concurrently in the MPS thread.