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
