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: unable to build due to assertion violation in igc_dump_check_object_starts Date: Tue, 23 Jul 2024 16:10:42 +0200 Message-ID: References: <861q3k9sfb.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="35884"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Pip Cet , Helmut Eller , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 23 16:11:36 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 1sWGEp-00094F-D3 for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Jul 2024 16:11:35 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sWGE6-00007C-Ei; Tue, 23 Jul 2024 10:10:50 -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 1sWGE4-0008TG-Vl for emacs-devel@gnu.org; Tue, 23 Jul 2024 10:10:49 -0400 Original-Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sWGE3-0005pC-1N; Tue, 23 Jul 2024 10:10:48 -0400 Original-Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-5a15692b6f6so5103634a12.0; Tue, 23 Jul 2024 07:10:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721743845; x=1722348645; 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=NuqYCpANC0i6X/eGu1VdFcDJCHkW7dMI3ZqXK9RWT7k=; b=i49eWsiL4znA7TpiZO5KygSYgscTvOCH7K1guKGugs24qWZolX/OuzNpN6PdGNrbss CHpTgl0iAJ9VKgPuBD8vZ2SQGfMvpEoixI43ZbVFCoYC71cAvO0IT/+xfdgreEuZxYiz D6zUDW3UYdD/Z0rb7kR5jNqXR/yQhCH/mHFbEi0X6j07PHfKisCrX42LBZJY9PNCASY7 1YuLfE/wlnac0D6/jZ7TfxknVIdQB3ky3+SsP5gaBzMNaTDvQI5dxH03wbWd/7Zvd8Bm 9A8Q5tr3IOK0qNs6SqBtYRwQUTEFIVO6QOWXAifpL/Fn1SGgnrWudnhOd/O42tNc9Vls DzQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721743845; x=1722348645; 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=NuqYCpANC0i6X/eGu1VdFcDJCHkW7dMI3ZqXK9RWT7k=; b=YOasOTiwfXUyVNKgxBA1ERKaZWB5/G/RSqHV82mwI2KaVY/l9KhMOmxhGjgUP9jrXF RUpfwv4dkN7AA9Nrw7a6qH3en88mP6WNHAOAkEZLaHF26WKWc/cMHDWTqi+kA1fL0cKm MGgMw3ThbPXM4h2pX2jZqsNVPohoi6HEfVFXkHv4J0asbaUw873phkXiwi9HyTEIVgxy 8eybuEyxhHwqn9kyiLZMEQ4hHdgK0EmN65bvzFyIBN+q+Q2pHVfalEsSX7RLP7f/ih0E 7lsKwTNa7mG39xekSrV8S7CYPLvjX/yl0cM8OjiKGK/Ryzx9xsDfUxjWv96+qjvZ5mDy 1XlA== X-Forwarded-Encrypted: i=1; AJvYcCVHqcUDvBkByGTuP1x3sIWl01FtV8qxmugBimljpvpudyO5vKqLNck1O+eS9ICaWX88OGkUQzmDQr/Psiuy2a9E9nCv X-Gm-Message-State: AOJu0YxvYUhDUKxB48XvuvVFonOKmNoxKzSmGOYPfJEgZm2oW4YWwPIg VTW4tUXlRLls8SsB/uwf4A37H5+xtvr/H5o+MwGAiEb8C5Lqd1ttE71NCg== X-Google-Smtp-Source: AGHT+IEkIdpHsA/LSWf9yjdB266/63RBfZHMmmWkghSbmEATLBBTCLJuD/2Xlc7NBdgGmYCG/iLCvQ== X-Received: by 2002:a17:906:c10f:b0:a77:e1fb:7dec with SMTP id a640c23a62f3a-a7a87c7fb85mr229472666b.17.1721743844210; Tue, 23 Jul 2024 07:10:44 -0700 (PDT) Original-Received: from pro2.fritz.box (pd9e3603f.dip0.t-ipconnect.de. [217.227.96.63]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a7a4e68efdcsm450286666b.0.2024.07.23.07.10.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jul 2024 07:10:43 -0700 (PDT) In-Reply-To: <861q3k9sfb.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 23 Jul 2024 15:58:00 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::530; envelope-from=gerd.moellmann@gmail.com; helo=mail-ed1-x530.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:321989 Archived-At: Eli Zaretskii writes: > It looks like this: > > Finding pointers to doc strings... > Finding pointers to doc strings...done > Dumping under the name bootstrap-emacs.pdmp > Dumping fingerprint: fcd9b0097e8172ebf127ea1aea4dcd2e42d173dce96acd73db4b8b68ab5222e3 > cold user data: 7b4c68 > heap end: 7b8ee0 > > igc.c:4820: Emacs fatal error: assertion failed: end == p > > If I compile igc.c with -O0 (otherwise everything in > igc_dump_check_object_starts is "optimized-out"), I see this: > > Thread 1 hit Breakpoint 1, emacs_abort () at w32fns.c:11335 > 11335 { > (gdb) up > #1 0x00eb5540 in terminate_due_to_signal (sig=sig@entry=22, > backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:470 > 470 emacs_raise (sig); > (gdb) > #2 0x00f2a81a in die (msg=0x14f8051 "end == p", > file=0x14f79c8 "igc.c", line=4820) at alloc.c:8400 > 8400 terminate_due_to_signal (SIGABRT, INT_MAX); > (gdb) > #3 0x00fee189 in igc_dump_check_object_starts (relocs=0x11ce31a3, > dump_base=0x1ab94020, hot_start=0x1ab94098, hot_end=0x1b1a31e8, > cold_start=0x1b1c4020, heap_end=0x1b33ce88) at igc.c:4820 > 4820 eassert (end == p); > (gdb) l > 4815 EMACS_INT end_off = XFIXNUM (XCAR (XCDR (r))); > 4816 mps_addr_t start = (uint8_t *) dump_base + start_off; > 4817 mps_addr_t end = (uint8_t *) dump_base + end_off; > 4818 eassert (start == p); > 4819 p = dflt_skip (p); > 4820 eassert (end == p); > 4821 } > 4822 } > 4823 eassert (NILP (relocs)); > 4824 } > (gdb) p i > $1 = 1 > (gdb) p/x region > $2 = {start = 0x1b1c4020, end = 0x1b33ce88} > (gdb) p end > $3 = (mps_addr_t) 0x1b26ac80 > (gdb) p p > $4 = (mps_addr_t) 0x4af05d90 > (gdb) p start > $5 = (mps_addr_t) 0x1b26ac70 > (gdb) > > So it looks like dflt_skip(0x1b26ac70) yields some bogus value, but I > have no idea what it means or where to look to find the reason(s). This function checks the consistency of the pdump when it is written. It should be the case that the two regions of the dump (hot and cold) contain igc_headers that correspond to the relocs that the pdump contains. With i == 1 we are currently in the cold region. It should be the case that the igc_headers contained in the cold region are traversable in the same way as if the objects in the region had been allocated from MPS. That is, we start at the start of the regioni with the first objects, then dftl_skip from there we reach the second object, dflt_skip from there takes us to the third object and so on. In the failing case, dflt_skip from p does not take us to the next object, as far as the relocs say, So either the igc_header at p is somehow wrong or the reloc entry from relocs is wrong. Maybe one can see from the igc_header at p what object type was dumped there? There should be some 32-bit dependency somewhwere since I don't see that here on 64 bits.