Just curious about the behaviour and performance of mprotect and VirtualProtect.  Would it be feasible to use on each FFI callout so that aberrant memory access from C code cannot corrupt the Smalltalk Image, but generate an exception that could be handled in-Image?

cheers -ben

On Fri, Dec 23, 2016 at 12:37 AM, GitHub <noreply@github.com> wrote:
 
  Branch: refs/heads/Cog
  Home:   https://github.com/OpenSmalltalk/opensmalltalk-vm
  Commit: 28630b8c60c35096175f6d6fddb5cd91d7868882
      https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/28630b8c60c35096175f6d6fddb5cd91d7868882
  Author: Ronie Salgado <roniesalg@gmail.com>
  Date:   2016-12-20 (Tue, 20 Dec 2016)

  Changed paths:
    M platforms/unix/vm/sqUnixSpurMemory.c
    M platforms/win32/vm/sqWin32SpurAlloc.c

  Log Message:
  -----------
  The extra +1 in size parameter passed to mprotect(Unix) and VirtualProtect(Windows).


  Commit: 4d732c6db375be18a96a3c850f60a14538d2d867
      https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/4d732c6db375be18a96a3c850f60a14538d2d867
  Author: Ronie Salgado <roniesalg@gmail.com>
  Date:   2016-12-21 (Wed, 21 Dec 2016)

  Changed paths:
    M platforms/unix/vm/sqUnixSpurMemory.c

  Log Message:
  -----------
  Computing the size after rounding down the start address.


  Commit: 11880398af1da706e7b61802c11985f12bef280e
      https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/11880398af1da706e7b61802c11985f12bef280e
  Author: Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>
  Date:   2016-12-22 (Thu, 22 Dec 2016)

  Changed paths:
    M platforms/unix/vm/sqUnixSpurMemory.c
    M platforms/win32/vm/sqWin32SpurAlloc.c

  Log Message:
  -----------
  Merge pull request #109 from ronsaldo/MProtectBug

Bug when calling mprotect and VirtualAlloc with the SpurMemoryManager


Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/28293aa6b85e...11880398af1d