Subject: bug#75632: 31.0.50; igc: Crash report

From: Eli Zaretskii <[email-masked]>
Date: Sat, 18 Jan 2025 14:25:03 +0200

> Date: Sat, 18 Jan 2025 11:42:44 +0000
> From: Pip Cet <[email-masked]>
> Cc: [email-masked], [email-masked]
> 
> >> But if we build without pdumper (after removing the relevant #error and
> >> a few minor fixes, it works just fine), initialized is false, so SIGUSR2
> >> wouldn't work at all in those builds.
> >
> > Do we want to support MPS in unexec builds?  I thought we didn't.
> > (Does it even work in such builds?)
> 
> I was talking about --with-dumping=none, not unexec builds.  I"m not
> fixing unexec bugs!

OK, so the only interesting use case is running temacs when not
dumping it.

> >> In the pdumper case, it'd run in temacs, put the right subr in the
> >> symbol's plist, dump it, and then it'd be restored from the dump and
> >> we'd only need the initial call.
> >>
> >> Would that be okay?
> >
> > I have no idea, because I don't understand why is that the solution to
> > SIGUSR handling.  (How about adding some comments which explain the
> > purpose of watching that variable?)  Also see above regarding unexec
> > build with MPS.
> 
> Vdebug_on_event points to data behind a memory barrier.  It's replaced
> by a C string which is xstrdup'd, so that's not behind a memory barrier.
> keeping the two in sync is done with a variable watcher, as is the case
> for gc-cons-threshold.
> 
> Variable watchers survive dump/reload cycles, so we set it up just once,
> when !initialized; when entering the code in the post-dump state, we
> perform the initial dummy "watch" event to initialize the C string.

OK, but what does this have to do with SIGUSR handling?