bug#74274: [PATCH] Revert part of d3f8ed730f to avoid segmentation fault

[Gerd Möllmann]

Gong Qijian <gongqijian@gmail.com> writes:

> Patch for branch scratch/tty-child-frames to avoid segmentation fault.
>
> The issue can be triggered by the message function when creating a tty
> child frame during the initialization process.
>
> Reproduce:
>
>   $ src/emacs -nw -Q --eval "\
>     (progn
>       (require 'cl-lib)
>       (require 'tty-tip)
>       (advice-add 'tty-tip--compute-position :around
>        (defun tty-tip--compute-position@fix-nil-error (&rest args)
>          (cl-letf ((orig-mouse-position (symbol-function #'mouse-position))
>                    ((symbol-function #'mouse-position)
>                     (lambda ()
>                       (if (terminal-parameter nil 'xterm-mouse-x)
>                           (funcall orig-mouse-position)
>                         (cons (window-frame) (posn-x-y (posn-at-point)))))))
>            (apply args))))
>
>       (tty-tip--create-frame \"line1\nline2\")
>       (message \"tty-type: %S\" (tty-type)))"
>   Fatal error 11: Segmentation fault
>   ^[[Ifish: Job 1, 'src/emacs -nw -Q --eval "\…' terminated by signal (pro… 
> (SIGABRT)
>   fish: Job Abort, '' terminated by signal  ()

Thanks Gong Qijian, I think I can reproduce this here. Before debugging
this, I'd like to understand your test case a bit better, though. (And
I'm procrastinating a bit :-).)

Do I understand this right, that the advice you add to
tty-tip-compute-position only serves the purpose of being able to pop up
a tip frame early, when mouse-position doesn't really have a position to
report? Or does it also serve another purpose?

Another interesting question would be in which other, let's say more
normal, circumstances you observe this segfault.