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. Thanx Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: you cannot reproduce this. Additional info:
If you need more than 1024 fds, then select is certainly a bad interface, use poll instead. 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.