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. */
+/* 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)
#define STACK_SIZE (2 * 1024 * 1024)
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 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).
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.