From: Eli Zaretskii <eliz@gnu.org>
To: gerd.moellmann@gmail.com, pipcet@protonmail.com
Cc: 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:37:22 +0300 [thread overview]
Message-ID: <86h6cg7y59.fsf@gnu.org> (raw)
In-Reply-To: <86ikww7zvf.fsf@gnu.org> (message from Eli Zaretskii on Tue, 23 Jul 2024 21:00:04 +0300)
> Date: Tue, 23 Jul 2024 21:00:04 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: pipcet@protonmail.com, eller.helmut@gmail.com, emacs-devel@gnu.org
>
> #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)
And:
(gdb) fr 1
#1 0x00c9febf in dump_igc_finish_obj (ctx=0x777eb38, ctx@entry=0x777eb3c)
at pdumper.c:935
935 emacs_abort ();
(gdb) p ctx->igc_type
$5 = IGC_OBJ_STRING_DATA
(gdb) p should_end
$6 = <optimized out>
(gdb) p ctx->igc_obj_dumped
$7 = (void *) 0xb52b200
(gdb) p igc_header_type(ctx->igc_obj_dumped)
$8 = IGC_OBJ_STRING_DATA
(gdb) p obj_size(ctx->igc_obj_dumped)
$9 = 112
So this is IGC_OBJ_STRING_DATA, but why doesn't igc_dump_finish_obj do
its job in this case? What are we missing?
next prev parent reply other threads:[~2024-07-23 18:37 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
2024-07-23 18:37 ` Eli Zaretskii [this message]
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=86h6cg7y59.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.