Red Hat Bugzilla – Bug 153299
%ebp register is 0x0, %esp register has a correct value
Last modified: 2007-11-30 17:07:06 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Description of problem:
THIS IS NOT A RHEL3 BUG, but I have no idea how to solve this problem.
I have developed a multi-threaded server that crashes if there are more than 500 threads. This server implements a simple HTTP Protocol. Each thread processes one request at a time.
When the number of threads are increased, the server receive a SIGSEGV un dumps a core file.
I have run "gdb -c core.pid server" and receive a strange $ebp register value. That value is 0x0. The server crashes in a function that tests if there is something to be read from the socket. The only thing there is done is a simple select((int)fd+1, &read_fs, NULL, NULL, &tv);
I have incresed maximum number of fds from 1024 to 65535 with ulimit -n. Also I have modified /usr/include/bits/typesize.h to increment __FD_SETSIZE from 1024 to 32678.
I have recompiled the server using -g and still receive that SIGSEGV.
Please tell me what can I do.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
you cannot reproduce this.
If you need more than 1024 fds, then select is certainly a bad interface, use
Are you using NPTL or LinuxThreads (if the latter, non-FLOATING_STACKS or
FLOATING_STACKS)? What is the thread stack size you are using?
With the default thread stack size ~ 500 threads are filling the whole address
space. You can tweak that with ulimit -s or pthread_attr_setstacksize.
%ebp 0 is nothing strange in -fomit-frame-pointer code, in
-fno-omit-frame-pointer code it shouldn't be 0 with the exception of function
started by clone(2).
BTW, you should have asked about this through your support contact, bugzilla
is really only for reporting bugs.