Description of Problem: We're getting Memory faults from the JNI code we use as part of the admin engine for our product. This is caused because the threading library (linuxthreads/pthread.c) assigns less than 1Mb of stack per thread. Since all JNI accesses must occur in a thread, and the stack limit is inherited even across forks, this compromises even moderate stack usage on the IA64. There is a good reason why the max stack limit is 2Mb on IA32, but no good reason why it should be so small on IA64 because it has a far larger virtual memory space to map the thread stacks into. I realise the problem will be resolved eventually with floating stacks, but until then, could you apply the attached patch? It globally raises the maximum allowable stack to 16Mb for all 64 bit pointer architectures. --- linuxthreads/internals.h.orig Thu Aug 2 10:45:06 2001 +++ linuxthreads/internals.h Thu Aug 2 10:47:41 2001 @@ -339,7 +339,13 @@ THREAD_SELF implementation is used, this must be a power of two and a multiple of PAGE_SIZE. */ #ifndef STACK_SIZE +#ifdef __LP64__ +/* For 64 bit machines, we aren't as squeezed for thread stack space, and + the stack must be bigger because the alignment is. */ +#define STACK_SIZE (32 * 1024 * 1024) +#else #define STACK_SIZE (2 * 1024 * 1024) +#endif #endif
I thought stack sizes were floating on ia64 anyway; if glibc isn't configured that way, it should be (no need for 2.2.x kernel compatibility...)
It is not. The 2.4.0+ requirement is relevant to IA-32 only anyway (older kernels had broken LDT handling) and was requirement for %gs based threads, ie. where thread pointer lives in register (and that is a requirement for floating stacks). Floating stacks for alpha could be added easily (it is just a matter of testing), for IA-64 it will need some work (because of the divided stack vs. register save area issues).
See http://sources.redhat.com/ml/libc-hacker/2001-07/msg00051.html
Should be fixed in glibc-2.2.3-14 in rawhide.
Red Hat Linux and Red Hat Powertools are currently no longer supported by Red Hat, Inc. In an effort to clean up bugzilla, we are closing all bugs in MODIFIED state for these products. However, we do want to make sure that nothing important slips through the cracks. If, in fact, these issues are not resolved in a current Fedora Core Release (such as Fedora Core 5), please open a new issues stating so. Thanks.