bug#25912: 2.1.7 segfaults on cygwin

bug#25912: 2.1.7 segfaults on cygwin

[szgyg]

I got two identical segfaults from make -j2 on 32-bit cygwin, and
three identical segfaults from make -j3 on 64-bit at the same point.

Any idea?

-----------------

Making all in bootstrap
make[2]: Entering directory '/home/szgyg/usr/src/CYGPORT/guile2-2.1.7-0.i686/build/bootstrap'
  BOOTSTRAP GUILEC ice-9/eval.go
wrote `ice-9/eval.go'
  BOOTSTRAP GUILEC ice-9/psyntax-pp.go
  BOOTSTRAP GUILEC language/cps/intmap.go
*** starting debugger for pid 5024, tid 4568
*** starting debugger for pid 5060, tid 1904

----------------

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 5024.0x11d8]
vm_regular_engine (thread=0x20081e40, vp=0x200f0f78, registers=0x22c480,
    resume=0) at /usr/src/debug/guile2-2.1.7-0/libguile/vm-engine.c:1840
1840          *dst_loc = src;

(gdb) info locals
src = 0x7ff800d8
dst_loc = 0x7ff8d00c
op = 63
jump_table_ = {0x64b956d1 <vm_regular_engine+145>,
[...]

(gdb) print *dst_loc
$3 = (void *) 0x0

(gdb) print *dst_loc = src
Cannot access memory at address 0x7ff8d00c

(gdb) print argv[13]
$16 = 0x612eba68 "language/cps/intmap.go"

---------------------

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 5060.0x770]
vm_regular_engine (thread=0x20081e40, vp=0x200f0f78, registers=0x22c480,
    resume=0) at /usr/src/debug/guile2-2.1.7-0/libguile/vm-engine.c:1840
1840          *dst_loc = src;

(gdb) info locals
src = 0x7ff800d8
dst_loc = 0x7ff8d00c
op = 63
jump_table_ = {0x64b956d1 <vm_regular_engine+145>,
[...]

(gdb) print argv[13]
$6 = 0x612eba68 "ice-9/psyntax-pp.go"

-----------------------

Making all in bootstrap
make[2]: Entering directory '/home/szgyg/usr/src/CYGPORT/guile/guile2-2.1.7-0.x86_64/build/bootstrap'
  BOOTSTRAP GUILEC ice-9/eval.go
wrote `ice-9/eval.go'
  BOOTSTRAP GUILEC ice-9/psyntax-pp.go
  BOOTSTRAP GUILEC language/cps/intmap.go
*** starting debugger for pid 9848, tid 6772
  BOOTSTRAP GUILEC language/cps/intset.go
*** starting debugger for pid 6600, tid 376
*** starting debugger for pid 10136, tid 9064

--------------------------

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 6600.0x178]
vm_regular_engine (thread=0x600091e00, vp=0x600131f30, registers=0x1, resume=0)
    at /usr/src/debug/guile2-2.1.7-0/libguile/vm-engine.c:1840
1840    /usr/src/debug/guile2-2.1.7-0/libguile/vm-engine.c: No such file or directory.
(gdb)

(gdb) info locals
src = 0x6fffffd0128
dst_loc = 0x6fffffdd010
op = 63
jump_table_ = {0x4236bece4 <vm_regular_engine+180>, 0x4236bed84 <vm_regular_engine+340>,
[...]

------------------------

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 9848.0x1a74]
vm_regular_engine (thread=0x600091e00, vp=0x600130f30, registers=0x1, resume=0)
    at /usr/src/debug/guile2-2.1.7-0/libguile/vm-engine.c:1840
1840    /usr/src/debug/guile2-2.1.7-0/libguile/vm-engine.c: No such file or directory.

(gdb) info locals
src = 0x6fffffd0128
dst_loc = 0x6fffffdd010
op = 63
jump_table_ = {0x4236bece4 <vm_regular_engine+180>, 0x4236bed84 <vm_regular_engine+340>,
[...]

-------------------------

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 10136.0x2368]
vm_regular_engine (thread=0x600091e00, vp=0x600131f30, registers=0x1, resume=0)
    at /usr/src/debug/guile2-2.1.7-0/libguile/vm-engine.c:1840
1840    /usr/src/debug/guile2-2.1.7-0/libguile/vm-engine.c: No such file or directory.

