pgrep reports error "cannot allocate" when run without stack limit
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
procps (Debian) |
Fix Released
|
Unknown
|
|||
procps (Ubuntu) |
Fix Released
|
Medium
|
William Wilson | ||
Focal |
Fix Released
|
Medium
|
William Wilson | ||
Groovy |
Fix Released
|
Medium
|
William Wilson | ||
Hirsute |
Fix Released
|
Medium
|
William Wilson |
Bug Description
[Impact]
- Users who have ulimit set high would see either slow
or failed pgrep and pkill commands
- Users who have ulimit set to unlimited would see
failed pgrep and pkill commands
- This bug occurs because the behavior of sysconf(
changed with a newer version of the kernel.
[Test Case]
- set the ulimit to unlimited by running `ulimit -S -s unlimited`
- run `pgrep bash` to see that the "cannot allocate" error is
printed and the command has failed.
[Where Problems Could Occur]
- We have set upper and lower limits on the size of the malloc, but
if further kernel versions break the call to sysconf in
unexpected ways we could still see problems.
[Original Description]
If you have no stack limit (ulimit -S -s unlimited), any pgrep call will fail with an error:
> pgrep vim
pgrep: cannot allocate 4611686018427387903 bytes
If you have a high stack limit (e.g. ulimit -S -s 500000), pgrep is very slow:
> time pgrep vim
2196
real 8.48s user 8.40s syst 0.07s busy 99% rmem 253444
The relevant upstream bug report could be: https:/
Archlinux bug report: https:/
procps:
Installed: 2:3.3.16-1ubuntu2
500 http://
Changed in procps (Debian): | |
status: | Unknown → New |
tags: | added: groovy |
tags: | added: hirsute |
tags: | added: fr-1174 |
tags: | removed: rls-hh-incoming |
Changed in procps (Ubuntu Focal): | |
assignee: | nobody → William Wilson (jawn-smith) |
Changed in procps (Ubuntu Groovy): | |
assignee: | nobody → William Wilson (jawn-smith) |
Changed in procps (Ubuntu Hirsute): | |
assignee: | nobody → William Wilson (jawn-smith) |
description: | updated |
Changed in procps (Ubuntu Hirsute): | |
status: | Triaged → In Progress |
Changed in procps (Ubuntu Groovy): | |
status: | Confirmed → In Progress |
Changed in procps (Ubuntu Focal): | |
status: | Confirmed → In Progress |
Changed in procps (Ubuntu Hirsute): | |
status: | In Progress → Fix Committed |
Changed in procps (Ubuntu Focal): | |
importance: | Undecided → Medium |
Changed in procps (Ubuntu Groovy): | |
importance: | Undecided → Medium |
Changed in procps (Ubuntu Hirsute): | |
importance: | Undecided → Medium |
Changed in procps (Debian): | |
status: | New → Fix Released |
For the unlimited case, there is also Debian bug #955697 https:/ /bugs.debian. org/cgi- bin/bugreport. cgi?bug= 955697
Those bug reports do not mention the massive slowdown linear in stack limit.