From: Eli Zaretskii <eliz@gnu.org>
To: "Gerd Möllmann" <gerd.moellmann@gmail.com>
Cc: pipcet@protonmail.com, eller.helmut@gmail.com, emacs-devel@gnu.org
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 [thread overview]
Message-ID: <86ikww7zvf.fsf@gnu.org> (raw)
In-Reply-To: <m2o76ooyuz.fsf@pro2.fritz.box> (message from Gerd Möllmann on Tue, 23 Jul 2024 18:29:56 +0200)
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> 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=<optimized out>, ctx=0x777eb3c)
at pdumper.c:3560
#3 dump_drain_cold_data (ctx=0x777eb3c) at pdumper.c:3714
#4 Fdump_emacs_portable (filename=<optimized out>,
track_referrers=<optimized out>) 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=<optimized out>) 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=<optimized out>) 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=<optimized out>) 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=<optimized out>,
end@entry=0x0) at lread.c:2537
#22 0x00d0798b in Fload (file=<optimized out>, noerror=0x0, nomessage=0x0,
nosuffix=0x0, must_suffix=<optimized out>) 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 <top_level_2>, handlers=handlers@entry=0x60,
hfun=hfun@entry=0xc2f806 <cmd_error>) 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 <top_level_1>, 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=<optimized out>, argv=<optimized out>)
at emacs.c:2646
(gdb) up
#2 0x00ca5a3f in dump_cold_string (string=<optimized out>, 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)
next prev parent reply other threads:[~2024-07-23 18:00 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-23 12:58 MPS: unable to build due to assertion violation in igc_dump_check_object_starts Eli Zaretskii
2024-07-23 14:10 ` Gerd Möllmann
2024-07-23 14:26 ` Eli Zaretskii
2024-07-23 14:40 ` Eli Zaretskii
2024-07-23 14:52 ` Gerd Möllmann
2024-07-23 15:43 ` Eli Zaretskii
2024-07-23 16:29 ` Gerd Möllmann
2024-07-23 18:00 ` Eli Zaretskii [this message]
2024-07-23 18:37 ` Eli Zaretskii
2024-07-23 18:40 ` Pip Cet
2024-07-23 18:48 ` Gerd Möllmann
2024-07-23 19:12 ` Pip Cet
2024-07-23 19:25 ` Gerd Möllmann
2024-07-23 19:30 ` Gerd Möllmann
2024-07-23 22:47 ` Pip Cet
2024-07-24 3:50 ` Gerd Möllmann
2024-07-24 11:27 ` Eli Zaretskii
2024-07-24 8:01 ` Helmut Eller
2024-07-24 8:21 ` Pip Cet
2024-07-24 8:33 ` Helmut Eller
2024-07-24 9:20 ` Pip Cet
2024-07-24 9:39 ` Helmut Eller
2024-07-24 9:54 ` Pip Cet
2024-07-24 11:40 ` Helmut Eller
2024-07-24 12:25 ` Pip Cet
2024-07-24 11:44 ` Eli Zaretskii
2024-07-23 18:50 ` Gerd Möllmann
2024-07-23 18:42 ` Gerd Möllmann
2024-07-23 18:49 ` Eli Zaretskii
2024-07-23 18:59 ` Gerd Möllmann
2024-07-23 14:42 ` Pip Cet
2024-07-23 16:28 ` Pip Cet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86ikww7zvf.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=eller.helmut@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=gerd.moellmann@gmail.com \
--cc=pipcet@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.