(gdb) info locals
src = 0x6fffffd0128
dst_loc = 0x6fffffdd010
op = 63
jump_table_ = {0x4236bece4 <vm_regular_engine+180>, 0x4236bed84 <vm_regular_engine+340>,
[...]

-----------------------

$ less -N +g1840 vm-engine.c
   1821   /* static-patch! _:24 dst-offset:32 src-offset:32
   1822    *
   1823    * Patch a pointer at DST-OFFSET to point to SRC-OFFSET.  Both offsets
   1824    * are signed 32-bit values, indicating a memory address as a number
   1825    * of 32-bit words away from the current instruction pointer.
   1826    */
   1827   VM_DEFINE_OP (63, static_patch, "static-patch!", OP3 (X32, LO32, L32))
   1828     {
   1829       scm_t_int32 dst_offset, src_offset;
   1830       void *src;
   1831       void** dst_loc;
   1832
   1833       dst_offset = ip[1];
   1834       src_offset = ip[2];
   1835
   1836       dst_loc = (void **) (ip + dst_offset);
   1837       src = ip + src_offset;
   1838       VM_ASSERT (ALIGNED_P (dst_loc, void*), abort());
   1839
   1840       *dst_loc = src;
   1841
   1842       NEXT (3);
   1843     }
   1844

bug#25912: 2.1.7 segfaults on cygwin

[Andy Wingo]

On Wed 01 Mar 2017 11:27, szgyg <szgyg@ludens.elte.hu> writes:

> I got two identical segfaults from make -j2 on 32-bit cygwin, and
> three identical segfaults from make -j3 on 64-bit at the same point.
>
> Any idea?

Could it be some mprotect issue?  static-patch is a bytecode that is
used when doing run-time relocations in the .go files, when they are
first loaded up.  They are loaded by loader.c.  I usually use the mmap
path; is that being used on cygwin?  Is it reliable?  There is a
fallback path that doesn't use any memory protection.  See loader.c.

Andy

bug#25912: 2.1.7 segfaults on cygwin

[szgyg]

On Wed, Mar 01, 2017 at 05:47:30PM +0100, Andy Wingo wrote:
> On Wed 01 Mar 2017 11:27, szgyg <szgyg@ludens.elte.hu> writes:
> 
> > I got two identical segfaults from make -j2 on 32-bit cygwin, and
> > three identical segfaults from make -j3 on 64-bit at the same point.
> >
> > Any idea?
> 
> Could it be some mprotect issue?  static-patch is a bytecode that is
> used when doing run-time relocations in the .go files, when they are
> first loaded up.  They are loaded by loader.c.  I usually use the mmap
> path; is that being used on cygwin?  Is it reliable?  There is a
> fallback path that doesn't use any memory protection.  See loader.c.

Thanks.

load_thunk_from_memory doesn't call mprotect because in loader.c
line 436 the ELF segment is aligned to 4k while page size is 64k.

436               if (ph[i].p_align != page_size)
(gdb) print page_size
$3 = 65536
(gdb) print ph[i].p_align
$4 = 4096


(gdb) print *ph@n
$2 = {
{p_type = 1, p_offset = 0,     p_vaddr = 0,     p_paddr = 0,     p_filesz = 50264, p_memsz = 50264, p_flags = 4, p_align = 4096},
{p_type = 1, p_offset = 53248, p_vaddr = 53248, p_paddr = 53248, p_filesz = 1944,  p_memsz = 1944,  p_flags = 6, p_align = 4096},
{p_type = 2, p_offset = 50208, p_vaddr = 50208, p_paddr = 50208, p_filesz = 56,    p_memsz = 56,    p_flags = 4, p_align = 8}
}


I have applied the patch below as a workaround, and now I can compile guile.


--- origsrc/guile-2.1.7/libguile/loader.c	2017-01-08 23:38:55.000000000 +0100
+++ src/guile-2.1.7/libguile/loader.c	2017-03-01 21:57:35.114163900 +0100
@@ -475,7 +475,7 @@ map_file_contents (int fd, size_t len, i
   char *data;
 
 #ifdef HAVE_SYS_MMAN_H
-  data = mmap (NULL, len, PROT_READ, MAP_PRIVATE, fd, 0);
+  data = mmap (NULL, len, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
   if (data == MAP_FAILED)
     SCM_SYSERROR;
   *is_read_only = 1;

bug#25912: 2.1.7 segfaults on cygwin

[Mike Gran]

Hi-
I also can replicate the Cygwin problem as originally described.
After wingo's comment on the mmap path vs the non-mmap path,
I tried to use the non-mmap path by removing HAVE_SYS_MMAN_H
from the config.h.
The non-mmap path doesn't build.  The errors are in map_file_contents()
in loader.c
Making the obvious patches to map_file_contents() does
seem to allow the Cygwin build to continue.
The helper functions sniff_elf_alignment and copy_and_align_elf_data
are no longer included in master and had to be pulled from an older
rev.
Regards,
Mike

bug#25912: 2.1.7 segfaults on cygwin

[Andy Wingo]

Hi :)

On Thu 02 Mar 2017 10:13, szgyg <szgyg@ludens.elte.hu> writes:

> load_thunk_from_memory doesn't call mprotect because in loader.c
> line 436 the ELF segment is aligned to 4k while page size is 64k.

Ah, thank you for tracking this down.  I think we were going to just
change the page size to 64K for .go files but I can't remember.  I think
libc's loader doesn't actually align the pages on disk but projects
segments of the file onto the memory image.

What platform is this that has 64K pages?  IIUC cygwin's usual size is
4096 bytes.

Andy

bug#25912: 2.1.7 segfaults on cygwin

[szgyg]

On Mon, Mar 06, 2017 at 08:41:56PM +0100, Andy Wingo wrote:
> On Thu 02 Mar 2017 10:13, szgyg <szgyg@ludens.elte.hu> writes:
> 
> > load_thunk_from_memory doesn't call mprotect because in loader.c
> > line 436 the ELF segment is aligned to 4k while page size is 64k.
> 
> Ah, thank you for tracking this down.  I think we were going to just
> change the page size to 64K for .go files but I can't remember.  I think
> libc's loader doesn't actually align the pages on disk but projects
> segments of the file onto the memory image.

Changing *page-size* to 64k in linker.scm solves the problem. Size of
bootstrap/ goes from 17MB to 20MB.


> What platform is this that has 64K pages?  IIUC cygwin's usual size is
> 4096 bytes.

Pagesize is 4k on windows, but we can't allocate a single page, only
batches of 16 pages. Cygwin is hiding this abomination by using 64k
as pagesize.

bug#25912: 2.1.7 segfaults on cygwin

[Andy Wingo]

On Fri 03 Mar 2017 15:32, Mike Gran <spk121@yahoo.com> writes:

> I also can replicate the Cygwin problem as originally described.

I understand that with the fix in 2.1.8, that things are working
correctly now; closing the report.  Thanks for the sleuthing, szgyg and
Mike!

Andy