[Ecls-list] Patch: remove sbrk() usage in handle_signal()

[Geo Carncross]

On Sat, Oct 4, 2008 at 9:56 PM, Josh Elsasser <josh at elsasser.org> wrote:
> On Sat, Oct 04, 2008 at 09:13:08PM -0400, Geo Carncross wrote:
>> On Sat, Oct 4, 2008 at 3:16 PM, Josh Elsasser <josh at elsasser.org> wrote:
>> > The new stack overflow detection code uses sbrk(), which is not
>> > portable.
>>
>> Do you have a system that ECL runs on that doesn't have sbrk()?
>>
>> >  I'm guessing that it was used to detect if the signal
>> > handler was executing on the alternate signal stack, if that is the
>> > case then sigaltstack() would be the portable way to test for that.
>>
>> It isn't. The sbrk(0) is the top of the heap. The only things above it
>> should be mmap'd regions, and the stack. Since most unixes
>> automatically extend the stack, the first SIGSEGV above it is either a
>> very errant pointer, or the stack guard.
>
> On my system (OpenBSD/i386) they adjust the size of the
> process's data segment, which is located in a different address range
> than memory allocated by malloc().  With the current address space
> layout, sbrk(0) will always return an address less than any stack or
> heap address.

Oh that's right. OpenBSD uses mmap() for it's malloc implementation
because there's a guard around it.

Unfortunately, that means on OpenBSD the only way to differentiate
between a segmentation violation in freed/malloc'd space and a stack
overflow is to check the instruction that did the violation.

> I could be wrong, but I don't see any reason why the stack would have
> to be located above the heap either.

You're right about this; on systems where the stack grows up, it'll
likely be below the heap. However these people are doomed unless the
heap is placed very far away.

Implementing a non-GNU version of libsiginfo might be necessary in
order to support these platforms, but, does ECL support them?