Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.rc > #208755

Bug#865549: [Pkg-rust-maintainers] Bug#865549: cargo still segfaults / rustc still FTBFS with the newest fixed kernel

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

Control: tag -1 upstream patch moreinfo

On Fri, 30 Jun 2017 08:57:00 +0000 Ximin Luo <infinity0@debian.org> wrote:
> Ben Hutchings:
> > On Thu, 2017-06-29 at 17:45 +0000, Ximin Luo wrote:
> >> Ximin Luo:
> >>> [..]
> >>>
> >>> The segfault occurs on various commands at different frequencies and after 
> >>> differing amounts of time (but all less than a few seconds). The stack traces 
> >>> are all different too. [..]
> >>
> >> With some help from arielby from #rust-internals, we noticed that the
> >> stack getting allocated was always 192KB even though `ulimit -s` says
> >> 8192 (i.e. 8MB),
> > 
> > That's normal.
> > 
> >> and when the program tries to grow beyond this, is when the segfaults
> >> occur. Hope that's useful.
> > 
> > That's obviously not.  A page fault below the stack mapping and not too
> > far below the stack pointer should cause the mapping to expand, up to
> > the limit, without the process having to do anything about it.
> > 
> > The shell ulimit command, and the underlying setrlimit(2) system call,
> > set the limit for expansion of the stack mapping.  Expansion is also
> > restricted by the requirement of a gap between the stack and the next
> > mapping below, but so long as the size limit is not 'unlimited' this
> > *should* make no difference.  The gap used to be 1 page and is now
> > configurable but defaults to 256 pages.
> > 
> > The stack gap used to be included in the range shown in /proc/*/maps
> > and was counted toward the stack limit.  The first version of the fix
> > did not change that, so it effectively reduced all existing limits by
> > 255 pages.  The second version of the fix excludes the stack gap from
> > both.
> > 
> > [..]
> 
> By the way, PAGESIZE on these ppc64el machines is 64KB not 4KB, so a
256-page stack guard would be 16MB which is way higher than the default
`ulimit -s` of 8MB.
> 
> Although you said that the stack guard (in theory) should not be part
of the stack limit, the fact that a 24MB limit made the segfaults go
away yet a 16MB did not, suggests there might be a link. What do you
think?

We talked about this on IRC and you also said that Rust allocates its
*own* stack guard page.  That can never have worked for the main stack
and will also now inhibit stack growth.  With 64 kiB pages, the stack
will never be able to grow with the default stack limit and stack gap
sizes.

Please can you test using a kernel with the attached patch? 
Instructions for building a patched kernel package are at:
https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official
I tested this with a Rust program on amd64 with a stack limit of 1 MiB
and it seems to work as expected.

Ben.

-- 
Ben Hutchings
The world is coming to an end.	Please log off.

Back to linux.debian.bugs.rc | Previous | Next | Find similar | Unroll thread

Thread

Bug#865549: [Pkg-rust-maintainers] Bug#865549: cargo still segfaults / rustc still FTBFS with the newest fixed kernel Ben Hutchings <ben@decadent.org.uk> - 2017-07-04 13:40 +0200

csiph-web