https://sourceware.org/bugzilla/show_bug.cgi?id=19903
--- Comment #1 from cvs-commit at gcc dot gnu.org ---
The master branch has been updated by Samuel Thibault
:
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=c9536b7b9ddb111bded10e7252da28a6826771d1
commit c9536b7b9ddb111bded10e7252da28a
https://sourceware.org/bugzilla/show_bug.cgi?id=19903
Samuel Thibault changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://sourceware.org/bugzilla/show_bug.cgi?id=19903
--- Comment #3 from joseph at codesourcery dot com ---
When marking a bug as FIXED, please set the target milestone to the first
mainline release with the fix (so 2.31 at present) so the bug appears in
the automatically-generated list of fix
https://sourceware.org/bugzilla/show_bug.cgi?id=19903
Samuel Thibault changed:
What|Removed |Added
Target Milestone|--- |2.31
--- Comment #4 from Samuel Thi
Samuel Thibault, on Sun 03 Apr 2016 11:27:48 +0200, wrote:
> Richard Braun, on Sat 02 Apr 2016 20:55:58 +0200, wrote:
> > On Sat, Apr 02, 2016 at 01:35:49PM -0300, Agustina Arzille wrote:
> > > As a workaround, we could always use 'vm_map', no matter what, since the
> > > idea that 'vm_allocate' ha
Agustina Arzille, on Mon 04 Apr 2016 13:01:27 -0300, wrote:
> I have a new libpthread implementation based on the 'gsync' module,
Groovy :)
Samuel
On 04/04/2016 04:34 AM, Samuel Thibault wrote:
You can submit that patch to the libc-al...@sourceware.org mailing list
(explaining the rationale etc. alongside), putting rol...@hack.frob.com
and this bug-hurd@gnu.org list in Cc. And we can commit the patch to
the debian libc in parallel.
Done.
Hello, everyone.
It appears that in GNU/Hurd, memory mappings obtained by 'mmap' with MAP_SHARED
and MAP_ANON as its flags are not being inherited by children processes.
Here's a simple program that illustrates the issue:
===
#include
#include
#include
#include
Hello,
Agustina Arzille, on Sat 02 Apr 2016 13:35:49 -0300, wrote:
> It appears that memory mappings obtained by 'mmap' with MAP_SHARED
> and MAP_ANON as its flags are not being inherited by children processes.
BTW, how did you discover this? Does this trigger a failure in some
application?
Sam
Hello,
Agustina Arzille, on Sun 03 Apr 2016 22:40:52 -0300, wrote:
> >You can submit that patch to the libc-al...@sourceware.org mailing list
> >(explaining the rationale etc. alongside), putting rol...@hack.frob.com
> >and this bug-hurd@gnu.org list in Cc. And we can commit the patch to
> >the d
https://sourceware.org/bugzilla/show_bug.cgi?id=19903
Bug ID: 19903
Summary: Shared mappings not being inherited by children
processes
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
On 04/03/2016 06:27 AM, Samuel Thibault wrote:
So the fix would be just to remove the whole
if ((flags & (MAP_TYPE|MAP_INHERIT)) == MAP_ANON
block?
Yes, that seems do the trick.
You can submit that patch to the libc-al...@sourceware.org mailing list
(explaining the rationale etc. alongsid
Richard Braun, on Sat 02 Apr 2016 20:55:58 +0200, wrote:
> On Sat, Apr 02, 2016 at 01:35:49PM -0300, Agustina Arzille wrote:
> > As a workaround, we could always use 'vm_map', no matter what, since the
> > idea that 'vm_allocate' has a little less overhead is somewhat bogus to me,
> > or
> > keep
On Sat, Apr 02, 2016 at 01:35:49PM -0300, Agustina Arzille wrote:
> As a workaround, we could always use 'vm_map', no matter what, since the
> idea that 'vm_allocate' has a little less overhead is somewhat bogus to me, or
> keep using 'vm_allocate', but do an additional 'vm_inherit' if the user
>
Hello, everyone.
It appears that memory mappings obtained by 'mmap' with MAP_SHARED
and MAP_ANON as its flags are not being inherited by children processes.
Here's a simple program that illustrates the issue:
===
#include
#include
#include
#include
int main (vo
15 matches
Mail list logo
