guile-devel
[Top][All Lists]
Advanced

[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




reply via email to

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