GNU bug report logs - #75632
31.0.50; igc: Crash report

Previous Next

Full log

Message #82 received at 75632 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: yantar92 <at> posteo.net, 75632 <at> debbugs.gnu.org
Subject: Re: bug#75632: 31.0.50; igc: Crash report
Date: Wed, 22 Jan 2025 17:04:17 +0200

> Date: Wed, 22 Jan 2025 12:30:45 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: 75632 <at> debbugs.gnu.org, yantar92 <at> posteo.net
> 
> "Eli Zaretskii" <eliz <at> gnu.org> writes:
> 
> >> Date: Sun, 19 Jan 2025 13:37:18 +0000
> >> From: Pip Cet <pipcet <at> protonmail.com>
> >> Cc: 75632 <at> debbugs.gnu.org, yantar92 <at> posteo.net
> >>
> >> "Eli Zaretskii" <eliz <at> gnu.org> writes:
> >>
> >> > and at temacs time?
> >>
> >> I don't think it's a realistic scenario that someone needs to debug
> >> non-interactive temacs, cannot use the default signal, and wants to
> >> change it.
> >
> > I meant the interactive temacs, which begins by loading all the
> > preloaded packages.  So one of those could add the watcher.
> 
> Do we really need this to be added early?

Only if we care about sending SIGUSR2 before bindings.el is loaded.

I guess we can leave it in bindings.el, and wait for someone to
complain that it doesn't work earlier.

> > One of the first files we load in loadup, I think?  Like subr.el,
> > perhaps?
> 
> See above.  I think if you need to put an --eval '(debug--on-event
> (quote sigusr1))' in your temacs invocation, you're likely knowledgeable
> enough to do so.

Does it really help?  I think temacs loads the preloaded files before
it processes --eval on the command line, isn't that so?

> The only case that's really different is temacs -nl: it would probably
> behave differently if it worked (to the extend bare temacs even does).

Not sure "temacs -nl" is important in this context.  I've never used
that except for debugging very rare and special problems.

> temacs -nl fixable, but I'll wait for a response before looking into
> doing that properly.  Might not be worth it.

I wouldn't complicate the code because of "temacs -nl".

> > It's not optimal, indeed.  See a somewhat better arrangement we have
> > with the variables which should trigger redisplay of the current
> > buffer, at the end of frame.el.
> 
> I've tried this:
> 
> diff --git a/lisp/help-fns.el b/lisp/help-fns.el
> index 9324cf85454..f4f595aedbe 100644
> --- a/lisp/help-fns.el
> +++ b/lisp/help-fns.el
> @@ -1712,7 +1712,9 @@ help-fns--var-watchpoints
>      (when watchpoints
>        (princ "  Calls these functions when changed: ")
>        ;; FIXME: Turn function names into hyperlinks.
> -      (princ watchpoints)
> +      (dolist (watchpoint watchpoints)
> +        (princ (help-fns-function-name watchpoint))
> +        (princ "\n  "))
>        (terpri))))
>  
> it generates a three-digit hex hash of the function, which is a lot
> nicer than bytecode, but still not ideal.
> 
> Adding a docstring and a name to the function produces:
> 
>   Calls these functions when changed: (#[1028 \300!\207 [debug--on-event] 6 (bindings.elc . 52251)])
> 
> If there's a better way to fix this minor problem, we probably should.

This might be a misunderstanding.  I meant to use a subr, as we do in
frame.el.  "C-h v" then says:

    Calls these functions when changed: (#<subr set-buffer-redisplay>)

Isn't that slightly nicer than

  (#[1028 \300!\207 [debug--on-event] 6 (bindings.elc . 52251)]) 

?  That would mean make debug--on-event a subr, not a DEFUN.

> @@ -8280,6 +8284,7 @@ add_user_signal (int sig, const char *name)
>    p = xmalloc (sizeof *p);
>    p->sig = sig;
>    p->name = xstrdup (name);
> +  p->debug_on_event = !strcmp (p->name, "sigusr2");

Hmm... why only sigusr2? what about sigusr1?

> I hope I didn't run off and do something totally different from what
> you intended.

Doesn't look like that, no.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.