Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 26 Apr 2024 12:56:29 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > No, we should instead solve that.  Moving assertions out of the way
> > just sweeps real problems under the carpet, which makes little sense
> > to me.  These problems need to be solved, or else they will pile up
> > for no good reason.  It isn't like we are going to release this branch
> > soon, so avoiding these aborts has no useful purpose, IMO.
> 
> I've meanwhile pushed something that handles the use of PVEC_OTHER in
> modules. Nothing done for the scroll_bar struct in w32. Caution: I
> remved the assert.

Why did you do that?  What possible useful purpose can that serve?  If
the assertion gets in the way of what you are looking at, you can
always remove it locally, can't you?

> >> Sometimes it helps to put MPS into a post-mortem state, as MPS calls it.
> >> There is igc_postmorten which can be called from the debugger. That at
> >> least lifts the memory barriers.
> >> 
> >> Does that make sense?
> >
> > Yes, it does.  Maybe xbacktrace should do that automatically?  What
> > are the downsides of calling igc_postmorten?
> 
> I'd say that xpostmortem wouldn't make sense during normal debugging,
> when MPS is not dead in the water. I don't think one can get out of that
> state again.

I don't follow.  How is debugging problems with GC different from
"normal debugging"?

In any case, I asked about the downsides of calling igc_postmorten,
which I think is crucial to understand for making this decision.  If
there are no significant downsides, then doing so is a net win, no?