* bug#25912: 2.1.7 segfaults on cygwin @ 2017-03-01 10:27 ` szgyg 2017-03-01 16:47 ` Andy Wingo 2017-03-03 14:32 ` Mike Gran 0 siblings, 2 replies; 7+ messages in thread From: szgyg @ 2017-03-01 10:27 UTC (permalink / raw) To: 25912 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#25912: 2.1.7 segfaults on cygwin 2017-03-01 10:27 ` bug#25912: 2.1.7 segfaults on cygwin szgyg @ 2017-03-01 16:47 ` Andy Wingo 2017-03-02 9:13 ` szgyg 2017-03-03 14:32 ` Mike Gran 1 sibling, 1 reply; 7+ messages in thread From: Andy Wingo @ 2017-03-01 16:47 UTC (permalink / raw) To: szgyg; +Cc: 25912 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#25912: 2.1.7 segfaults on cygwin 2017-03-01 16:47 ` Andy Wingo @ 2017-03-02 9:13 ` szgyg 2017-03-06 19:41 ` Andy Wingo 0 siblings, 1 reply; 7+ messages in thread From: szgyg @ 2017-03-02 9:13 UTC (permalink / raw) To: Andy Wingo; +Cc: 25912 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; ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#25912: 2.1.7 segfaults on cygwin 2017-03-02 9:13 ` szgyg @ 2017-03-06 19:41 ` Andy Wingo 2017-03-08 16:50 ` szgyg 0 siblings, 1 reply; 7+ messages in thread From: Andy Wingo @ 2017-03-06 19:41 UTC (permalink / raw) To: szgyg; +Cc: 25912 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#25912: 2.1.7 segfaults on cygwin 2017-03-06 19:41 ` Andy Wingo @ 2017-03-08 16:50 ` szgyg 0 siblings, 0 replies; 7+ messages in thread From: szgyg @ 2017-03-08 16:50 UTC (permalink / raw) To: Andy Wingo; +Cc: 25912 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#25912: 2.1.7 segfaults on cygwin 2017-03-01 10:27 ` bug#25912: 2.1.7 segfaults on cygwin szgyg 2017-03-01 16:47 ` Andy Wingo @ 2017-03-03 14:32 ` Mike Gran 2017-03-14 11:35 ` Andy Wingo 1 sibling, 1 reply; 7+ messages in thread From: Mike Gran @ 2017-03-03 14:32 UTC (permalink / raw) To: 25912@debbugs.gnu.org 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#25912: 2.1.7 segfaults on cygwin 2017-03-03 14:32 ` Mike Gran @ 2017-03-14 11:35 ` Andy Wingo 0 siblings, 0 replies; 7+ messages in thread From: Andy Wingo @ 2017-03-14 11:35 UTC (permalink / raw) To: Mike Gran; +Cc: 25912@debbugs.gnu.org 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-03-14 11:35 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <78221352.340980.1488551525340.ref@mail.yahoo.com> 2017-03-01 10:27 ` bug#25912: 2.1.7 segfaults on cygwin szgyg 2017-03-01 16:47 ` Andy Wingo 2017-03-02 9:13 ` szgyg 2017-03-06 19:41 ` Andy Wingo 2017-03-08 16:50 ` szgyg 2017-03-03 14:32 ` Mike Gran 2017-03-14 11:35 ` Andy Wingo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).