emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SIGTRAP in kill emulation on Windows


From: Eli Zaretskii
Subject: Re: SIGTRAP in kill emulation on Windows
Date: Thu, 25 Aug 2016 19:18:20 +0300

> From: Alain Schneble <address@hidden>
> Date: Thu, 25 Aug 2016 17:08:51 +0200
> 
> The following patch provides support for SIGTRAP in the kill emulation
> on Windows.  It implements mapping SIGTRAP to a call to
> DebugBreakProcess in C code.  Patches that implement the discussed use
> cases in LISP will be submitted separately as this change is useful on
> its own, e.g. (signal-process PROCESS 'TRAP).

Thanks.  I think this needs an entry in NEWS.

> +  else if (sig == SIGTRAP)
> +    {
> +#if _WIN32_WINNT >= _WIN32_WINNT_WINXP
> +      if (!DebugBreakProcess (proc_hand))

We don't put in Emacs sources compile-time conditionals that depend on
the version of the OS on which Emacs is built: that would preclude the
(very popular on Windows) practice of building Emacs on one system,
and then using it on many others, possibly running other versions of
the OS.

Instead, functions that might be unavailable at run time are called
through a function pointer, which is assigned the value when it is
first needed, by looking up the function address in the corresponding
DLL (and loading the DLL if needed, which is not the case here).
Please see an example of how that is done in
w32proc.c:w32_compare_strings (and in many places in w32.c).

> +     {
> +       DWORD err = GetLastError ();
> +
> +       DebPrint (("sys_kill.DebugBreakProcess return %d "
> +                  "for pid %lu\n", err, pid));
> +
> +       switch (err)
> +         {
> +         case ERROR_ACCESS_DENIED:
> +           errno = EPERM;
> +           break;
> +         default:
> +           errno = EINVAL;
> +           break;
> +         }
> +
> +       rc = -1;
> +     }
> +#else
> +      errno = EINVAL;
> +      rc = -1;

When the function is not available, you should assign ENOTSUP to
errno, not EINVAL, to make the error message more accurate.

Please test what this functionality does when PID specifies a child
process of Emacs (which is tracked via the child_procs[] array), and
also when it specifies the calling Emacs process itself.  If any of
these use cases cause any kind of trouble, we may wish to disallow
such usage, to prevent users from shooting themselves in the foot.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]