In 1.8.5's version of path_check_0(), the ruby vm recurses until it determines it's absolute path: path_check_0(fpath, loadpath) { ... if (!is_absolute_path(p0)) { ... return path_check_0(newpath, loadpath); } ... } However, if the environment's path is broken and getcwd unable to determine the full path of the current working directory, ruby will recurse indefinitely (or until consuming all available memory). The reproducer is fairly obtuse but replicates a problem a customer is seeing on-site. To reproduce: sudo mount <nfs>:<export> /mnt/ cd /mnt/foo sudo umount -l /mnt/ PATH= Then run any ruby program. I used: #!/usr/bin/ruby -w kernel = %x{/bin/uname -s}.chomp A better behavior would be to error out after any reasonable chance of determining an absolute path has failed.
The following patch presents one way of fixing the recursion problem by raising a rb_eRuntimeError if the relative path built in path_check_0 grows beyond MAXPATHLEN (eg, 4096). While not specifically targeting the case of a broken cwd, it seems a reasonable check to perform under all conditions. Another option would be to backport 1.8.6's non-recursive implementation of path_check_0; I did not do this because it relied on a series of macros defined in 1.8.6 not present in our version. However, that seems another reasonable and simple solution. I also fixed some white-space in the effected conditional block.
Created attachment 296521 [details] check maxpathlen patch
Created attachment 301632 [details] ruby getcwd path based on upstream code.
This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?".
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
I have been investigating this problem and it seems, that the patch in comment 3 by ritz is ok. I have reproduced the bug and the problem is, that if you do the steps from comment 1: sudo mount <nfs>:<export> /mnt/ cd /mnt/foo sudo umount -l /mnt/ PATH= then my_getcwd() function used to get the current working directory returns only 'foo/' (if you 'cd /mnt/foo/bar' instead of just 'cd /mnt/foo', my_getcwd returns 'foo/bar'). So when you call the function for the first time, it finds out that the path is not absolute (because its empty, thats why the 'PATH=' has to be present), so it calls my_getcwd and before recursing, it has "newpath = 'foo/'". This is not absolute path, so in the next call, the function prepends another 'foo/' to newpath. Therefore the recursion never ends, constructing the newpath in form of 'foo/foo/foo/foo/...', which is never absolute. The patch works because my_getcwd uses getcwd (which returns an absolute path in a normal case), so in a normal case, the recursion is not needed anyway. In the special case mentioned in comment 1, getcwd returns just foo/ and path_check_0 continues (and works) normally.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0218.html