[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Throw an exception when mutating read-only data
From: |
Pedro Alves |
Subject: |
Re: [PATCH] Throw an exception when mutating read-only data |
Date: |
Mon, 3 Apr 2017 11:49:45 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 |
Hi Andy,
I'm mostly clueless on Guile's internals, but this patch caught my
eye, given the potential for conflict with GDBs use of libguile.
On 04/02/2017 11:11 AM, Andy Wingo wrote:
> +void
> +scm_maybe_throw_exception_for_mutation_of_read_only_data (void *addr)
> +{
> + if (!find_mapped_elf_image_unlocked (addr))
> + return;
> +
> + /* Assume that a SEGV originating from access to an address in our
> + mapped ELF images is because that part of the image was mapped
> + read-only, and user code is trying to mutate it. Throw an
> + exception instead. */
> + scm_misc_error (NULL, "Attempt to mutate read-only value", SCM_EOL);
AFAICS, guile uses bare setjmp/longjmp for exceptions.
But, one should not use longjmp to jump out of a signal handler, since
that leaves the signal mask disabled if the system automatically masks
the signal on handler entry (which is true on e.g., the Linux kernel).
Instead, sigsetjmp+siglongjmp should be used, in order to restore
the signal mask.
Since sigsetjmp is heavy weight (it requires a system call to get the current
mask [1]), I'd recommend instead to use sigsetjmp/siglongjmp around the
problematic code area, and then call scm_misc_error back in mainline code (as
opposed to changing SCM_I_SETJMP/SCM_I_LONGJMP and forcing all exception
handling to use sigsetjmp+siglongjmp).
[1] - See <https://sourceware.org/ml/gdb-patches/2016-04/msg00249.html>
and the linked URL for a practical difference that made in GDB.
Thanks,
Pedro Alves