libsigsegv?

libsigsegv?

[Eli Zaretskii]

Apropos stack overflow protection: why not use libsigsegv if it is
available?  It is capable of doing what we want (AFAICT), and supports
more platforms, including MS-Windows.

Re: libsigsegv?

[Dmitry Antipov]

On 09/11/2014 07:08 PM, Eli Zaretskii wrote:

> Apropos stack overflow protection: why not use libsigsegv if it is
> available?  It is capable of doing what we want (AFAICT), and supports
> more platforms, including MS-Windows.

1. Stefan's mood gets worse after each new library dependency.

2. Basically libsigsegv uses the following heuristics to distinguish between
    stack overflow and other kinds of SIGSEGVs:
    a) If the fault address is near the stack pointer, it's a stack overflow.
    b) If the fault address is near and beyond the bottom of the stack's virtual
       memory area, it's a stack overflow.
    c) If the stack pointer is near the bottom of the stack's virtual memory area,
       it's a stack overflow.

    Currently we have only b), and this is the only thing which can be implemented
    staying in POSIX interfaces and without architecture-dependent tricks. a) may
    be implemented in a small forest of #ifdefs, and it doesn't worth using an
    extra library. c) is the most controversial - for example, on GNU/Linux it works
    by opening and reading /proc/self/maps.  Do you really want to open and read file
    on SIGSEGV?  I do not.

Dmitry

Re: libsigsegv?

[Eli Zaretskii]

> Date: Thu, 11 Sep 2014 19:49:19 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: emacs-devel@gnu.org
> 
> On 09/11/2014 07:08 PM, Eli Zaretskii wrote:
> 
> > Apropos stack overflow protection: why not use libsigsegv if it is
> > available?  It is capable of doing what we want (AFAICT), and supports
> > more platforms, including MS-Windows.
> 
> 1. Stefan's mood gets worse after each new library dependency.

But what is your take on this?

Please note that my suggestion is to use the library only
_if_available_, and only for stack overflow detection.

> 2. Basically libsigsegv uses the following heuristics to distinguish between
>     stack overflow and other kinds of SIGSEGVs:
>     a) If the fault address is near the stack pointer, it's a stack overflow.
>     b) If the fault address is near and beyond the bottom of the stack's virtual
>        memory area, it's a stack overflow.
>     c) If the stack pointer is near the bottom of the stack's virtual memory area,
>        it's a stack overflow.
> 
>     Currently we have only b), and this is the only thing which can be implemented
>     staying in POSIX interfaces and without architecture-dependent tricks.

But libsigsegv already did all those tricks, and it stays stable for
quites some time on many platforms (the long and impressive list is in
the library, I suggest to take a look).  So why not use all that
knowledge and experience?

>     a) may be implemented in a small forest of #ifdefs, and it
>     doesn't worth using an extra library.

Are you going to implement it for the platforms we support?  The
library is exceedingly small and static, btw.

>     c) is the most controversial - for example, on GNU/Linux it works
>     by opening and reading /proc/self/maps.  Do you really want to open and read file
>     on SIGSEGV?  I do not.

/proc/self/maps is not a real file, AFAIK.

Besides, other projects do that (e.g., Gawk).  I don't see why we
shouldn't.

Re: libsigsegv?

[Paul Eggert]

Eli Zaretskii wrote:
> other projects do that (e.g., Gawk).

And other projects avoid libsigsegv and do it themselves (e.g., 
coreutils, m4), due in part to the problems that Dmitry mentioned.  I am 
skeptical about using libsigsegv, though I admit I haven't looked into 
the details for quite some time.

Re: libsigsegv?

[Dmitry Antipov]

On 09/11/2014 08:04 PM, Eli Zaretskii wrote:

> But what is your take on this?

I don't like to discuss nearly the same things twice:
https://lists.gnu.org/archive/html/emacs-devel/2014-02/msg00063.html

> But libsigsegv already did all those tricks, and it stays stable for
> quites some time on many platforms (the long and impressive list is in
> the library, I suggest to take a look).  So why not use all that
> knowledge and experience?

"Use" != "link with that library".

> Besides, other projects do that (e.g., Gawk).  I don't see why we
> shouldn't.

Not on my system, BTW:

$ ldd /usr/bin/gawk
         linux-vdso.so.1 =>  (0x00007fffe5b54000)
	libdl.so.2 => /lib64/libdl.so.2 (0x0000003291400000)
	libm.so.6 => /lib64/libm.so.6 (0x0000003291000000)
	libc.so.6 => /lib64/libc.so.6 (0x0000003290c00000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003290800000)

AFAICS Fedora guys uses --with-libsigsegv-prefix=no for gawk since 2009.

Dmitry

Re: libsigsegv?

[Eli Zaretskii]

> Date: Thu, 11 Sep 2014 20:20:14 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: emacs-devel@gnu.org
> 
> > Besides, other projects do that (e.g., Gawk).  I don't see why we
> > shouldn't.
> 
> Not on my system, BTW:

It's an optional feature, in Gawk as well.

Re: libsigsegv?

[Stefan Monnier]

> 1. Stefan's mood gets worse after each new library dependency.

At the same time, I prefer when we use an off the shelf library over
reimplementing the functionality by hand.

As for my opinion on stack-overflow handling: I think it's of very
little importance.


        Stefan "the wonders of ambiguity"