[Bug libc/5758] New: [patch] Fix getrlimit() acting funny sometimes

[Bug libc/5758] New: [patch] Fix getrlimit() acting funny sometimes

[thomas dot jarosch at intra2net dot com]

Hey there,

attached patch fixes a little bug I found while tracing some getrlimit issues 
on my system. Please have a look, I couldn't find a place 
where "__have_no_new_getrlimit" seems to get initialized.

The patch is still valid for glibc HEAD.

Currently pthread_create fails on my system as ugetrlimit(STACK_SIZE) 
retuns "2147483648". That -almost- half the size of RLIM_INFINITY.
mmap() in ntpl/allocatestack.c then tries to get 2GB of memory on my 1 GB 
box ;-) Still investigating...

Cheers,
Thomas

-- 
           Summary: [patch] Fix getrlimit() acting funny sometimes
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: thomas dot jarosch at intra2net dot com
                CC: glibc-bugs at sources dot redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=5758

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/5758] [patch] Fix getrlimit() acting funny sometimes

[thomas dot jarosch at intra2net dot com]

------- Additional Comments From thomas dot jarosch at intra2net dot com  2008-02-12 14:30 -------
Created an attachment (id=2246)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=2246&action=view)
Initialize __have_no_new_getrlimit


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5758

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/5758] [patch] Fix getrlimit() acting funny sometimes

[drepper at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
Attachment #2246 is|0                           |1
           obsolete|                            |


http://sourceware.org/bugzilla/show_bug.cgi?id=5758

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/5758] [patch] Fix getrlimit() acting funny sometimes

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2008-02-12 15:23 -------
The patch is of course complete nonsense.  This is a global variable and hence
it is automatically initialize.  If this basic C programming knowledge isn't
known to you you really shouldn't touch libc code.

As for a  problem, I don't know of any and you have provided no indication
whatsoever.  You'll have to provide a test case reproducing the problem or I'll
close the bug.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sourceware.org/bugzilla/show_bug.cgi?id=5758

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/5758] [patch] Fix getrlimit() acting funny sometimes

[thomas dot jarosch at intra2net dot com]

------- Additional Comments From thomas dot jarosch at intra2net dot com  2008-02-12 16:09 -------
Ha, you caught me! I was not aware that global vars get initialized to zero 
with all the years experience in C as I always initialize my vars.
Guess I was confused after all the hours searching for the root of the 
ugetrlimit issue. You can close the bug while I'm still searching for the 
source of it.

btw: What's the best way to print/dump variables inside glibc? getrlimit() 
gets called very early in ntpl/init.c and fprintf(stderr) doesn't seem to work 
yet.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5758

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/5758] [patch] Fix getrlimit() acting funny sometimes

[thomas dot jarosch at intra2net dot com]

------- Additional Comments From thomas dot jarosch at intra2net dot com  2008-02-12 18:40 -------
Ulrich,

Concerning the rlimit issue:
My main system is running glibc 2.1.3 and kernel 2.6.23.
I've added some debug loggers to the kernel and traced
bash's 2.04 "ulimit -s unlimited" call. This ends up
in the kernel as sys_setrlimit(RLIMIT_STACK) -> 2147483647.

That's the signed version of RLIMIT_INFINITY missing one bit, right?
As far as I can tell there is no translation layer for setrlimit
in the kernel and there is only a ugetrlimit call but no usetrlimit call.
-> Old glibc versions will set wrong values.

As I'm currently in the process of switching the primary glibc to 2.7
I can add a small patch to nptl/init.c to get "__default_stacksize"
to a reasonable value until the switch over is complete.

OTOH we could modify unix/sysv/linux/i386/getrlimit.c to apply
the same "compat" code for ugetrlimit as for getrlimit.
Who want's a stack size of -exactly- 2GB for the threads anyway?!

This solves the famous error message like:
"gnome-terminal: allocatestack.c:370: allocate_stack: Assertion `size != 0' 
failed."

Here are just two examples of users facing the problem:

http://hercules.herts.ac.uk/~mjh/limits-conf-problem.html

or

http://nptl.bullopensource.org/phpBB/viewtopic.php?p=290


Hope you don't try to kill me again ;-)

Regards,
Thomas

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |ASSIGNED


http://sourceware.org/bugzilla/show_bug.cgi?id=5758

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/5758] [patch] Fix getrlimit() acting funny sometimes

[thomas dot jarosch at intra2net dot com]

------- Additional Comments From thomas dot jarosch at intra2net dot com  2008-02-14 16:08 -------
Created an attachment (id=2263)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=2263&action=view)
Correct signed values also for ugetrlimit

Attached patch fixes the getrlimit call for mixed new/old glibc setups as
described above. It should also fix it for systems running a current glibc
only, but still having the old signed limits somewhere in the system.
(f.e. pam_limits' /etc/security/limits.conf)


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5758

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/5758] [patch] Fix getrlimit() acting funny sometimes

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2008-03-09 05:48 -------
(In reply to comment #5)
> Attached patch fixes the getrlimit call for mixed new/old glibc setups as
> described above.

I won't cause potential problems for all users in the future just because some
people run for the time being these combined systems.  2G is no unreasonable
value to use.  Just get the system to the point where you throw away the old code.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |WONTFIX


http://sourceware.org/bugzilla/show_bug.cgi?id=5758

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/5758] [patch] Fix getrlimit() acting funny sometimes

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=5758

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.