all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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)



  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.