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 21:00:04 +0300 Message-ID: <86ikww7zvf.fsf@gnu.org> References: <861q3k9sfb.fsf@gnu.org> <86zfq889re.fsf@gnu.org> <86y15s893y.fsf@gnu.org> <86ttgg867k.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="25384"; 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 20:00: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 1sWJoo-0006M5-MO for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Jul 2024 20:00:58 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sWJo2-0007U0-Vp; Tue, 23 Jul 2024 14:00:11 -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 1sWJo1-0007Tq-CB for emacs-devel@gnu.org; Tue, 23 Jul 2024 14:00:09 -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 1sWJo1-000825-2G; Tue, 23 Jul 2024 14:00:09 -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=hHbXptKij6VXYxpDVTCoZTYzJTbg78K6/B0WfG83tIY=; b=lS8R9nJ4am+f24HU+gLC 6Y4yvJDLMiLdPnWLiuZehBHEl26Av+cjxcglnU4MOmYU25ba4qCSgDAUVXAofKF5HB/XOeI8OuEZM hNAKw+Cf+vzrGD7wc0Q+2jnt0kTYkiwbLdgKLxR9m1Beo4jF/OOaITxKW2IOJ/Vu4lCMjc9BSPrmW 7edCkSvI9ttNetPdJBQqVmJlO+1tFMfl4wIVg4q6Irj6yDOvGxECKiFsc3cZ/JbCVLvBpc613uZrG ndDNNQNQW4mgw675CT0eei697t+tR4DrglF55Ax+EJGuHlC/192JhzpojyRM9G624/BaubSv19Ym5 hmVu5uXX2SLVEw==; In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Tue, 23 Jul 2024 18:29:56 +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:322005 Archived-At: > From: Gerd Möllmann > Cc: pipcet@protonmail.com, eller.helmut@gmail.com, emacs-devel@gnu.org > Date: Tue, 23 Jul 2024 18:29:56 +0200 > > But we can try to use the value of start_off at the time the assertion > is triggered. The list containing the start/end offsets should be > created here: > > static void > dump_igc_finish_obj (struct dump_context *ctx) > { > if (ctx->flags.dump_object_contents) > { > char *base = (char *) ctx->buf + ctx->igc_base_offset; > char *end = (char *) ctx->buf + ctx->offset; > eassert (end > base); > char *should_end = igc_dump_finish_obj (ctx->igc_obj_dumped, ctx->igc_type, base, end); > eassert (should_end >= end); > dump_write_zero (ctx, should_end - end); > if (ctx->flags.record_object_starts) > dump_push (&ctx->igc_object_starts, > list2 (dump_off_to_lisp (ctx->igc_base_offset), > dump_off_to_lisp (ctx->offset))); > Here ^^^^^^ > > } > > ctx->igc_obj_dumped = NULL; > ctx->igc_type = IGC_OBJ_INVALID; > ctx->igc_base_offset = -1; > } > # endif // HAVE_MPS > > If I'm not completely mistaken, start_off when asserting should == > ctx->igc_base_offset at some point whle dumping. Could you perhaps put a > conditional breakpoint there? That was not a good idea: I waited for an hour, but the breakpoint didn't break and temacs didn't finish. I guess we severely underestimate how many objects pdumper dumps, and thus how many times this breakpoint triggers and GDB needs to examine the values. So instead I added a source-level condition: if (ctx->igc_base_offset == THAT_SPECIFIC_VALUE) emacs_abort (); and ran with a breakpoint in emacs_abort. That did the trick. > We could then go up the stack and see which dump_xy function that > is. Here, let me know what more you want to see: Thread 1 hit Breakpoint 1, emacs_abort () at w32fns.c:11335 11335 { (gdb) up #1 0x00c9febf in dump_igc_finish_obj (ctx=0x777eb38, ctx@entry=0x777eb3c) at pdumper.c:935 935 emacs_abort (); (gdb) bt #0 emacs_abort () at w32fns.c:11335 #1 0x00c9febf in dump_igc_finish_obj (ctx=0x777eb38, ctx@entry=0x777eb3c) at pdumper.c:935 #2 0x00ca5a3f in dump_cold_string (string=, ctx=0x777eb3c) at pdumper.c:3560 #3 dump_drain_cold_data (ctx=0x777eb3c) at pdumper.c:3714 #4 Fdump_emacs_portable (filename=, track_referrers=) at pdumper.c:4514 #5 0x00ccae36 in eval_sub (form=0xbb2ac73) at eval.c:2630 #6 0x00ccac41 in eval_sub (form=0xbb2abb3) at eval.c:2578 #7 0x00ccafc3 in Fprogn (body=0xbb2ae6b) at eval.c:452 #8 0x00ccc068 in Flet (args=) at lisp.h:1546 #9 0x00ccac41 in eval_sub (form=0xbb2aacb) at eval.c:2578 #10 0x00ccc916 in Funwind_protect (args=0xbb2ae7b) at lisp.h:1546 #11 0x00ccac41 in eval_sub (form=0xbb2aabb) at eval.c:2578 #12 0x00ccafc3 in Fprogn (body=0x0) at eval.c:452 #13 0x00ccc068 in Flet (args=) at lisp.h:1546 #14 0x00ccac41 in eval_sub (form=0xbb2aa8b) at eval.c:2578 #15 0x00ccafc3 in Fprogn (body=0xbb2b93b) at eval.c:452 #16 0x00ccc068 in Flet (args=) at lisp.h:1546 #17 0x00ccac41 in eval_sub (form=0xbb2a52b) at eval.c:2578 #18 0x00ccac41 in eval_sub (form=0xbb2a50b) at eval.c:2578 #19 0x00ccafc3 in Fprogn (body=0x0) at eval.c:452 #20 0x00ccac41 in eval_sub (form=form@entry=0xbb29ff3) at eval.c:2578 #21 0x00d06f34 in readevalloop (readcharfun=readcharfun@entry=0x60c0, infile0=infile0@entry=0x777f638, sourcename=sourcename@entry=0xa848184, printflag=printflag@entry=false, unibyte=unibyte@entry=0x0, readfun=readfun@entry=0x0, start=start@entry=0x0, end=, end@entry=0x0) at lread.c:2537 #22 0x00d0798b in Fload (file=, noerror=0x0, nomessage=0x0, nosuffix=0x0, must_suffix=) at lisp.h:1214 #23 0x00ccadd3 in eval_sub (form=form@entry=0xa847e4b) at eval.c:2641 #24 0x00cccf0d in Feval (form=0xa847e4b, lexical=lexical@entry=0x20) at eval.c:2486 #25 0x00c25d51 in top_level_2 () at lisp.h:1214 #26 0x00cc528c in internal_condition_case ( bfun=bfun@entry=0xc25cf3 , handlers=handlers@entry=0x60, hfun=hfun@entry=0xc2f806 ) at eval.c:1633 #27 0x00c26460 in top_level_1 (ignore=0x0) at lisp.h:1214 #28 0x00cc51a6 in internal_catch (tag=tag@entry=0xc520, func=func@entry=0xc26437 , arg=arg@entry=0x0) at eval.c:1312 #29 0x00c25b0f in command_loop () at lisp.h:1214 #30 0x00c2f3c4 in recursive_edit_1 () at keyboard.c:765 #31 0x00c2f6b2 in Frecursive_edit () at keyboard.c:848 #32 0x00e75745 in main (argc=, argv=) at emacs.c:2646 (gdb) up #2 0x00ca5a3f in dump_cold_string (string=, ctx=0x777eb3c) at pdumper.c:3560 3560 dump_igc_finish_obj (ctx); (gdb) p data $1 = (struct Lisp_String_Data *) 0xb52b200 (gdb) p *$ $2 = {gc_header = {v = 245077557021}, data = 0xb52b208 "ÅÆ!\210Ç\030\t.\017"} (gdb) p/x *$1 $3 = {gc_header = {v = 0x390fc2bf1d}, data = 0xb52b208} (gdb)