* libsigsegv?
@ 2014-09-11 15:08 Eli Zaretskii
2014-09-11 15:49 ` libsigsegv? Dmitry Antipov
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2014-09-11 15:08 UTC (permalink / raw)
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: libsigsegv?
2014-09-11 15:08 libsigsegv? Eli Zaretskii
@ 2014-09-11 15:49 ` Dmitry Antipov
2014-09-11 16:04 ` libsigsegv? Eli Zaretskii
2014-09-11 19:27 ` libsigsegv? Stefan Monnier
0 siblings, 2 replies; 7+ messages in thread
From: Dmitry Antipov @ 2014-09-11 15:49 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: libsigsegv?
2014-09-11 15:49 ` libsigsegv? Dmitry Antipov
@ 2014-09-11 16:04 ` Eli Zaretskii
2014-09-11 16:19 ` libsigsegv? Paul Eggert
2014-09-11 16:20 ` libsigsegv? Dmitry Antipov
2014-09-11 19:27 ` libsigsegv? Stefan Monnier
1 sibling, 2 replies; 7+ messages in thread
From: Eli Zaretskii @ 2014-09-11 16:04 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: libsigsegv?
2014-09-11 16:04 ` libsigsegv? Eli Zaretskii
@ 2014-09-11 16:19 ` Paul Eggert
2014-09-11 16:20 ` libsigsegv? Dmitry Antipov
1 sibling, 0 replies; 7+ messages in thread
From: Paul Eggert @ 2014-09-11 16:19 UTC (permalink / raw)
To: Eli Zaretskii, Dmitry Antipov; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: libsigsegv?
2014-09-11 16:04 ` libsigsegv? Eli Zaretskii
2014-09-11 16:19 ` libsigsegv? Paul Eggert
@ 2014-09-11 16:20 ` Dmitry Antipov
2014-09-11 16:48 ` libsigsegv? Eli Zaretskii
1 sibling, 1 reply; 7+ messages in thread
From: Dmitry Antipov @ 2014-09-11 16:20 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: libsigsegv?
2014-09-11 16:20 ` libsigsegv? Dmitry Antipov
@ 2014-09-11 16:48 ` Eli Zaretskii
0 siblings, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2014-09-11 16:48 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: libsigsegv?
2014-09-11 15:49 ` libsigsegv? Dmitry Antipov
2014-09-11 16:04 ` libsigsegv? Eli Zaretskii
@ 2014-09-11 19:27 ` Stefan Monnier
1 sibling, 0 replies; 7+ messages in thread
From: Stefan Monnier @ 2014-09-11 19:27 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: Eli Zaretskii, emacs-devel
> 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"
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-09-11 19:27 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-09-11 15:08 libsigsegv? Eli Zaretskii
2014-09-11 15:49 ` libsigsegv? Dmitry Antipov
2014-09-11 16:04 ` libsigsegv? Eli Zaretskii
2014-09-11 16:19 ` libsigsegv? Paul Eggert
2014-09-11 16:20 ` libsigsegv? Dmitry Antipov
2014-09-11 16:48 ` libsigsegv? Eli Zaretskii
2014-09-11 19:27 ` libsigsegv? Stefan Monnier
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.