From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii 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 17:26:29 +0300 Message-ID: <86zfq889re.fsf@gnu.org> References: <861q3k9sfb.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21927"; mail-complaints-to="usenet@ciao.gmane.io" Cc: pipcet@protonmail.com, eller.helmut@gmail.com, emacs-devel@gnu.org To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 23 16:27:37 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 1sWGUL-0005UQ-2G for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Jul 2024 16:27:37 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sWGTT-0003bo-HS; Tue, 23 Jul 2024 10:26:43 -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 1sWGTJ-0002wM-2H for emacs-devel@gnu.org; Tue, 23 Jul 2024 10:26:33 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sWGTI-000131-PK; Tue, 23 Jul 2024 10:26:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=2JLzTLJiHIwbBy472j0zi7VihXRvJ9wqdMnkm5+00TY=; b=BKkijFU3trLdapXnbmpP 8DLwAs2KbqjqEolf12aYMDzjy7ENl9we3zMQM6K0Lfvek0n3Ar46iHH2wXfrBV38VAkQpwUyw1dcT Fu/deOciBxV6x4L1cEnMUViQD5SWT+CvqmfIa0gC9ny7e2gYkkPFD3JGVDe3xZ80lhCwRnWvOorU5 fKfIiBlztfCZAo1ecOuutQrhXEzKa5T03XAxuWGetdyiyi3sgPwwl+wHakh9GZTjf/Y5Y3KspVbQW K5agt2INrajRutNpMI6BqkplEJjfvTKaMeYtdL5ym2HEGyxWlq/KFHyHo0Gn6juavZ43g3N9Swr78 yi7DvRtJ82R45g==; In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Tue, 23 Jul 2024 16:10:42 +0200) 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:321990 Archived-At: > From: Gerd Möllmann > Cc: Pip Cet , Helmut Eller , > emacs-devel@gnu.org > Date: Tue, 23 Jul 2024 16:10:42 +0200 > > Eli Zaretskii writes: > > > 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. I don't really understand what I'm doing, but does the below help? 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=0x11d32853, dump_base=0x1aa41020, hot_start=0x1aa41098, hot_end=0x1b055c70, cold_start=0x1b081020, heap_end=0x1b1f9e98) at igc.c:4820 4820 eassert (end == p); (gdb) p obj_size(start) $1 = 801749580 (gdb) p igc_header_nwords(start) $2 = 200437395 (gdb) p header_tag(start) $3 = 0 (gdb) p header_nwords(start) $4 = 200437395 (gdb) p *(struct igc_header *)start $5 = {v = 1721744118644157000} (gdb) p/x *(struct igc_header *)start $6 = {v = 0x17e4dd2759e72a48} (gdb) p relocs $7 = (Lisp_Object) 0x11d32853 (gdb) source .gdbinit SIGINT is used by the debugger. Are you sure you want to change it? (y or n) [answered Y; input not from terminal] Environment variable "DISPLAY" not defined. Environment variable "TERM" not defined. Breakpoint 2 at 0xeb54e0: file emacs.c, line 432. (gdb) p relocs $8 = XIL(0x11d32853) (gdb) xtype Lisp_Cons (gdb) xcar $9 = 0x11a5eda3 (gdb) xtype Lisp_Cons (gdb) xcar $10 = 0x1b9b062 (gdb) xtype Lisp_Int0 (gdb) xint $11 = 7236632 (gdb) p r $12 = XIL(0x11a5ed33) (gdb) xtype Lisp_Cons (gdb) xcar $13 = 0x1b9b022 (gdb) xtype Lisp_Int0 (gdb) xint $14 = 7236616 (gdb) pp r (7236616 7236632) So relocs seem to be pairs of numbers, and 'r', the one that seems to cause the problem, looks okay to me. But is the igc_header okay? Let me know if I can collect more data.