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: scratch/igc 90e80a9a53e 6/6: Adjust igc.c code to header changes Date: Sun, 21 Jul 2024 15:07:24 +0300 Message-ID: <861q3nc5j7.fsf@gnu.org> References: <8634o3c98h.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34744"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 21 14:08:22 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 1sVVMT-0008oo-R3 for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Jul 2024 14:08:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sVVLf-0004qV-11; Sun, 21 Jul 2024 08:07:31 -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 1sVVLb-0004q8-L7 for emacs-devel@gnu.org; Sun, 21 Jul 2024 08:07:28 -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 1sVVLa-0002Vg-T3; Sun, 21 Jul 2024 08:07:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=rUUD62jRkUdQZyhZO5mxG5T2SCC52UyzjzvHw+4PlFQ=; b=RfSSGOByLHJ+ BnYur56s+4ppmuyiQRmHw3iOblzQ/9qSijK9Th0eohxYjIlLdX58tmFHsgtiBPW0VBCf9d5q1kUwr lNUDXKklO6VQ/dgc3IP9+N9ZK6rTTSCKa3XEfGjNlYSBu8H5Bei4ZK6ioYcKuUfzJGdNrOT/Ny1uA QO5Fe7mze/mv7pmseImStNgmATWJB8sbWE9BYyYoafdDLjWEh2NnSmyWKNQ3m0WsW3PeCH8mwrBKE vG9z2VHfdmlp4yvGelUkIbBPmum/Wd3UnkBAbrWqKCzTLswZHaVz7Eyzhphfee3KZpov4vQXZRhfr DpKt8ym8pwAtlfC+enruOg==; In-Reply-To: (message from Pip Cet on Sun, 21 Jul 2024 11:42:41 +0000) 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:321870 Archived-At: > Date: Sun, 21 Jul 2024 11:42:41 +0000 > From: Pip Cet > Cc: emacs-devel@gnu.org > > > Error: error ("Memory exhausted--use M-x save-some-buffers then exit and restart Emacs") > > dump-emacs-portable("d:/gnu/git/emacs/feature/src/bootstrap-emacs.pdmp") > > > > The last commit that did build was 55670e0. > > Thanks for letting me know! It builds here on 32-bit and 64-bit GNU/Linux systems, so it's possible this is a Windows issue... Maybe, maybe not. I see nothing specific to Windows yet. > > The backtrace from the call to memory_full is below. The reason seems > > to be the recent changes in igc_dump_finish_obj: the result is that > > dump_igc_finish_obj wants to write a preposterously large amount of > > zeros into the dump: 744MB in the backtrace below, but I've seen much > > larger numbers there, like 1.2GB(!). This causes dump_grow_buffer > > requests 2GB from the OS, which rightfully fails. > > That all points to an object with a broken MPS header (or none). The question is what kind of object. > > > #8 dump_float (lfloat=, ctx=) at pdumper.c:2381 > > > > #9 dump_object (ctx=0x724eb38, ctx@entry=0x724eb3c, object=XIL(0xcbf005)) > > at pdumper.c:3306 > > This section puzzles me. If object is a vectorlike (the type bits of 0xcbf005 are 5, so it should be), it should be dumped as a vectorlike, not a float. Does the below help? #4 dump_write (ctx=0x71ceb38, buf=0x71ce848, nbyte=8) at pdumper.c:792 792 dump_write (struct dump_context *ctx, const void *buf, dump_off nbyte) (gdb) p ctx->igc_obj_dumped $1 = (void *) 0xc3f000 > (Also, ctx@entry shouldn't be different from ctx, should it?) I think this is just GDB trying (and failing) to understand the complexity of GCC's allocation of the place to hold the value: (gdb) fr 9 #9 dump_object (ctx=0x71ceb38, ctx@entry=0x71ceb3c, object=0xc3f005 ) at pdumper.c:3306 3306 offset = dump_float (ctx, XFLOAT (object)); (gdb) info address ctx Symbol "ctx" is multi-location: Range 0x6d2df0-0x6d2e14: a variable in $eax Range 0x6d2e14-0x6d2f84: a variable in $ebx Range 0x6d2f84-0x6d2f88: a complex DWARF expression: 0: DW_OP_GNU_entry_value 2: DW_OP_reg0 [$eax] 3: DW_OP_stack_value Range 0x6d2f88-0x6d2f8b: a variable in $eax Range 0x6d2f8b-0x6d300a: a variable in $ebx Range 0x6d300a-0x6d300e: a complex DWARF expression: 0: DW_OP_GNU_entry_value 2: DW_OP_reg0 [$eax] 3: DW_OP_stack_value Range 0x6d300e-0x6d3bb5: a variable in $ebx Range 0x8a1c70-0x8a1c75: a variable in $ebx >From poking inside igc_dump_finish_obj, the value returned by obj_size here: return base + obj_size (h); is preposterously large.