Cannot allocate memory if process owned by user with large number of groups

Bug #1150413 reported by Andrew Lowther on 2013-03-06
138
This bug affects 23 people
Affects Status Importance Assigned to Milestone
procps (Ubuntu)
High
Dave Chiluk
Precise
High
Dave Chiluk
Quantal
High
Dave Chiluk
Raring
High
Dave Chiluk

Bug Description

[Impact]

 * Users that are members of large numbers of groups are unable to run procps commands, but instead are greated with a segfault or "failed to allocate XXXXXXXXX bytes of memory"

 * Many enterprise or University users create large numbers of groups in order to effectively manage access in their infrastructure. Often admins end up being added to most of these groups. Admins end up not being able to use procps commands as a result

 * before this update procps statically allocated a buffer of 1024 bytes for reading all of /proc/#/status. This file includes the list of gid's that a user is part of. The attached patches backport a45dace4 and 95d01362 from upstream procps-ng which modifies file2str to use a dynamically allocated buffer instead.

[Test Case]

 * sudo useradd bob; for i in {1..800}; do sudo groupadd group$i; sudo adduser bob group$i; done; sudo -u bob ps

 * The above command returns failed to allocate XXXXXXXXXXX bytes of memory

[Regression Potential]

 * Regressions are most likely to manifest in corruption of data that is available from the /proc/<pid>/{stat,statm,status} files. Additionally it is theoretically possible that non-returning proc commands could also be possible.

 * The above being said, I feel as though regression potential is fairly minimal as this is mostly a backport of upstream commits.

 * This fix is now available as part of this ppa https://launchpad.net/~chiluk/+archive/lp1150413 where the fix has already been verified by users on this thread.

[Other Info]

 * procps is a horrible no-good very bad codebase, and we should upgrade to procps-ng as soon as possible. Available https://gitorious.org/procps. Preferably before the next LTS.

----------------------------------Snip--------------------------------------
Both ps and pgrep exit with an error like "xrealloc: realloc(1073741824) failedCannot allocate memory" if there is a process owned by a user with a large number of groups.

I suspect this was introduced with a recent kernel patch which no longer limits the number of groups returned by /proc/<pid>/status to 32. It affects Ubuntu kernel 3.2.0-38.60 and newer.

Links
* related kernel bug report - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1132789
* kernel patch - https://lists.ubuntu.com/archives/kernel-team/2013-January/024446.html
* kernel 3.2.0-38.60 changelog - https://launchpad.net/ubuntu/precise/+source/linux/3.2.0-38.60

