Re: help needed to fix contrib/ee crash/exit when receiving SIGWINCH
Dag-Erling Smørgrav schrieb am 2009-10-26: > Rong-En Fan writes: > > devel/ncurses-devel will be updated this week. For base's ncurses, > > I'll > > check with Thomas Dickey to see if there will be 5.8 soon. If not, > > we > > can also import a recent snapshot. > There is no reason to wait, nor to import an entire snapshot. Se my > earlier message to Alexander. > DES rafan just mfc'ed the patch. could we also have the fix in 8.0-RELEASE? should get approved by r...@. alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: mmap(2) segaults with certain len values and MAP_ANON|MAP_FIXED
John Baldwin schrieb am 2009-10-21: > On Wednesday 21 October 2009 11:30:51 am Alexander Best wrote: > > Robert Watson schrieb am 2009-10-21: > > > On Wed, 21 Oct 2009, Alexander Best wrote: > > > >this code serves only one purpose: to trigger a segfault. i > > > >don't > > > >use the code for any other purpose. i was under the impression > > > >that > > > >mmap() should either succeed or fail (tertium non datur). mmap's > > > >manual doesn't say anything about mmap() causing segfaults. > > > Have you tried ktracing the application? I think you'll find > > > that > > > mmap(2) system call succeeded fine, and that the segfault comes > > > from > > > attempting to execute the address in libc on return to userspace, > > > as > > > a result of libc not being at that address anymore (since you > > > removed its mapping). You can use procstat -v to inspect address > > > space use by processes, but as a general rule you don't want to > > > pass > > > anything other than an address of 0x0 to mmap(2) unless you're > > > very > > > carefully managing the address space of the process. Many > > > userspace > > > libraries are involved in using that address space, but > > > especially > > > the runtime linker which begins execution in userspace when a > > > binary > > > is started. > > > Robert N M Watson > > > Computer Laboratory > > > University of Cambridge > > you're right. this kdump shows that the segfault isn't being caused > > by the > > mmap() call: > > 88343 mmap_test CALL > > mmap(0x1000,0x80047000,PROT_NONE,MAP_FIXED|MAP_ANON,0x,0,0) > > 88343 mmap_test RET mmap 4096/0x1000 > > 88343 mmap_test PSIG SIGSEGV SIG_DFL > > 88343 mmap_test NAMI "mmap_test.core" > > thanks for clearing things up. > > however i stil think mentioning this situation in the mmap(2) > > manual (maybe in > > section MAP_FIXED) would be a good idea. > I'm not sure it is useful to attempt to enumerate all the possible > ways one > can shoot one's own foot using mmap(2) in the manual page. The list > would be > quite long and would require a large amount of imagination. In > effect, you > are asking for a manual page to document all the possible bugs one > could have > and manual pages in general do not do that. you're probably right. documenting all things one can do wrong using mmap isn't what the manual is supposed to do. thanks for the help. alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: mmap(2) with MAP_ANON honouring offset although it shouldn't
John Baldwin schrieb am 2009-10-21:
> On Wednesday 21 October 2009 11:51:04 am Alexander Best wrote:
> > although the mmap(2) manual states in section MAP_ANON:
> > "The offset argument is ignored."
> > this doesn't seem to be true. running
> > printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, MAP_ANON, -1,
> > 0x12345678));
> > and
> > printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, MAP_ANON, -1,
> > 0));
> > produces different outputs. i've attached a patch to solve the
> > problem. the
> > patch is similar to the one proposed in this PR, but should apply
> > cleanly to
> > CURRENT: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71258
> A simpler patch would be to simply set pos = 0 below the MAP_STACK
> line if
> MAP_ANON is set.
how about the following patch. problem seems to be that pos = 0 needs to be
set before pageoff is being calculated.
i've tested mmap with MAP_STACK and the offset gets discarded just as
documented in mmap(2). with the patch the offset handling with MAP_ANON and
MAP_STACK (implies MAP_ANON) are the same.
another short question:
why does the second call when doing
printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_READ|PROT_WRITE,
MAP_STACK, -1, 0x0));
printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_READ|PROT_WRITE,
MAP_STACK, -1, 0x0));
fail? doesn't MAP_STACK allow mapping the same region twice?
printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_READ|PROT_WRITE,
MAP_STACK, -1, 0x0));
printf("%p\n", mmap((void*)0x2000, 0x1000, PROT_READ|PROT_WRITE,
MAP_STACK, -1, 0x0));
works just as expected.
cheers.
alex
--- /usr/src/sys/vm/vm_mmap.c 2009-10-28 21:37:53.0 +0100
+++ ./vm_mmap.c 2009-10-31 03:22:44.0 +0100
@@ -241,9 +241,11 @@
((prot & (PROT_READ | PROT_WRITE)) != (PROT_READ |
PROT_WRITE)))
return (EINVAL);
flags |= MAP_ANON;
- pos = 0;
}
+ if (flags & MAP_ANON)
+ pos = 0;
+
/*
* Align the file position to a page boundary,
* and save its page offset component.
@@ -300,7 +302,6 @@
handle = NULL;
handle_type = OBJT_DEFAULT;
maxprot = VM_PROT_ALL;
- pos = 0;
} else {
/*
* Mapping file, get fp for validation and
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
