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

Groups > linux.debian.kernel > #58222

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

Cross-posted to 2 groups.

Show all headers | View raw

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?

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Back to linux.debian.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Bug#865549: cargo still segfaults / rustc still FTBFS with the newest fixed kernel Ximin Luo <infinity0@debian.org> - 2017-06-29 17:20 +0200
  Bug#865549: [Pkg-rust-maintainers] cargo still segfaults / rustc still FTBFS with the newest fixed kernel Ximin Luo <infinity0@debian.org> - 2017-06-29 17:30 +0200
  Bug#865549: [Pkg-rust-maintainers] cargo still segfaults / rustc still FTBFS with the newest fixed kernel Ximin Luo <infinity0@debian.org> - 2017-06-29 19:50 +0200
    Bug#865549: [Pkg-rust-maintainers] cargo still segfaults / rustc still FTBFS with the newest fixed kernel Ben Hutchings <ben@decadent.org.uk> - 2017-06-30 00:40 +0200
      Bug#865549: [Pkg-rust-maintainers] Bug#865549: cargo still segfaults / rustc still FTBFS with the newest fixed kernel Ximin Luo <infinity0@debian.org> - 2017-06-30 11:10 +0200

csiph-web