strace ps output where it fails when it gets to the process owned by a user with a large number of groups
open("/proc/11860/status", O_RDONLY) = 6
read(6, "Name:\tsu\nState:\tS (sleeping)\nTgid:\t11860\nPid:\t11860\nPPid:\t7912\nTracerPid:\t0\nUid:\t1001\t1001\t1001\t1001\nGid:\t1351\t1351\t1351\t1351\nFDSize:\t256\nGroups:\t1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 13", 1023) = 1023
close(6) = 0
mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbcc1e4c000
mremap(0x7fbcc1e4c000, 135168, 266240, MREMAP_MAYMOVE) = 0x7fbcc1e0b000
mremap(0x7fbcc1e0b000, 266240, 528384, MREMAP_MAYMOVE) = 0x7fbcc28cf000
mremap(0x7fbcc28cf000, 528384, 1052672, MREMAP_MAYMOVE) = 0x7fbcc27ce000
mremap(0x7fbcc27ce000, 1052672, 2101248, MREMAP_MAYMOVE) = 0x7fbcc1c6c000
mremap(0x7fbcc1c6c000, 2101248, 4198400, MREMAP_MAYMOVE) = 0x7fbcc186b000
mremap(0x7fbcc186b000, 4198400, 8392704, MREMAP_MAYMOVE) = 0x7fbcc106a000
mremap(0x7fbcc106a000, 8392704, 16781312, MREMAP_MAYMOVE) = 0x7fbcc0069000
mremap(0x7fbcc0069000, 16781312, 33558528, MREMAP_MAYMOVE) = 0x7fbcbe068000
mremap(0x7fbcbe068000, 33558528, 67112960, MREMAP_MAYMOVE) = 0x7fbcba067000
mremap(0x7fbcba067000, 67112960, 134221824, MREMAP_MAYMOVE) = 0x7fbcb2066000
mremap(0x7fbcb2066000, 134221824, 268439552, MREMAP_MAYMOVE) = 0x7fbca2065000
mremap(0x7fbca2065000, 268439552, 536875008, MREMAP_MAYMOVE) = 0x7fbc82064000
mremap(0x7fbc82064000, 536875008, 1073745920, MREMAP_MAYMOVE) = -1 EFAULT (Bad address)
mmap(NULL, 1073745920, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
brk(0x4133c000) = 0x1333000
mmap(NULL, 1073876992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
open("/sys/devices/system/cpu/online", O_RDONLY|O_CLOEXEC) = 6
read(6, "0\n", 8192) = 2
close(6) = 0
mmap(NULL, 134217728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x7fbbfa042000
munmap(0x7fbbfa042000, 33284096) = 0
munmap(0x7fbc00000000, 33824768) = 0
mprotect(0x7fbbfc000000, 135168, PROT_READ|PROT_WRITE) = 0
mmap(NULL, 1073745920, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
write(2, "xrealloc: realloc(1073741824) failed", 36xrealloc: realloc(1073741824) failed) = 36
write(2, "Cannot allocate memory\n", 23Cannot allocate memory
) = 23
exit_group(1) = ?

Steps I was able to use to reproduce the problem with all local users and groups. The number of groups needed to break ps may be different on other systems.
root@alowther-d02:~# for i in $(seq 180); do groupadd group$i ; done
root@alowther-d02:~# useradd user1
root@alowther-d02:~# su - user1 -c ps
No directory, logging in with HOME=/
  PID TTY TIME CMD
 5182 pts/0 00:00:00 su
 5183 pts/0 00:00:00 sh
 5185 pts/0 00:00:00 ps
root@alowther-d02:~# for i in $(seq 180); do adduser user1 group$i; done > /dev/null
root@alowther-d02:~# su - user1 -c ps
xrealloc: realloc(1073741824) failedCannot allocate memory

System info - I also tried using the version of procps from Raring, but it still failed
root@alowther-d02:~# lsb_release -rd
Description: Ubuntu 12.04.2 LTS
Release: 12.04
root@alowther-d02:~# uname -a
Linux alowther-d02 3.2.0-38-generic #61-Ubuntu SMP Tue Feb 19 12:18:21 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
root@alowther-d02:~# dpkg -l procps
ii procps 1:3.2.8-11ubuntu6 /proc file system utilities
root@alowther-d02:~# apt-cache policy procps
procps:
  Installed: 1:3.2.8-11ubuntu6
  Candidate: 1:3.3.3-2ubuntu5
  Version table:
     1:3.3.3-2ubuntu5 0
        500 http://aptproxy/ubuntu/ raring/main amd64 Packages
 *** 1:3.2.8-11ubuntu6 0
        500 http://aptproxy/ubuntu/ precise/main amd64 Packages
        100 /var/lib/dpkg/status

Andrew Lowther (alowther) wrote :

I'm not sure the best way to fix this, but I have located the problem.

I've found this bug to be caused by a Debian patch "ps_supgid_display.patch" which was initially from the bug report at http://bugs.debian.org/506303

When any /proc/<pid>/status has more than 1024 characters before the end of the Groups line, an infinite loop is entered because the loop never finds the "\n" character it expected. Looking back at the strace, the read of "/proc/11860/status" is truncated. A succesful part of the strace is

stat("/proc/1110", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
open("/proc/1110/stat", O_RDONLY) = 6
read(6, "1110 (npcd) S 1 1108 1108 0 -1 4202816 509903 56395239 0 129102 205 836 161563 37679 20 0 1 0 3191 243957760 263 18446744073709551615 4194304 4219268 140737259370048 140737259368256 140200938633277 0 0 0 16387 18446744071579436968 0 0 17 0 0 0 1348 0 0\n", 1023) = 253

While the loop runs, it keeps allocating more memory for the array of Group IDs that it has found associated with the process until it fails because there isn't enough memory to allocate.

The while loop below from the patch is what runs infinitely. The xrealloc allocates more memory, doubling the amount it wants each time the loop thinks the array is filled.
+ case_Groups:
+ isupgid = 0;
+ if (*S != '\n'){ // Is there any supplementary group ?
+ P->supgid = (int *) xmalloc(0x0004 * sizeof(int));
+ int vctsize = 0x0004;
+ while (S[1] != '\n' && isupgid<INT_MAX){ // There is one blank before '\n'
+ if (isupgid == vctsize){
+ vctsize *= 2;
+ P->supgid = (int *)xrealloc(P->supgid,vctsize * sizeof(int));
+ }
+ P->supgid[isupgid++] = strtol(S,&S,10);
+ P->nsupgid++;
+ }
+ }
+ continue;

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in procps (Ubuntu):
status: New → Confirmed
Andrew Lowther (alowther) wrote :

I created a very simple patch that allocates a larger buffer for the contents of /proc/<pid>/status, and avoids the infinite loop scenario. The buffer could still conceivably fill up, but ps at least won't crash.

A better solution would be to dynamically allocate memory when reading /proc/<pid>/* , but that looks like a much larger code change.

Another potential bug is that the output still seems limited. When running './p -e -o tid,supgid --sort supgid' , not all groups are being shown. It may also be a better solution to rework the original ps_supgid_display.patch to fix these issues.

e.g.
# ./p -e -o tid,supgid --sort supgid | grep 19853
19853 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252

# cat /proc/19853/status
Name: su
State: S (sleeping)
Tgid: 19853
Pid: 19853
PPid: 30058
TracerPid: 0
Uid: 1001 1001 1001 1001
Gid: 1351 1351 1351 1351
FDSize: 256
Groups: 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387
...

The attachment "gid_buffer_problem.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Changed in procps (Ubuntu):
importance: Undecided → High
status: Confirmed → Triaged
tags: added: precise
tags: added: raring
Steve Langasek (vorlon) on 2013-04-03
Changed in procps (Ubuntu):
assignee: nobody → Matthias Klose (doko)
Dave Chiluk (chiluk) wrote :

@doko
I came to the similar conclusion of increasing the buffer sizes when looking at bug #1174444. That issue however resulted in a segfault, but is solved by the same solution.

Matthias I know it's not ideal, but we are following what upstream is doing. Can we get your patch sru'ed into precise asap?

Dave Chiluk (chiluk) wrote :

@doko
What's going on with this? We have at least 18 people waiting on this and a few in other bugs. The fix looks pretty safe.

Here's a patch that loads /proc/*/status files into a dynamically sized buffer.

BTW, is there any ETA of precise update? It's a real issue.

Dave Chiluk (chiluk) wrote :

The fix referenced by comment #7 is
https://www.gitorious.org/procps/procps/commit/7933435584aa1fd75460f4c7715a3d4855d97c1c
Which is essentially the same fix as is attached in comment #3.

As for comment #8, I'd have to look at the problem more closely. Grzegorz, perhaps you could put together a ppa with your fix such that others could try out your fix and verify it? Additionally you might consider submitting your fix to the procps mainstream. Getting it into mainstream would make it a ton easier to get it into Ubuntu.

Okay, here's a PPA with the patched procps package:

https://launchpad.net/~megiteam/+archive/p2

Works for me™, please give it a try. I tested it with up to 480 groups (/proc/#/status had a bit over 3KB).

BTW, I noticed that even with the patch ps doesn't show all supplementary groups. For example,

root@mtdedicated:~# su - user1 -c 'grep Groups: /proc/self/status | wc'
No directory, logging in with HOME=/
      1 482 2414
root@mtdedicated:~# su - user1 -c 'ps -e -o tid,supgid --sort supgid | grep 1049 | head -1 | wc'
No directory, logging in with HOME=/
      1 48 242

Anyway, I'm pinging upstream just now.

Bryan Quigley (bryanquigley) wrote :

@Grzegorz Nosek (5-root-localdomain-pl)
How have you pinged upstream?

Via mail at <email address hidden> (got this one from the manpage of prcops-ng, as the original procps mailing list at <email address hidden> is a spam-infested wasteland).

Bryan Quigley (bryanquigley) wrote :

I have a confirmation from a customer that the megiteam PPA fixes their issue and that the procps package from 12.10 does not.

Dave Chiluk (chiluk) wrote :

So it looks like procps finally released a fix for this upstream. It is primarily contained in a45dace4 and 95d01362.

I have created a ppa for this here. Can someone please test this ppa, and report back here as to whether it fixes the seg faulting issues related to large numbers of groups. Once I hear back I will push an SRU through and get this into the main archive.

https://launchpad.net/~chiluk/+archive/lp1150413

I have also attached the debdiff with the solution to this bug.

Changed in procps (Ubuntu):
assignee: Matthias Klose (doko) → Dave Chiluk (chiluk)

I'e just installed the ppa and test it issuing "ps -ef" which previously produced the Segfault.
The PPA works. No more segfaults, at least using "ps -ef".

Thanks a lot.

Dave Chiluk (chiluk) wrote :

Thanks Javier for testing. I have since uploaded packages for quantal, raring, and saucy which should get built shortly. I'll go ahead and fill out the SRU now.

Dave Chiluk (chiluk) on 2013-09-24
description: updated
Changed in procps (Ubuntu):
status: Triaged → In Progress
tags: added: quantal saucy
Dave Chiluk (chiluk) on 2013-09-24
Changed in procps (Ubuntu):
status: In Progress → Confirmed
Changed in procps (Ubuntu Precise):
status: New → Triaged
Changed in procps (Ubuntu Quantal):
status: New → Triaged
Changed in procps (Ubuntu Raring):
status: New → Triaged
Changed in procps (Ubuntu Precise):
importance: Undecided → High
Changed in procps (Ubuntu Quantal):
importance: Undecided → High
Changed in procps (Ubuntu Raring):
importance: Undecided → Critical
importance: Critical → High
Dave Chiluk (chiluk) on 2013-09-25
Changed in procps (Ubuntu Precise):
status: Triaged → Confirmed
Changed in procps (Ubuntu Raring):
status: Triaged → Confirmed
Changed in procps (Ubuntu Quantal):
status: Triaged → Confirmed
Dave Chiluk (chiluk) wrote :

I updated the debdiffs and resultant quilt patches to include dep3 information.

Dave Chiluk (chiluk) wrote :
Dave Chiluk (chiluk) wrote :
Dave Chiluk (chiluk) wrote :
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package procps - 1:3.3.3-2ubuntu7

---------------
procps (1:3.3.3-2ubuntu7) saucy; urgency=low

  * Backport of a45dace4 and 95d01362 in order to enable dynamically
    allocated buffers in file2str. This fixes a number of seg fault problems
    including the one related to large numbers of groups per user.
    (LP: #1150413)
 -- Dave Chiluk <email address hidden> Thu, 26 Sep 2013 15:32:17 -0700

Changed in procps (Ubuntu):
status: Confirmed → Fix Released
Brian Murray (brian-murray) wrote :

I'll upload this to the SRU queue later today or tomorrow.

Dave Chiluk (chiluk) wrote :

Verified saucy.

tags: added: verification-saucy-done
Brian Murray (brian-murray) wrote :

I've uploaded this to all the relevant queues.

Dave Chiluk (chiluk) on 2013-09-30
Changed in procps (Ubuntu Precise):
assignee: nobody → Dave Chiluk (chiluk)
Changed in procps (Ubuntu Quantal):
assignee: nobody → Dave Chiluk (chiluk)
Changed in procps (Ubuntu Raring):
assignee: nobody → Dave Chiluk (chiluk)

Hello Andrew, or anyone else affected,

Accepted procps into raring-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/procps/1:3.3.3-2ubuntu5.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in procps (Ubuntu Raring):
status: Confirmed → Fix Committed
tags: added: verification-needed
Brian Murray (brian-murray) wrote :

Hello Andrew, or anyone else affected,

Accepted procps into quantal-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/procps/1:3.3.3-2ubuntu3.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in procps (Ubuntu Quantal):
status: Confirmed → Fix Committed
Brian Murray (brian-murray) wrote :

Hello Andrew, or anyone else affected,

Accepted procps into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/procps/1:3.2.8-11ubuntu6.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in procps (Ubuntu Precise):
status: Confirmed → Fix Committed
Dave Chiluk (chiluk) on 2013-10-08
tags: added: verification-quantal-done
tags: added: verification-done-quantal verification-done-saucy
removed: verification-quantal-done verification-saucy-done
Dave Chiluk (chiluk) on 2013-10-08
tags: added: verification-done-raring
Dave Chiluk (chiluk) wrote :

Verified p,q,r. All is looking good.

tags: added: verification-done verification-done-precise
removed: verification-needed
Dave Chiluk (chiluk) on 2013-10-08
Changed in procps (Ubuntu Quantal):
status: Fix Committed → Fix Released
Changed in procps (Ubuntu Precise):
status: Fix Committed → Fix Released
Changed in procps (Ubuntu Raring):
status: Fix Committed → Fix Released
Brian Murray (brian-murray) wrote :

The packages have not moved from the -proposed repository to the -updates one so the correct status is still Fix Committed as the packages are not available to everyone.

Changed in procps (Ubuntu Raring):
status: Fix Released → Fix Committed
Changed in procps (Ubuntu Quantal):
status: Fix Released → Fix Committed
Changed in procps (Ubuntu Precise):
status: Fix Released → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package procps - 1:3.2.8-11ubuntu6.1

---------------
procps (1:3.2.8-11ubuntu6.1) precise; urgency=low

  * Backport of a45dace4 and 95d01362 in order to enable dynamically
    allocated buffers in file2str. This fixes a number of seg fault problems
    including the one related to large numbers of groups per user.
    (LP: #1150413)
 -- Dave Chiluk <email address hidden> Fri, 27 Sep 2013 09:19:32 -0700

Changed in procps (Ubuntu Precise):
status: Fix Committed → Fix Released

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package procps - 1:3.3.3-2ubuntu3.1

---------------
procps (1:3.3.3-2ubuntu3.1) quantal; urgency=low

  * Backport of a45dace4 and 95d01362 in order to enable dynamically
    allocated buffers in file2str. This fixes a number of seg fault problems
    including the one related to large numbers of groups per user.
    (LP: #1150413)
 -- Dave Chiluk <email address hidden> Fri, 27 Sep 2013 08:28:14 -0700

Changed in procps (Ubuntu Quantal):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package procps - 1:3.3.3-2ubuntu5.1

---------------
procps (1:3.3.3-2ubuntu5.1) raring; urgency=low

  * Backport of a45dace4 and 95d01362 in order to enable dynamically
    allocated buffers in file2str. This fixes a number of seg fault problems
    including the one related to large numbers of groups per user.
    (LP: #1150413)
 -- Dave Chiluk <email address hidden> Fri, 27 Sep 2013 08:17:18 -0700

Changed in procps (Ubuntu Raring):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.