From: Andreas Jaeger <aj@suse.de>
To: libc-hacker@sourceware.cygnus.com
Subject: Solution to my linuxthreads problem
Date: Mon, 20 Dec 1999 09:34:00 -0000 [thread overview]
Message-ID: <199912201734.SAA31126@sturm.suse.de> (raw)
Yesterday I reported a problem with the current glibc when using
headers from 2.3.33 on a Linux 2.2.13 system. Together with Andreas
Schwab we've fixed this with the appended patch. The problem is that
ugetrlimit doesn't exist and therefore errno is set - but errno is not
initialized yet. The solution is to move the getrlimit call after
errno has been set.
Andreas
1999-12-20 Andreas Jaeger <aj@suse.de>
* pthread.c (pthread_initialize): Move getrlimit call after
setting of errno.
===================================================================
RCS file: /cvs/glibc/libc/linuxthreads/pthread.c,v
retrieving revision 1.17.2.6
diff -u -c -r1.17.2.6 pthread.c
cvs server: conflicting specifications of output style
*** pthread.c 1999/11/22 20:41:55 1.17.2.6
--- pthread.c 1999/12/20 17:28:28
***************
*** 289,303 ****
STACK_SIZE boundary. */
__pthread_initial_thread_bos =
(char *)(((long)CURRENT_STACK_FRAME - 2 * STACK_SIZE) & ~(STACK_SIZE - 1));
- /* Play with the stack size limit to make sure that no stack ever grows
- beyond STACK_SIZE minus two pages (one page for the thread descriptor
- immediately beyond, and one page to act as a guard page). */
- getrlimit(RLIMIT_STACK, &limit);
- max_stack = STACK_SIZE - 2 * __getpagesize();
- if (limit.rlim_cur > max_stack) {
- limit.rlim_cur = max_stack;
- setrlimit(RLIMIT_STACK, &limit);
- }
/* Update the descriptor for the initial thread. */
__pthread_initial_thread.p_pid = __getpid();
/* If we have special thread_self processing, initialize that for the
--- 289,294 ----
***************
*** 308,313 ****
--- 299,314 ----
/* The errno/h_errno variable of the main thread are the global ones. */
__pthread_initial_thread.p_errnop = &_errno;
__pthread_initial_thread.p_h_errnop = &_h_errno;
+ /* Play with the stack size limit to make sure that no stack ever grows
+ beyond STACK_SIZE minus two pages (one page for the thread descriptor
+ immediately beyond, and one page to act as a guard page). */
+ /* errno must be set for system calls. */
+ getrlimit(RLIMIT_STACK, &limit);
+ max_stack = STACK_SIZE - 2 * __getpagesize();
+ if (limit.rlim_cur > max_stack) {
+ limit.rlim_cur = max_stack;
+ setrlimit(RLIMIT_STACK, &limit);
+ }
#ifdef __SIGRTMIN
/* Initialize real-time signals. */
init_rtsigs ();
next reply other threads:[~1999-12-20 9:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-12-20 9:34 Andreas Jaeger [this message]
1999-12-20 23:32 ` Ulrich Drepper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199912201734.SAA31126@sturm.suse.de \
--to=aj@suse.de \
--cc=libc-hacker@sourceware.cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).